>From looking into that other tools are doing, looks like docker engine does not allows using duplicate names even when it uses UUIDs, I assume they made this decision for better UX. Other management tools(OpenStack and others) follow only uuid as unique fields.
On Thu, Sep 28, 2017 at 5:30 PM Vaishnavi K.R <[email protected]> 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 <[email protected]> > Sent: Tuesday, September 26, 2017 2:04:50 AM > To: [email protected] > 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 <[email protected]> > 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 < > [email protected] > > > > > 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 <[email protected]> > > > Sent: Monday, September 18, 2017 4:25:57 PM > > > To: [email protected] > > > 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 < > > [email protected] > > > > > > > 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 <[email protected]> > > > > Sent: Saturday, September 16, 2017 12:12:22 AM > > > > To: [email protected] > > > > 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 < > > [email protected]> > > > > wrote: > > > > > > > > > > > > > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <[email protected]> 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 < > > > [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 > > > > > >>>>>>>>>>>>>> > > > > > >>>>>>>>>>>>> > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > >> > > > > > > > > > > > > > > > > > > > >
