You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ariatosca.apache.org by "Vaishnavi K.R" <va...@ericsson.com> on 2017/09/05 08:57:46 UTC
Re: Unique identification of an instance element across services
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 <av...@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 <va...@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 <ta...@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 <de...@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 <ta...@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 <de...@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" <ta...@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" <ta...@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 <ta...@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.k.r@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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by Tal Liron <ta...@cloudify.co>.
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.baillargeon@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:tal@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.k.r@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 <ta...@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 <de...@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.k.r@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 <ra...@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.k.r@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 <ra...@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 <
> > > tnadeau@lucidvision.com>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <
> > > > dewayne@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
> > > > > > >> <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> > > > > > >> dewayne@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 <
> > tal@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 <
> > > > > > >>>> dewayne@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"
> > > > > > >>>>>>>>> <ta...@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 <
> > > > > > >>>> maxim@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"
> > > > > > >>>>>>>>>>> <ta...@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 <
> > > > > > >>>>> maxim@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 <
> > > > > > >>>> tal@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.k.r@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
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
RE: Unique identification of an instance element across services
Posted by Steve Baillargeon <st...@ericsson.com>.
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:tal@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 <va...@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 <ta...@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 <de...@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.k.r@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 <ra...@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.k.r@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 <ra...@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 <
> > tnadeau@lucidvision.com>
> > > > wrote:
> > > >
> > > > >
> > > > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <
> > > dewayne@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
> > > > > >> <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> > > > > >> dewayne@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 <
> tal@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 <
> > > > > >>>> dewayne@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"
> > > > > >>>>>>>>> <ta...@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 <
> > > > > >>>> maxim@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"
> > > > > >>>>>>>>>>> <ta...@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 <
> > > > > >>>>> maxim@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 <
> > > > > >>>> tal@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.k.r@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
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by Tal Liron <ta...@cloudify.co>.
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 <va...@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 <ta...@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 <de...@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.k.r@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 <ra...@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.k.r@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 <ra...@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 <
> > tnadeau@lucidvision.com>
> > > > wrote:
> > > >
> > > > >
> > > > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <
> > > dewayne@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> > > > > >> dewayne@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 <
> tal@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 <
> > > > > >>>> dewayne@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" <ta...@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 <
> > > > > >>>> maxim@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" <ta...@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 <
> > > > > >>>>> maxim@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 <
> > > > > >>>> tal@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.k.r@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
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by Arthur Berezin <ar...@cloudify.co>.
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 <va...@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 <ta...@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 <de...@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.k.r@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 <ra...@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.k.r@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 <ra...@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 <
> > tnadeau@lucidvision.com>
> > > > wrote:
> > > >
> > > > >
> > > > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <
> > > dewayne@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> > > > > >> dewayne@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 <
> tal@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 <
> > > > > >>>> dewayne@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" <ta...@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 <
> > > > > >>>> maxim@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" <ta...@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 <
> > > > > >>>>> maxim@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 <
> > > > > >>>> tal@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.k.r@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
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by "Vaishnavi K.R" <va...@ericsson.com>.
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 <ta...@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 <de...@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.k.r@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 <ra...@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.k.r@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 <ra...@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 <
> tnadeau@lucidvision.com>
> > > wrote:
> > >
> > > >
> > > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <
> > dewayne@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> > > > >> dewayne@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 <tal@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 <
> > > > >>>> dewayne@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" <ta...@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 <
> > > > >>>> maxim@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" <ta...@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 <
> > > > >>>>> maxim@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 <
> > > > >>>> tal@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.k.r@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
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by Tal Liron <ta...@cloudify.co>.
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 <de...@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.k.r@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 <ra...@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.k.r@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 <ra...@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 <
> tnadeau@lucidvision.com>
> > > wrote:
> > >
> > > >
> > > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <
> > dewayne@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> > > > >> dewayne@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 <tal@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 <
> > > > >>>> dewayne@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" <ta...@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 <
> > > > >>>> maxim@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" <ta...@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 <
> > > > >>>>> maxim@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 <
> > > > >>>> tal@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.k.r@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
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by DeWayne Filppi <de...@cloudify.co>.
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 <va...@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 <ra...@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.k.r@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 <ra...@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 <tn...@lucidvision.com>
> > wrote:
> >
> > >
> > > > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <
> dewayne@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> > > >> dewayne@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 <ta...@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 <
> > > >>>> dewayne@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" <ta...@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 <
> > > >>>> maxim@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" <ta...@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 <
> > > >>>>> maxim@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 <
> > > >>>> tal@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.k.r@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
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by "Vaishnavi K.R" <va...@ericsson.com>.
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 <ra...@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 <va...@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 <ra...@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 <tn...@lucidvision.com>
> wrote:
>
> >
> > > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <de...@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> > >> dewayne@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 <ta...@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 <
> > >>>> dewayne@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" <ta...@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 <
> > >>>> maxim@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" <ta...@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 <
> > >>>>> maxim@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 <
> > >>>> tal@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.k.r@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
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Unique identification of an instance element across services
Posted by Ran Ziv <ra...@cloudify.co>.
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 <va...@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 <ra...@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 <tn...@lucidvision.com>
> wrote:
>
> >
> > > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <de...@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> > >> dewayne@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 <ta...@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 <
> > >>>> dewayne@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" <ta...@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 <
> > >>>> maxim@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" <ta...@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 <
> > >>>>> maxim@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 <
> > >>>> tal@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.k.r@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
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Unique identification of an instance element across services
Posted by "Vaishnavi K.R" <va...@ericsson.com>.
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 <ra...@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 <tn...@lucidvision.com>
wrote:
>
> > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <de...@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> >> dewayne@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 <ta...@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 <
> >>>> dewayne@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" <ta...@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 <
> >>>> maxim@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" <ta...@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 <
> >>>>> maxim@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 <
> >>>> tal@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.k.r@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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: Unique identification of an instance element across services
Posted by Ran Ziv <ra...@cloudify.co>.
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 <tn...@lucidvision.com>
wrote:
>
> > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <de...@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> >> dewayne@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 <ta...@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 <
> >>>> dewayne@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" <ta...@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 <
> >>>> maxim@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" <ta...@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 <
> >>>>> maxim@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 <
> >>>> tal@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.k.r@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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: Unique identification of an instance element across services
Posted by DeWayne Filppi <de...@cloudify.co>.
I was also considering a "partial hash" concept like git.
On Fri, Sep 15, 2017 at 11:04 AM, Thomas Nadeau <tn...@lucidvision.com>
wrote:
>
> > On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <de...@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> >> dewayne@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 <ta...@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 <
> >>>> dewayne@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" <ta...@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 <
> >>>> maxim@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" <ta...@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 <
> >>>>> maxim@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 <
> >>>> tal@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.k.r@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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: Unique identification of an instance element across services
Posted by Thomas Nadeau <tn...@lucidvision.com>.
> On Sep 15, 2017, at 1:53 PM, Tal Liron <ta...@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 <de...@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
>> dewayne@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 <ta...@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 <
>>>> dewayne@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" <ta...@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 <
>>>> maxim@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" <ta...@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 <
>>>>> maxim@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 <
>>>> tal@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.k.r@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: Unique identification of an instance element across services
Posted by Tal Liron <ta...@cloudify.co>.
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 <de...@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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <
> dewayne@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 <ta...@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 <
> > > dewayne@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" <ta...@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 <
> > > maxim@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" <ta...@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 <
> > > > maxim@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 <
> > > tal@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.k.r@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
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by DeWayne Filppi <de...@cloudify.co>.
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 <ta...@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.k.r@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 <ta...@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.k.r@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 <av...@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.k.r@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 <ta...@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 <dewayne@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 <ta...@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 <
> > dewayne@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" <ta...@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 <
> > maxim@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" <ta...@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 <
> > > maxim@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 <
> > tal@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.k.r@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
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by Tal Liron <ta...@cloudify.co>.
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 <va...@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 <ta...@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 <va...@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 <av...@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.k.r@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 <ta...@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 <de...@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 <ta...@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 <
> dewayne@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" <ta...@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 <
> maxim@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" <ta...@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 <
> > maxim@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 <
> tal@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.k.r@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
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by "Vaishnavi K.R" <va...@ericsson.com>.
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 <ta...@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 <va...@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 <av...@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.k.r@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 <ta...@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 <de...@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 <ta...@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 <dewayne@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" <ta...@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" <ta...@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 <
> maxim@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 <ta...@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.k.r@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
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Unique identification of an instance element across services
Posted by Tal Liron <ta...@cloudify.co>.
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 <va...@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 <av...@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.k.r@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 <ta...@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 <de...@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 <ta...@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 <dewayne@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" <ta...@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" <ta...@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 <
> maxim@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 <ta...@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.k.r@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
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>