ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tal Liron <...@cloudify.co>
Subject Re: Unique identification of an instance element across services
Date Wed, 26 Jul 2017 15:18:40 GMT
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" <tal@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" <tal@cloudify.co> wrote:
> > > > >
> > > > > Our code for determining the next index is not concurrently safe
> (no
> > > > atomic
> > > > > transaction) so I can see it breaking in concurrent use cases
> > (running
> > > > two
> > > > > ARIA commands at the same time).
> > > > >
> > > > > What is to gain here in terms of human readability? In my opinion
> it
> > > adds
> > > > > confusion because it gives a false sense of predictability.
> > > > >
> > > > > In my opinion the best compromise is to use base57-encoded UUIDs.
> > These
> > > > are
> > > > > true UUIDs, but use a mix of upper and lowercase alphanumerics
> > ensuring
> > > > no
> > > > > visually ambiguous characters. We have the code for this in
> > > > utils/uuid.py.
> > > > >
> > > > > See also: https://github.com/wyattisimo/base57-ruby
> > > > >
> > > > > On Tue, Jul 25, 2017 at 1:28 PM, Maxim Orlov <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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message