Re: Unique identification of an instance element across services

Let's consider a mass deployment: thousands of service instances of the same service template, created by many different users with their own ARIA installations (and databases). In that case, assuming we use sequential IDs, you would have the same node ID appear many times. You would have to

Re: Unique identification of an instance element across services

This is a nice post: https://rclayton.silvrback.com/do-you-really-need-a-uuid-guid On Jul 25, 2017 12:42 PM, "DeWayne Filppi" wrote: > True uuids are seductive, because of their simplicity. But they are huge, > overkill, and meaningless. Imho a structured id is superior

Re: Unique identification of an instance element across services

True uuids are seductive, because of their simplicity. But they are huge, overkill, and meaningless. Imho a structured id is superior if it can be made to work without a global locking scheme. - DeWayne On Jul 25, 2017 12:11 PM, "Tal Liron" wrote: > It's not an issue of

Re: Unique identification of an instance element across services

It's not an issue of thread safety -- it could be entirely different processes, on different machines, accessing the same db. It can be solved via a SQL transaction, but I feel the whole issue can be avoided by using UUIDs. Using the CLI to access specific nodes is not something I see happening a

Re: Unique identification of an instance element across services

Technically we have no issue with implementing this via uuid or a threadsafe solution for the current index implementation. Getting node data via the cli feels more intuitive using the index based ID, rather than the uuid based ID in my opionion. On Jul 25, 2017 9:49 PM, "Tal Liron"

Re: Unique identification of an instance element across services

Our code for determining the next index is not concurrently safe (no atomic transaction) so I can see it breaking in concurrent use cases (running two ARIA commands at the same time). What is to gain here in terms of human readability? In my opinion it adds confusion because it gives a false

Re: Unique identification of an instance element across services

Actually the refactoring was made so the id would be more user readable. The index is determined according to the used indices (it's not just a running number). If indeed this poses an issue (or if indeed a uuid is easier to recognize, or even use in a query), let's discuss it further... On Tue,

Re: Inputs and Node object context for python and shell scripts

Not entirely sure about that actually, let me double check that. On Tue, Jul 25, 2017 at 7:37 PM, Tal Liron wrote: > It should be impossible in TOSCA to create an attribute that was not > declared at the type. Are we allowing users to create any ad hoc attribute? > > On Tue,

Re: Inputs and Node object context for python and shell scripts

It should be impossible in TOSCA to create an attribute that was not declared at the type. Are we allowing users to create any ad hoc attribute? On Tue, Jul 25, 2017 at 7:33 AM, Maxim Orlov wrote: > Indeed runtime_properties became attributes in ARIA . As for the behavior, >

Re: Unique identification of an instance element across services

We used to use UUIDs but at some point this was refactored. I tend to agree with you. Actually, I would prefer it to be configurable. We have code in place for ID generation of various types: UUIDs, short UUIDs, and sequentials. All of them would seem useful to me for various scenarios. On Tue,

Re: TOSCA spec compliance on finding target node

It indeed should *not* be required. I just verified that it you are correct, and a match is not made if only the capability is specified without a node type/template. This is a regression, because it used to work correctly. There is currently work in progress to refactor that mechanism, so I

Re: Inputs and Node object context for python and shell scripts

Indeed runtime_properties became attributes in ARIA . As for the behavior, attributes behave just as a dict would (behind the scenes attributes translate to a proper Attribute TOSCA model). No need to define the attributes on the node-type level, if an attribute with that name exists in on the

RE: Inputs and Node object context for python and shell scripts

Hi Max, I see the runtime_properties have been replaced with "attributes" and there has been multiple changes with respect to attribute handling. What do you refer by "map" in your below example, Is that a keyword ? "ctx.node.attributes['map']['key'] = value" Also with runtime_properties

Digest for ASF's Slack

Here’s your digest for today! #ariatosca undefined: [UPDATE] still having issues with clearwater running, however while improving the template and scripts i have encountered a few bugs that i'm fixing along the way. one of them was in the parser, in terms of dealing with overriding capability

Unique identification of an instance element across services

Hi, With my understanding in current ARIA, the node instances are made unique by prefixing the node name with the 'id of the service' (i.e. the primary key of the service table) as the instances are specific to the service. What will be the name of the node instances if the default instances

TOSCA spec compliance on finding target node

Hi ARIA folks, I had a look at the source code of ARIA on how the target node is identified based on the requirement and capability information furnished in the node template and its corresponding node type. But I find that only few of the combinations are supported i.e., as per the TOSCA