date:20170925

Re: Unique identification of an instance element across services

2017-09-25 Thread Tal Liron

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

Planning to remove rosters from active podlings

2017-09-25 Thread John D. Ament

All,

This coming weekend (9/29) I plan to remove the roster sections from all
podling status pages.

Podling rosters are meant to be managed in Whimsy.  The roster in the
status page is redundant and end up out of sync.  In place of the roster, I
will be adding a link automatically to all podling rosters.

John

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

2017-09-25 Thread Steve Baillargeon

Hi
YAML1.0 spec is incorrect for import definitions.
YAML1.2 spec has updated the import grammar as follows.
It will be great for ARIA to support parts of the YAML1.2 spec soon especially 
for areas that are corrected. 

From YAML 1.2 spec:
3.5.8.2 Grammar
Import definitions have one the following grammars:
3.5.8.2.1 Single-line grammar:
imports:
  - 
  - 
3.5.8.2.2 Multi-line grammar
imports:  
  - file: 
repository: 
namespace_uri: 
namespace_prefix: 

-Steve B

-Original Message-
From: Tal Liron [mailto:t...@cloudify.co] 
Sent: Monday, September 25, 2017 11:39 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Contribution for https://issues.apache.org/jira/browse/ARIA-118

So, this is one of the cases where the spec seems to be wrong: the 
 is probably a mistake. None of the other examples in the spec 
have it, nor do we see it in other TOSCA examples.

Note that if we needed an  than it would even have to be for the 
short form. So:

imports:
 - importname1: myfile.yaml
 - importname2: otherfile.yaml
 - importname3:
 file: lastfile.yaml

The above seems wrong (also, what role does the import name have?). In ARIA we 
treated this as an error in the spec, so we do not have the import name.

On Mon, Sep 25, 2017 at 8:52 AM, D Jayachandran  wrote:

> Hi Tal,
>
> As per the grammer in the SPEC, seems the import should take a 
> . Your example dint have a  but started with 
> respository as such.
>
> :
>
>   file: 
>
>   repository: 
>
>   namespace_uri: 
>
>   namespace_prefix: 
>
>
> With your example can we have multiple repositories ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, September 21, 2017 9:31 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> 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 < 
> d.jayachand...@ericsson.com
> > 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: Contribution for https://issues.apache.org/jira/browse/ARIA-118

2017-09-25 Thread Tal Liron

So, this is one of the cases where the spec seems to be wrong: the
 is probably a mistake. None of the other examples in the spec
have it, nor do we see it in other TOSCA examples.

Note that if we needed an  than it would even have to be for
the short form. So:

imports:
 - importname1: myfile.yaml
 - importname2: otherfile.yaml
 - importname3:
 file: lastfile.yaml

The above seems wrong (also, what role does the import name have?). In ARIA
we treated this as an error in the spec, so we do not have the import name.

On Mon, Sep 25, 2017 at 8:52 AM, D Jayachandran  wrote:

> Hi Tal,
>
> As per the grammer in the SPEC, seems the import should take a
> . Your example dint have a  but started with
> respository as such.
>
> :
>
>   file: 
>
>   repository: 
>
>   namespace_uri: 
>
>   namespace_prefix: 
>
>
> With your example can we have multiple repositories ?
>
>
> Regards,
> DJ
>
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Thursday, September 21, 2017 9:31 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Contribution for https://issues.apache.org/
> jira/browse/ARIA-118
>
> 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 <
> d.jayachand...@ericsson.com
> > 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: Contribution for https://issues.apache.org/jira/browse/ARIA-118

2017-09-25 Thread D Jayachandran

Hi Tal,

As per the grammer in the SPEC, seems the import should take a . 
Your example dint have a  but started with respository as such.

:

  file: 

  repository: 

  namespace_uri: 

  namespace_prefix: 


With your example can we have multiple repositories ? 


Regards,
DJ

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

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

Planning to remove rosters from active podlings

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

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

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

5 matches

Site Navigation

Mail list logo

Footer information