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 > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
