I'm wondering why the spec for SimpleAttributeOperand uses a browsePath list and not just a NodeId as the parameter.
From my understanding, NodeId would uniquely identify a node object but instead, we use a browse path list as specified for SimpleAttributeOperand which would lead to possible duplicates. In other words, two nodes can have the same browse name.
Am I correct in thinking this is an issue?
SimpleAttributeOperand is typically used to define the fields of an EventFilter.
The BrowsePath defines an element of the event relative to itself. You define, for example, that you wish to monitor all events from the server, and for each of them, you wish to get the Message. Alarms use nodes that contain the Message, but it's a different node for each alarm - and simple events don't define any nodes in the address space. So you don't want to use NodeIds for defining that, in practice.
Related
I have a collection in my Cosmos database that I would like to observe for changes. I have many documents (official and unofficial) explaining how to do this. There is one thing though that I cannot get to work in a reliable way: how do I receive the same changes to multiple instances when I don't have any common reference for instance names?
What do I mean by this? Well, I'm running my work loads in a Kubernetes cluster (AKS). I have a variable number of instances within the cluster that should observe my collection. In order for change feeds to work properly, I have to have a unique instance name for each instance. The only candidate I have is the pod name. It's usually on the form of <deployment-name>-<random string>. E.g. pod-5f597c9c56-lxw5b.
If I use the pod name as instance name, all instances do not receive the same changes (which is my requirement), only one instance will receive the change (see https://learn.microsoft.com/en-us/azure/cosmos-db/change-feed-processor#dynamic-scaling). What I can do is to use the pod name as feed name instead, then all instances get the same changes. This is what I fear will bite me in the butt at some point; when peek into the lease container, I can see a set of documents per feed name. As pod names come and go (the random string part of the name), I fear the container will grow over time, generating a heap of garbage. I know Cosmos can handle huge work loads, but you know, I like to keep things tidy.
How can I keep this thing clean and tidy? I really don't want to invent (or reuse for that matter!) some protocol between my instances to vote for which instance gets which name out of a finite set of names.
One "simple" solution would be to build my own instance names, if AKS or Kubernetes held some "index" of some sort for my pods. I know stateful sets give me that, but I don't want to use stateful sets, as the pods themselves aren't really stateful (except for this particular aspect!).
There is a new Change Feed pull model (which is in preview at this time).
The differences are:
In your case, it looks like you don't need parallelization (you want all instances to receive everything). The important part would be to design a state storing model that can maintain the continuation tokens (or not, maybe you don't care to continue if a pod goes down and then restarts).
I would suggest that you proceed to use the pod name as unique ID. If you are concerned about sprawl of the data, you could monitor the container and devise a clean-up mechanism for the metadata.
In order to have at-least-once delivery, there is going to need to be metadata persisted somewhere to track items ACK-ed / position in a partition, etc. I suspect there could be a bit of work to get change feed processor to give you at-least-once delivery once you consider pod interruption/re-scheduling during data flow.
As another option Azure offers an implementation of checkpoint based message sharing from partitioned event hubs via EventProcessorClient. In EventProcessorClient, there is also a bit of metadata added to a storage account.
I am trying to deviate a list to container in yang.
I tried going through RFC#6020, and I couldn't figure-out how to deviate on the container level.
You can't change the type of a yang node.
However, you can use deviate not-supported on the list and deviate add on the parent node to create a new container with the same name as the list. The child elements of the list will be lost.
What you try to achieve is not a common use case and deviation modules are not designed to do what you request. A deviation should be used as a last resort to let netconf clients know that some part of the yang modules is not supported or only with restrictions.
You can't do it. But you can use deviate not-supported on the list and augment a new container to the parent node. 'deviate' statment only can modify the poperties of data node ,but it can not add a new data node.
I have a query which returns a number of ways. I want to find nodes matching certain criteria which appear within those ways. Note that the nodes I'm interested in do not form part of the way itself, but do appear within the bounds of the way. Also, the ways do not all have corresponding areas, so using the area search doesn't work in all cases.
I've got a minimal example which finds way 95677318, and I want to be able to find node 1552949334:
(
way({{bbox}})["man_made"="lighthouse"];
)->.searchArea;
/*doesn't work:*/
/*node(area.searchArea)["seamark:name"];*/
/*recur down and find node directly, just for the purpose of this question*/
(
.searchArea;>;
node({{bbox}})["seamark:name"];
);
out;
(Try it on https://overpass-turbo.eu/s/EpV)
This feature is not yet available as of release 0.7.55. In case there's no corresponding area available on the Overpass server, this kind of query is simply not feasible.
See https://github.com/drolbr/Overpass-API/issues/77 for details.
I am building a OPC-UA server using eclipse milo. What are the different ways to provide multiple nodes for a subscription service? Can I define a custom data object having properties of basic data types, for this? How?
I want to have a service which serves data of different data types (Integer, Double, Boolean etc.) as it's output. Each of the values should be named different not single name like array output with single name for all of the values. For this purpose is there a way to define a custom data object class with attributes of different types? Is this possible in OPC to have a custom data object type as output of a service?
Conceptually, adding Nodes with each of the different DataTypes you're asking about is no different than creating a folder node and adding nodes to that.
The ExampleNamespace in the milo-examples project shows you how to do that.
If you truly want to use an instance of a custom ObjectType rather than an instance of FolderType then there's a bit of bookkeeping work you'll need to do.
Create an instance of ObjectTypeNode to describe your new type.
For each property/member it will have, create a new VariableNode with that configured with the DataType you want, then add a HasComponent or HasProperty reference from your ObjectTypeNode to this VariableNode. (These Nodes are what the spec calls InstanceDeclarations)
Add your ObjectTypeNode to the address space as a subtype of BaseObjectTypeNode.
Then, when you created your original ObjectNode, you'd specify the type definition as being your newly created ObjectTypeNode rather than, say, a FolderType.
You can get a better idea about how all this works in Part 3 and 5 of the spec or by using a client like UaExpert to inspect some of the pre-existing ObjectTypes in the server, such as ServerType.
Edit: There's now an example of how to do this here. If this seems a bit bulky... you're right. Typically ObjectTypes and VariableTypes are designed in a modelling tool and imported via a NodeSet XML file, but that's outside the scope of things right now...
I know that individual nodes can be versioned in JCR repositories. But what if I have documents that are comprised of a hierarchy of small individual snippets, aliases to nodes in larger snippet pool. I'd like to take a snapshot of all the nodes in a document and share information of the current state of the hierarchy among all clients that are editing the document. Is that possible with JCR and can you give me some pointers on how to do it?
Yes, it is possible (and quite easy) to version a subgraph in its entirety. The node at the top of the subgraph should have the jcr:versionable mixin, either explicitly or implicitly via a supertype of the node's primary type or mixin types. No other node in the subgraph needs to be marked as versionable; in fact, it's far easier if none of them do have it.
By default, all "on parent versioning" behavior of property definitions and child node definitions are COPY, which will work perfectly.
Then, simply get the VersionManager for the JCR Session (via the session's workspace), and check in the node:
javax.jcr.Node subgraphRoot = ...
javax.jcr.VersionManager vmgr = session.getWorkspace().getVersionManager();
vmgr.checkin(subgraphRoot.getPath());
Checking it out to modify it is just as simple:
vmgr.checkout(subgraphRoot.getPath());