RE: Openstack plugin

[D Jayachandran]

Hi,

The cloudify openstack plugin has validation interfaces, Do they still hold 
good with ARIA with the use of adapter ?


Regards,
DJ
-Original Message-
From: Ran Ziv [mailto:r...@cloudify.co] 
Sent: Tuesday, August 08, 2017 5:33 AM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Openstack plugin

For future readers of this thread, you can find an example on how to use this 
plugin here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/OpenStack+Hello+World

On Wed, Jul 26, 2017 at 6:25 PM, Maxim Orlov  wrote:

> you got most of it right :). You would need to follow these steps:
> 1. Install the adapter
> 2. Using ARIA, Install the wagon of the plugin.
> 3. Utilize the corresponding plugin.yaml found in the repo in your 
> templates.
>
> The reason the adapter does not come with ARIA is it's an adapter for 
> Cloudify based plugins, and hence it cannot be a part of the ARIA code 
> base.
> In the future ARIA would have its own plugins, and will not need the 
> adapter for Cloudify plugins.
>
> On Wed, Jul 26, 2017 at 12:20 PM, D Jayachandran < 
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Max,
> >
> > IF I understand correctly,
> > we need to take the cloudify openstack plugin and replace 
> > the plugin.yaml with the one found in the repo.
> > Install this updated plugin with ARIA
> > Install the adapter found in this repo to make use of the 
> > plugin
> >
> > Am I right with my understanding ?  Also why this adapter is not 
> > included with ARIA by default ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> > Sent: Monday, July 24, 2017 9:17 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Openstack plugin
> >
> > Hey DJ,
> >
> > Basically ARIA indeed has an adapter for cloudify-based plugins. 
> > This enables support for any cloudify plugins (Provided the 
> > plugin.yaml has
> been
> > translated into TOSCA). Note that later on, ARIA will have native 
> > plugins and will not rely on kindness of Cloudify.
> > You can find the Cloudify repo here
> > . It 
> > holds some examples, the plugin.yaml and the adapter itself.
> >
> > On Mon, Jul 24, 2017 at 2:01 PM, D Jayachandran < 
> > d.jayachand...@ericsson.com
> > > wrote:
> >
> > > Thanks for the information Tal.  What is the adapter which you are 
> > > referring here ?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@gigaspaces.com]
> > > Sent: Friday, July 21, 2017 8:37 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Openstack plugin
> > >
> > > ARIA has an adapter that can use Cloudify plugins, and it has been 
> > > tested successfully with both OpenStack and AWS so far.
> > >
> > > Unfortunately there are no instructions on how to use it. I know 
> > > just the right person to write it and will ask him to do so. :)
> > >
> > > On Fri, Jul 21, 2017 at 3:29 AM, D Jayachandran < 
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Will openstack plugin be available as part of any ARIA release ?
> > > > Is this already been looked upon or in the backlog ?
> > > >
> > > >
> > > > Regards,
> > > > DJ
> > > >
> > >
> >
>

Re: Unique identification of an instance element across services

[Arthur Berezin]

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