Re: Unique identification of an instance element across services

[DeWayne Filppi]

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 
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 
> 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  >
> 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 
> > 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, 

Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[Tal Liron]

I do suggest the repository, because it seems like the more TOSCA way to do
this. These are special imports that are not part of the CSAR but rather
provided in a special way by ARIA. A special repository seems to be the
right way to handle this.

On Thu, Sep 21, 2017 at 2:40 AM, D Jayachandran  wrote:

> Hi Tal,
>
> I had a space between the plugin and filename. The correct one would like
> this.
>
> import
>   - plugin:openstack-1.0
>
> By this way it won't conflict with YAML convention. Do you still suggest
> to use the repository conventions ?
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Wednesday, September 20, 2017 9:38 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> I think the format you suggest is awkward in YAML. Because ":" is
> reserved, you would have to wrap the string in quotes:
>
> imports:
>  - this/is/a/string/import.yaml
>  - this is also a string .yaml
>  - "plugins: but here we have to add quotes because of the colon.yaml"
>
> The TOSCA way to handle name ambiguity is to use a repository in the
> long-form of the import. What we can do is create a built-in repository
> called "plugins". So it would look like this:
>
> imports:
>  - mytypes.yaml
>  - repository: plugins
>file: openstack.yaml
>
>
>
>
>
>
> On Wed, Sep 20, 2017 at 3:49 AM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi Tal,
> >
> > With respect to this JIRA issue.
> > I would like to contribute on the first part, which is specific to
> > plugin implementation.
> >
> > " If a plugin contained its plugin.yaml as part of its wagon archive,
> > then once installed, users could import the yaml file more easily
> > using a notation such as plugins/openstack.yaml (or perhaps
> > openstack.yaml, having the import mechanism iterate over plugins
> > looking for this resource file or so)"
> >
> > Instead of "plugins/openstack.yaml", I would like to suggest the
> > following
> > "plugins: openstack-"
> > Please let me know if this fine with you.
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Tal Liron [mailto:t...@gigaspaces.com]
> > Sent: Thursday, July 20, 2017 6:24 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Contribution for https://issues.apache.org/
> > jira/browse/ARIA-118
> >
> > It's unassigned, so I don't see why not!
> >
> > On Thu, Jul 20, 2017 at 7:41 AM, D Jayachandran <
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Hi,
> > >
> > > Do you have any plans on working on this JIRA issue ?
> > > https://issues.apache.org/jira/browse/ARIA-118
> > > Can we contribute on this ?
> > >
> > >
> > > Regards,
> > > DJ
> > >
> >
>

Re: Unique identification of an instance element across services

[Vaishnavi K . R]

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 
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 
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 
> 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 
> wrote:
>
> >
> > > On Sep 15, 2017, at 1:53 PM, Tal Liron  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 

RE: Contribution for https://issues.apache.org/jira/browse/ARIA-118

[D Jayachandran]

Hi Tal,

I had a space between the plugin and filename. The correct one would like this.

import
  - plugin:openstack-1.0

By this way it won't conflict with YAML convention. Do you still suggest to use 
the repository conventions ?

Regards,
DJ
-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Wednesday, September 20, 2017 9:38 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

I think the format you suggest is awkward in YAML. Because ":" is reserved, you 
would have to wrap the string in quotes:

imports:
 - this/is/a/string/import.yaml
 - this is also a string .yaml
 - "plugins: but here we have to add quotes because of the colon.yaml"

The TOSCA way to handle name ambiguity is to use a repository in the long-form 
of the import. What we can do is create a built-in repository called "plugins". 
So it would look like this:

imports:
 - mytypes.yaml
 - repository: plugins
   file: openstack.yaml






On Wed, Sep 20, 2017 at 3:49 AM, D Jayachandran  wrote:

> Hi Tal,
>
> With respect to this JIRA issue.
> I would like to contribute on the first part, which is specific to 
> plugin implementation.
>
> " If a plugin contained its plugin.yaml as part of its wagon archive, 
> then once installed, users could import the yaml file more easily 
> using a notation such as plugins/openstack.yaml (or perhaps 
> openstack.yaml, having the import mechanism iterate over plugins 
> looking for this resource file or so)"
>
> Instead of "plugins/openstack.yaml", I would like to suggest the 
> following
> "plugins: openstack-"
> Please let me know if this fine with you.
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@gigaspaces.com]
> Sent: Thursday, July 20, 2017 6:24 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> It's unassigned, so I don't see why not!
>
> On Thu, Jul 20, 2017 at 7:41 AM, D Jayachandran < 
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Do you have any plans on working on this JIRA issue ?
> > https://issues.apache.org/jira/browse/ARIA-118
> > Can we contribute on this ?
> >
> >
> > Regards,
> > DJ
> >
>