So, we actually don't have this working yet. The code is in there, but it is not yet configurable. I've added a comment to ARIA-229 about specifically handling this. Until ARIA-229 is resolved, this issue is still open:
https://issues.apache.org/jira/browse/ARIA-229 Also, regarding service names, I've added a comment to ARIA-221. In my opinion, service name auto-generation should follow the same rules as node name auto-generation. That would be most coherent: https://issues.apache.org/jira/browse/ARIA-221 On Fri, Oct 6, 2017 at 3:32 PM, Steve Baillargeon < steve.baillarg...@ericsson.com> wrote: > Hi > About the UUID. > As far as I know and mentioned a number of times, ARIA already support > different kinds of ID generation. > I have nothing to add on this topic. > > I would like to focus on the service-template name and the 'already exist' > error generated by ARIA when the user submits a service-template with a > name that is "already-in-use". > When will this problem be resolved? Do we have a Jira for it? > As previously indicated, ARIA must allow for duplicate service-template > names. > > Here are the best practices for API regarding individual resource names > and resource IDs. > > 1) The resource name is generated by the API consumer. It is optional. The > resource name does *not* need to be globally unique. The resource name is > usually human-readable. > 2) If resource name is not generated by the API consumer, the API producer > does not need to (automatically) generate a resource name. > 3) The resource identifier is generated by the API producer. The resource > identifier must be "globally unique". The resource ID does not need to be > human-readable. > 4) The API producer must use the resource identifier to uniquely identify > the resource. It shall not use the resource name for identification > purpose. The resource name (if provided) is metadata associated with the > resource. > 5) The API consumer must provide the resource ID when performing an > operation on an existing resource. > > Regarding CLI and the existing Jira. > https://issues.apache.org/jira/browse/ARIA-221 > I don't think it is a good idea. > In fact, I think the API guidelines should apply to CLI as well. > The main difference will be on the choice of the resource identifier > algorithm. > If CLI user wants a "human-readable" ID, then selects one that is > appropriate for it. > If API user wants a true UUID, the selects a version 1 UUID for instance. > I suspect the choice of the resource identifier algorithm can be > system-wide or per interface (?) > > -Steve B > > > > -----Original Message----- > From: Tal Liron [mailto:t...@cloudify.co] > Sent: Monday, October 02, 2017 11:52 AM > To: dev@ariatosca.incubator.apache.org > Subject: Re: Unique identification of an instance element across services > > I suggest that this discussion isn't too important now. > > What's important is that we have support for user configuration in ARIA, > and that it is possible to easily switch between different kinds of ID > generation. > > Once we have that working, we can go back to discussing what the default > should be. As users gain some experience playing with different IDs we > could get feedback. > > On Thu, Sep 28, 2017 at 9:29 AM, Vaishnavi K.R <vaishnavi....@ericsson.com > > > wrote: > > > Thanks Tal. > > > > > > I think many of us are not convinced with the inclusion of the UUID > > for element identification. > > > > As of now, we have ID for the unique identification. So why should we > > restrict the users from giving duplicate names for the service templates. > > > > > > I wish to confirm if anyone has a second opinion in allowing duplicate > > names. > > > > If not, I can raise a JIRA issue and fix it. > > > > Looking forward to your comments. > > > > > > Thanks, > > > > /Vaish > > > > ________________________________ > > From: Tal Liron <t...@cloudify.co> > > Sent: Tuesday, September 26, 2017 2:04:50 AM > > To: dev@ariatosca.incubator.apache.org > > Subject: Re: Unique identification of an instance element across > > services > > > > DeWayne, I think you missed parts of this discussion where we answered > > some these issues: > > > > 1) ARIA *does* allow you configure you choice of ID generation, and I > > agree it can be an integration requirement. (We have a JIRA open to > > give this configuration a CLI.) > > 2) ARIA has a choice of UUID formats beyond the very long 36-character > hex. > > Base57 is 22 characters and designed for human readability. > > 3) All the costs you mention seem very negligible to me. ARIA's > > database storage is tiny. UUID generation happens only when new nodes > > are created, and is many orders of magnitude faster than storing > anything in a database. > > > > It doesn't easy to resolve this issue, as there are two camps here. > > But I'm very convinced that Vaish and I are correct here. :) Node (and > > service) names in the real world are used for other systems beyond > > ARIA once the nodes are installed: names become domain names linked to > > IP addresses, names of operating system services, registration IDs for > > message queues, analytics IDs, etc. For all of these a collision is > > disastrous, and Vaish is right that if it's set up initially by ARIA > > there is no need to do anything else. > > > > The only possible user discomfort is in using the "aria nodes show", > > which frankly is a command that I have never even used myself. As for > > logs, in any install that has more than one service you will be > > filtering by workflow ID or service ID anyway. > > > > Also, in case there was any confusion: we are talking about node names > > here, not database IDs. The database IDs are entirely handled within > > the database and are obviously unique only per table and per > > installation of ARIA. The "name" is an extra column that is uses out in > the real world. > > > > If this will have to come to a vote among committers, I will > > absolutely advocate UUIDs by default, and a preference for base57 > > format. I would consider any other kind of default to be broken for > > real world cloud orchestration, and I would be very worried if ARIA is > > to be broken out of the box. > > > > > > On Thu, Sep 21, 2017 at 11:09 AM, DeWayne Filppi <dewa...@cloudify.co> > > wrote: > > > > > IMHO, obviously UUIDs "work", in the sense that they are > > > "universally unique" and therefore make collisions unlikely. On the > > > other hand, they are "universally unique", which includes time and > > > space. There is a cost to that, and it is the ridiculous number of > > > bits used (IOW they are insanely inefficient). That has a cost both > in storage and readability.. > > > Also, unless there is a way to mathematically map the UUID to the > > > table index it refers to, the UUID will have to be in the database, > > > and > > therefore > > > the database will be exposed to the user. Besides bulk, the UUID > > > gets exposed in logs ( and occasionally in the CLI ), which just > > > creates a > > mess > > > and eats storage. So UUIDs work, but are a last resort, IMO. Has > > anyone > > > put any thought into a structured ID? Structured IDs are far more > > > useful and user friendly (readable) and potentially compact. I > > > think it would > > be > > > good to at least exhaust alternatives before resorting to UUIDs. > > > Another option is just to punt, make user exposed ID generation > > > pluggable, and provide a default implementation (or two). This > > > would allow consumers to use their own ID formats, which might be an > integration requirement. > > > > > > --DeWayne > > > > > > On Thu, Sep 21, 2017 at 4:25 AM, Vaishnavi K.R < > > vaishnavi....@ericsson.com > > > > > > > wrote: > > > > > > > Hi, > > > > > > > > > > > > Yes. You are correct. IDs remain unique across the table. > > > > > > > > Usually the IDs in the database are used for the internal operations. > > > > > > > > In general, they need not be exposed to the user. It is more used > > > > by > > the > > > > application itself. > > > > > > > > > > > > That's why it would be better to have an UUID which is specially > > > > meant > > to > > > > be used by the user. And also in the large scale environments, > > > > where > > huge > > > > number of service templates and instances pour in, they could have > > > uniform > > > > identification IDs rather than incremental numbers. > > > > > > > > > > > > And about allowing duplicate names for the service templates and > > service > > > > instances, it is MUST to have it. In multi user and multi tenant > > > > applications, the probability of getting the duplicate names is high. > > So > > > > its better to handle it in the initial phase itself. > > > > > > > > > > > > So I would like to know your suggestion and comment on the > > > > following > > > three > > > > items, > > > > > > > > > > > > 1. Allowing duplicate names for the service templates and > > > > service instances > > > > 2. Appending UUID to the node instances > > > > 3. Identifying the service templates and the service instances > > > > by > > > UUIDs > > > > (not appended to their names, because that might confuse the user > > > > when > > a > > > > list of items are scrolled on) > > > > > > > > > > > > Thanks, > > > > > > > > /Vaish > > > > > > > > ________________________________ > > > > From: Ran Ziv <r...@cloudify.co> > > > > Sent: Monday, September 18, 2017 4:25:57 PM > > > > To: dev@ariatosca.incubator.apache.org > > > > Subject: Re: Unique identification of an instance element across > > services > > > > > > > > The service name is optional - it may be auto-generated according > > > > to > > the > > > > service-template name. > > > > > > > > The service-template name can also be made optional (see this jira > > issue: > > > > https://issues.apache.org/jira/browse/ARIA-221 ). > > > > > > > > > > > > Regarding the scenario of non-CLI interaction - for any non-human > > usage, > > > > IDs should be used, as they're guaranteed to be unique. I don't > > > > see why UUIDs are necessary in this case. > > > > > > > > > > > > On Mon, Sep 18, 2017 at 9:22 AM, Vaishnavi K.R < > > > vaishnavi....@ericsson.com > > > > > > > > > wrote: > > > > > > > > > Hi All, > > > > > > > > > > > > > > > In addition to the node instance name, I am concerned about the > > service > > > > > template name and the service instance names. In a wider > > > > > perspective, > > > > there > > > > > is high chance for these names to be the same. > > > > > > > > > > > > > > > And as I have already mentioned in previous discussion, its an > > overhead > > > > > for an user to change the name again and again when he > > > > > encounters the 'already exist' error. > > > > > > > > > > > > > > > And also when ARIA is used as a TOSCA Orchestration service > > > > > provider, manual interaction via CLI won't happen. All > > > > > operations could be > > > > performed > > > > > over the HTTP calls. In such scenerio, it would be great and > > > > > very > > much > > > > > useful, if elements are queried or identified using the UUID. > > > > > > > > > > > > > > > So I see the uniqueness should prevail across the elements like > > service > > > > > templates, service instances and node instances. > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > /Vaish > > > > > > > > > > ________________________________ > > > > > From: Ran Ziv <r...@cloudify.co> > > > > > Sent: Saturday, September 16, 2017 12:12:22 AM > > > > > To: dev@ariatosca.incubator.apache.org > > > > > Subject: Re: Unique identification of an instance element across > > > services > > > > > > > > > > I can't seem to be able to access our JIRA at the moment, but > > generally > > > > > speaking, the CLI currently supports "static completion" only, i.e. > > it > > > > > auto-completes CLI commands but not object names. > > > > > We tried implementing dynamic completion (e.g. tab on "-s" would > > > > > auto-complete service names from the storage), but we ran into > > > > > some > > > > issues > > > > > with the underlying Click framework. > > > > > I'm not sure if an issue for trying to implement this further is > > > > currently > > > > > open on our JIRA. > > > > > > > > > > Regarding a "partial hash" concept, I don't really find this to > > > > > be > > > useful > > > > > in this case. IMO, as Tal's mentioned, the cases when you need > > > > > to > > > > actually > > > > > use these auto-generated long names are rare, and when that > > > > > happens, dynamic completion can take care of it well, if we can > get it done. > > > > > > > > > > > > > > > > > > > > On Fri, Sep 15, 2017 at 9:04 PM, Thomas Nadeau < > > > tnad...@lucidvision.com> > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <t...@cloudify.co> > wrote: > > > > > > > > > > > > > > When do you actually have to ender node names? Probably only > > > > > > > in > > > "aria > > > > > > nodes > > > > > > > show". And in those cases you would be copy-pasting from a > list. > > We > > > > > could > > > > > > > also improve our CLI completion code to properly complete > > > > > > > node > > IDs. > > > > > > > > > > > > That sounds like a very useful enhancement. Do we > > > > > > have a > > > Jira > > > > > for > > > > > > this yet? *) > > > > > > > > > > > > > I think the serial numbers are more confusing than helpful. > > > > > > > Let's > > > say > > > > > you > > > > > > > currently have 20 difference services running, and they are > > > > > > > of > > > > various > > > > > > > different service templates. But let's say a few service > > templates > > > > have > > > > > > > node templates with the same name, "database". You could > > > potentially > > > > > > > "database_1" in the list and "database_2", but each one of > > > > > > > these > > > > nodes > > > > > > > would be of a different node template of a different service > > > > template. > > > > > > The > > > > > > > serial number gives the false sense that these two nodes are > > > somehow > > > > > > > together. Anyway, we discussed this in much detail already: > > > > > > > we > > all > > > > > agree > > > > > > > that the serial system is totally broken if you're using > > > > > > > more > > than > > > > ARIA > > > > > > > install, or even if a few different ARIA users are using the > > > > > > > same > > > > cloud > > > > > > > accounts (each ARIA install could create its own > > > > > > > "database_1" -- > > > what > > > > > if > > > > > > > you have two hosts with that same DNS name?). > > > > > > > > > > > > I was just going to say the point you made above about > > > > > > DNS > > > name > > > > > > overlap. > > > > > > It sounds like we need to sit down and re-visit the serial > > > > > > number management? > > > > > > > > > > > > —Tom > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Sep 15, 2017 at 12:35 PM, DeWayne Filppi < > > > > dewa...@cloudify.co> > > > > > > > wrote: > > > > > > > > > > > > > >> I get the feeling that you are more gifted typist than > > > > > > >> most. Or > > > are > > > > > you > > > > > > >> saying nobody will ever be required to type in one those IDs? > > > > > > >> > > > > > > >> On Fri, Sep 15, 2017 at 9:27 AM, Tal Liron > > > > > > >> <t...@cloudify.co> > > > wrote: > > > > > > >> > > > > > > >>> Before we allow users to configure this, we have another > > > > > > >>> JIRA > > to > > > > > > resolve: > > > > > > >>> actually, we don't have a mechanism for storing > > > > > > >>> configuration > > > yet! > > > > > Here > > > > > > >> is > > > > > > >>> the open JIRA: > > > > > > >>> > > > > > > >>> https://issues.apache.org/jira/browse/ARIA-229 > > > > > > >>> > > > > > > >>> As for what to configure in this case, our practice until > > > > > > >>> now > > was > > > > > that > > > > > > >> the > > > > > > >>> UUID would be added as an underscored postfix of the > > > > > > >>> object's > > > name. > > > > > So > > > > > > if > > > > > > >>> you have a node template named "database" then node > > > > > > >>> instances > > > could > > > > > be, > > > > > > >>> assuming longest form of UUID (alphanumeric, 36 characters): > > > > > > >>> > > > > > > >>> database_2d79fd86-0877-49ca-81d8-cd2dc9f7b0e2 > > > > > > >>> database_2819972e-3b07-4923-be94-43e95985155f > > > > > > >>> database_45b9faf5-8bf4-482a-a570-d1c058270424 > > > > > > >>> > > > > > > >>> This guarantees names that are universally unique and yet > > > > > > >>> still > > > > > > >> meaningful: > > > > > > >>> you would be able to tell at a glance what kind of node > > > > > > >>> this > > is: > > > a > > > > > > >>> database. Note that we also have a mechanism in place to > > > > > > >>> warn > > you > > > > if > > > > > > the > > > > > > >>> final name is more than 63 characters, because such names > > > > > > >>> can't > > > be > > > > > used > > > > > > >> as > > > > > > >>> DNS hostnames (a common usage for node names in the cloud). > > This > > > > > should > > > > > > >>> also be configurable. > > > > > > >>> > > > > > > >>> I don't see why this needs to be abstracted from the user. > > > > > > >>> If > > you > > > > are > > > > > > >> using > > > > > > >>> the CLI and see the list of nodes, you can refer to the > > > > > > >>> node > > you > > > > are > > > > > > >>> examining with the full name as seen above. I think having > > > > > > >>> a > > > > separate > > > > > > UI > > > > > > >>> name such as "database_1", "database_2', etc., would be > > > confusing. > > > > > > >>> > > > > > > >>> So, assuming the above, I imagine these kinds of > > > > > > >>> configuration > > > > vars: > > > > > > >>> > > > > > > >>> instance.id_type = 'uuid' | 'alphanumeric' | 'base57' > > (default?) > > > | > > > > > > >> 'serial' > > > > > > >>> node.id_max_length = 63 > > > > > > >>> > > > > > > >>> Here are examples of the other types. Alphanumeric (25 > > > characters): > > > > > > >>> > > > > > > >>> database_t5evps77wp5biqdb1oyw36956 > > > > > > >>> database_uw5oa530kn9mu73lzjuech02a > > > > > > >>> database_nzv3a7umph0g1093abwq6qjd3 > > > > > > >>> > > > > > > >>> And base57 (22 characters): > > > > > > >>> > > > > > > >>> database_g8KV4qpKep2J2uA473fv6X > > > > > > >>> database_M2bLkYsToZ52L3HSy7CCmC > > > > > > >>> database_q8se9o5fDDWvT53tnnRiXN > > > > > > >>> > > > > > > >>> My personal preference for the default has always been > base57. > > It > > > > is > > > > > > both > > > > > > >>> the most compact, meaning less of a chance you would hit > > > > > > >>> the 63 > > > > > > character > > > > > > >>> limit, and also cleverly designed for human readability > > > > > > >>> (no visually-ambiguous glyphs). > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> On Fri, Sep 15, 2017 at 2:34 AM, Vaishnavi K.R < > > > > > > >> vaishnavi....@ericsson.com > > > > > > >>>> > > > > > > >>> wrote: > > > > > > >>> > > > > > > >>>> Hi, > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> Thanks for the update. > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> With current ARIA, the utility module to generate the > > > > > > >>>> UUID is > > > > > > >> available. > > > > > > >>>> But the UUID support will also mandate the following > > > > > > >>>> changes > > if > > > my > > > > > > >>>> understanding is right, > > > > > > >>>> > > > > > > >>>> 1. the inclusion of the UUID column in the mapper > > > > > > >>>> classes of > > > > > > >>> sqlalchemy > > > > > > >>>> 2. the model object created should set the value for > > > > > > >>>> the > > UUID > > > > and > > > > > > >> send > > > > > > >>>> it to database > > > > > > >>>> > > > > > > >>>> For an use case in our product, we badly need this UUID > > > > > > >>>> based > > > > > element > > > > > > >>>> identification. So I look forward to your comments on the > > > > following, > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> 1. We contribute the UUID support to ARIA without > > > > > > >>>> affecting > > > the > > > > > > >>> current > > > > > > >>>> CLI module i.e. CLI will continue to use the name option. > > > > > > >>>> The > > > UUID > > > > > > will > > > > > > >>> be > > > > > > >>>> completely abstracted from the user. > > > > > > >>>> 2. Configurable option to use UUID or name based > > > identification. > > > > > By > > > > > > >>>> default, it will work with the name based identification > > > > > > >>>> > > > > > > >>>> Also I need clarification on the UUID generation. > > > > > > >>>> Currently > > ARIA > > > > > > >> supports > > > > > > >>>> four variants. Do we have any standard on how this UUID > > > > > > >>>> should > > > be > > > > > and > > > > > > >>> also > > > > > > >>>> on what aspect these four variants are concluded on? > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> Thanks, > > > > > > >>>> > > > > > > >>>> /Vaish > > > > > > >>>> > > > > > > >>>> ________________________________ > > > > > > >>>> From: Tal Liron <t...@cloudify.co> > > > > > > >>>> Sent: Tuesday, September 5, 2017 8:24:41 PM > > > > > > >>>> To: dev@ariatosca.incubator.apache.org > > > > > > >>>> Subject: Re: Unique identification of an instance element > > across > > > > > > >> services > > > > > > >>>> > > > > > > >>>> We already have utility code to generate all kinds of > > > > > > >>>> UUIDs, > > so > > > > it's > > > > > > >>>> trivial to make the change. I guess it's just a matter of > > > making a > > > > > > >>>> decision... > > > > > > >>>> > > > > > > >>>> On Tue, Sep 5, 2017 at 3:57 AM, Vaishnavi K.R < > > > > > > >>> vaishnavi....@ericsson.com> > > > > > > >>>> wrote: > > > > > > >>>> > > > > > > >>>>> > > > > > > >>>>> Hi, > > > > > > >>>>> > > > > > > >>>>> I agree that with the CLI based usage in ARIA, the > > requirement > > > of > > > > > the > > > > > > >>>> UUID > > > > > > >>>>> based identification of the node and service instance > > elements > > > is > > > > > an > > > > > > >>>>> overhead. > > > > > > >>>>> > > > > > > >>>>> From the discussions so far, it seems like UUID is > > > > > > >>>>> important > > in > > > > > > >>> handling > > > > > > >>>>> the multi-user and multi-tenant scenarios. > > > > > > >>>>> > > > > > > >>>>> Do you have any update on when UUID will be considered > > > > > > >>>>> in the > > > > > > >> roadmap? > > > > > > >>>>> If its not too far, we would like to make our > > > > > > >>>>> contribution to > > > > ARIA > > > > > on > > > > > > >>>> UUID. > > > > > > >>>>> > > > > > > >>>>> Looking forward to your response. > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> Thanks, > > > > > > >>>>> > > > > > > >>>>> /Vaish > > > > > > >>>>> > > > > > > >>>>> ________________________________ > > > > > > >>>>> From: Avia Efrat <a...@cloudify.co> > > > > > > >>>>> Sent: Sunday, July 30, 2017 10:35:45 PM > > > > > > >>>>> To: dev@ariatosca.incubator.apache.org > > > > > > >>>>> Subject: Re: Unique identification of an instance > > > > > > >>>>> element > > > across > > > > > > >>> services > > > > > > >>>>> > > > > > > >>>>> First, good arguments from both 'sides'. > > > > > > >>>>> > > > > > > >>>>> I am for at least adding a uuid as an option, as ARIA is > > > intended > > > > > to > > > > > > >> be > > > > > > >>>>> used at scale as well. > > > > > > >>>>> But currently, I am for the simple ids to be used as > > > > > > >>>>> default > > > (and > > > > > not > > > > > > >>>>> uuids). Like it or not, right now ARIA is more at a > > > > > > >>>>> 'TOSCA > > > > > > >> playground' > > > > > > >>>>> stage, and I think that's perfectly fine =) And at this > > > > > > >>>>> stage, I think simple ids will be better, as they > > > > > easier > > > > > > >> to > > > > > > >>>> use > > > > > > >>>>> via the CLI, but more importantly, don't clog the logs > > > > > > >>>>> with > > > long > > > > > > >>>>> meaningless strings. As ARIA matures, we could switch > > > > > > >>>>> the > > > default > > > > > to > > > > > > >>>> UUIDs. > > > > > > >>>>> > > > > > > >>>>> And BTW, as our log format is configurable, there could > > > > > > >>>>> be > > > other > > > > > ways > > > > > > >>>> than > > > > > > >>>>> UUIDs to distinguish between nodes with the 'same id' in > > > > > > >>>>> a > > > > central > > > > > > >>>> logging > > > > > > >>>>> system, e.g using the user name as another indicator. > > > > > > >>>>> > > > > > > >>>>> On Thu, Jul 27, 2017 at 10:20 AM, Vaishnavi K.R < > > > > > > >>>>> vaishnavi....@ericsson.com> > > > > > > >>>>> wrote: > > > > > > >>>>> > > > > > > >>>>>> Hi, > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> Thanks for the active discussion. > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> Having UUID at the node instance level will just make > > > > > > >>>>>> the > > > nodes > > > > > > >>> unique. > > > > > > >>>>>> > > > > > > >>>>>> And these names will not be used by the user directly > > > > > > >>>>>> as no > > > > > > >>> operations > > > > > > >>>>> are > > > > > > >>>>>> happening on the node instance name. > > > > > > >>>>>> > > > > > > >>>>>> But at the service template and the service level, UUID > > > > > > >>>>>> will > > > be > > > > of > > > > > > >>>> great > > > > > > >>>>>> help considering the multi user and multi tenancy > > situations. > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> So in a large scale perspective, the node names and the > > > service > > > > > > >>>> template > > > > > > >>>>>> names have high probability of being same. > > > > > > >>>>>> > > > > > > >>>>>> When these enter into the automated world, it will > > > > > > >>>>>> create > > more > > > > > > >>> problem > > > > > > >>>>>> when name conflicts occur and its adds overhead to make > > > changes > > > > > > >> every > > > > > > >>>>> time > > > > > > >>>>>> to overcome the conflict. > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> UUID at service template and the service level: will be > > > > > > >>>>>> of > > > much > > > > > use > > > > > > >>> in > > > > > > >>>>> the > > > > > > >>>>>> above scenario and operations by user on these are less > > > > > > >>>>>> > > > > > > >>>>>> UUID at node instance level: makes the node much unique > > > > > > >>>>>> and > > no > > > > > > >>>> operation > > > > > > >>>>>> happens on it > > > > > > >>>>>> > > > > > > >>>>>> > > > > > > >>>>>> Thanks, > > > > > > >>>>>> > > > > > > >>>>>> /Vaish > > > > > > >>>>>> > > > > > > >>>>>> ________________________________ > > > > > > >>>>>> From: Tal Liron <t...@cloudify.co> > > > > > > >>>>>> Sent: Wednesday, July 26, 2017 8:48:40 PM > > > > > > >>>>>> To: dev@ariatosca.incubator.apache.org > > > > > > >>>>>> Subject: Re: Unique identification of an instance > > > > > > >>>>>> element > > > across > > > > > > >>>> services > > > > > > >>>>>> > > > > > > >>>>>> I just don't see users having to deal much with node > > > > > > >>>>>> IDs > > > outside > > > > > of > > > > > > >>>>> simple > > > > > > >>>>>> hello-world style tutorials, and I'd hate for the first > > > > > impressions > > > > > > >>>> that > > > > > > >>>>>> users get out of ARIA is that it's just a playground > > > > > > >>>>>> for > > > TOSCA. > > > > It > > > > > > >>>> should > > > > > > >>>>>> be ready out-of-the-box for the real world. > > > > > > >>>>>> > > > > > > >>>>>> On Wed, Jul 26, 2017 at 9:13 AM, DeWayne Filppi < > > > > > > >> dewa...@cloudify.co > > > > > > >>>> > > > > > > >>>>>> wrote: > > > > > > >>>>>> > > > > > > >>>>>>> Such is their strength. I'm just advocating using > > > > > > >>>>>>> them as > > a > > > > last > > > > > > >>>>> resort > > > > > > >>>>>>> because they are user unfriendly and gigantic. > > > > > > >>>>>>> > > > > > > >>>>>>> On Tue, Jul 25, 2017 at 12:55 PM, Tal Liron < > > t...@cloudify.co > > > > > > > > > > >>> wrote: > > > > > > >>>>>>> > > > > > > >>>>>>>> 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 > > > > > > >>>>>>>> identify it via the particular user and service > instance. > > If > > > > > > >>> you're > > > > > > >>>>>>>> centralizing logs, this can quickly be cumbersome. A > > > > > > >>>>>>>> UUID > > > will > > > > > > >>>>> identify > > > > > > >>>>>>> it > > > > > > >>>>>>>> globally and avoid any confusion. > > > > > > >>>>>>>> > > > > > > >>>>>>>> I think the default should be something that avoids > > > > > > >>>>>>>> such > > > > > > >>> problems. > > > > > > >>>>> For > > > > > > >>>>>>>> users who insist on shorter IDs, we can allow them to > > > > configure > > > > > > >>> it. > > > > > > >>>>>>>> > > > > > > >>>>>>>> On Tue, Jul 25, 2017 at 2:42 PM, DeWayne Filppi < > > > > > > >>>> dewa...@cloudify.co > > > > > > >>>>>> > > > > > > >>>>>>>> wrote: > > > > > > >>>>>>>> > > > > > > >>>>>>>>> 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" > > > > > > >>>>>>>>> <t...@cloudify.co> > > > > > > >> wrote: > > > > > > >>>>>>>>> > > > > > > >>>>>>>>>> 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 > > > > > > >>>>>>>>>> lot outside of debugging. And when you do debug, > > > > > > >>>>>>>>>> you'll > > > > > > >>>> probably > > > > > > >>>>> be > > > > > > >>>>>>>>> copying > > > > > > >>>>>>>>>> and pasting a node ID from the logs, so shorter > > > > > > >>>>>>>>>> names do > > > > > > >> not > > > > > > >>>> add > > > > > > >>>>>> much > > > > > > >>>>>>>>> ease > > > > > > >>>>>>>>>> of use. > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> Again, I would be personally happiest if this was > > > > > > >>> configurable > > > > > > >>>>> (and > > > > > > >>>>>>>>>> personally think UUIDs should be the reasonable > > default). > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>> On Tue, Jul 25, 2017 at 2:01 PM, Maxim Orlov < > > > > > > >>>> ma...@cloudify.co> > > > > > > >>>>>>>> wrote: > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>>>> 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" > > > > > > >>>>>>>>>>> <t...@cloudify.co> > > > > > > >>>> wrote: > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> 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 sense of > > > > > > >> predictability. > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> In my opinion the best compromise is to use > > > > > > >> base57-encoded > > > > > > >>>>> UUIDs. > > > > > > >>>>>>>> These > > > > > > >>>>>>>>>> are > > > > > > >>>>>>>>>>> true UUIDs, but use a mix of upper and lowercase > > > > > > >>>> alphanumerics > > > > > > >>>>>>>> ensuring > > > > > > >>>>>>>>>> no > > > > > > >>>>>>>>>>> visually ambiguous characters. We have the code > > > > > > >>>>>>>>>>> for > > this > > > > > > >> in > > > > > > >>>>>>>>>> utils/uuid.py. > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> See also: > > > > > > >>>>>>>>>>> https://github.com/wyattisimo/base57-ruby > > > > > > >>>>> [https://avatars1.githubusercontent.com/u/625546?v=3&s=4 > > > > > > >>>>> 00 > > > > > ]<https:// > > > > > > >>>>> github.com/wyattisimo/base57-ruby> > > > > > > >>>>> > > > > > > >>>>> GitHub - wyattisimo/base57-ruby: Base57 encoder for > > > > > > >>>>> Ruby.< https://github.com/wyattisimo/base57-ruby> > > > > > > >>>>> github.com > > > > > > >>>>> base57-ruby - Base57 encoder for Ruby. ... Clone with > > > > > > >>>>> HTTPS > > Use > > > > Git > > > > > > >> or > > > > > > >>>>> checkout with SVN using the web URL. > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>> On Tue, Jul 25, 2017 at 1:28 PM, Maxim Orlov < > > > > > > >>>>> ma...@cloudify.co> > > > > > > >>>>>>>>> wrote: > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>>>> 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, Jul 25, 2017 at 7:35 PM, Tal Liron < > > > > > > >>>> t...@cloudify.co> > > > > > > >>>>>>>> wrote: > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>>>> 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, Jul 25, 2017 at 3:42 AM, Vaishnavi K.R < > > > > > > >>>>>>>>>>>> vaishnavi....@ericsson.com > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>> wrote: > > > > > > >>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> 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 > > > > > > >>>>>>>>>>>> for > > > > > > >>>>>>>>>>>>>> the node template is '3' and how this will hold > > > > > > >> good > > > > > > >>>>> during > > > > > > >>>>>>>> scale > > > > > > >>>>>>>>>> in > > > > > > >>>>>>>>>>>> and > > > > > > >>>>>>>>>>>>>> out? > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> Could UUID be of great help in handling such > > > > > > >>>>>>>>>>>>>> cases > > > > > > >> by > > > > > > >>>>>>> including > > > > > > >>>>>>>>>> that > > > > > > >>>>>>>>>>>> as a > > > > > > >>>>>>>>>>>>>> column in the database tables of the service > > > > > > >>>>>>>>>>>>>> and > > > > > > >> the > > > > > > >>>>> node? > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> This will wipe out the naming confusions and > > > > > > >> querying > > > > > > >>>> can > > > > > > >>>>>> be > > > > > > >>>>>>>> made > > > > > > >>>>>>>>>>> easy > > > > > > >>>>>>>>>>>>>> with the UUIDs. > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> Looking forward to your suggestion. > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> Thanks, > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>>> /Vaish > > > > > > >>>>>>>>>>>>>> > > > > > > >>>>>>>>>>>>> > > > > > > >>>>>>>>>>>> > > > > > > >>>>>>>>>>> > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>> > > > > > > >>>>>>>> > > > > > > >>>>>>> > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >
