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=400]<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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
