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.
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?). On Fri, Sep 15, 2017 at 12:35 PM, DeWayne Filppi <[email protected]> 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 <[email protected]> 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 < > [email protected] > > > > > 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 <[email protected]> > > > Sent: Tuesday, September 5, 2017 8:24:41 PM > > > To: [email protected] > > > 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 < > > [email protected]> > > > 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 <[email protected]> > > > > Sent: Sunday, July 30, 2017 10:35:45 PM > > > > To: [email protected] > > > > 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 < > > > > [email protected]> > > > > 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 <[email protected]> > > > > > Sent: Wednesday, July 26, 2017 8:48:40 PM > > > > > To: [email protected] > > > > > 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 < > [email protected] > > > > > > > > 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 <[email protected]> > > 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 < > > > [email protected] > > > > > > > > > > > > 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" <[email protected]> > 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 < > > > [email protected]> > > > > > > > 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" <[email protected]> > > > 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 < > > > > [email protected]> > > > > > > > > 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 < > > > [email protected]> > > > > > > > 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 < > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
