Re: Openstack plugin

[Maxim Orlov]

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

[Tal Liron]

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  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  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 
> > 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"  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 
> > 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"  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 
> > > 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 
> > 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@ericsson.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > >
> > > > > > > > With my understanding in current ARIA, the node instances are
> > > made
> > > > > > unique
> > > > > > > > by prefixing the node name with the 

Re: Unique identification of an instance element across services

[DeWayne Filppi]

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  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 
> 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"  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 
> 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"  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 
> > 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 
> 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@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?

Digest for ASF's Slack

[Digest]

Here’s your digest for today! 
#ariatosca
undefined: [UPDATE] moved all of the topology related methods from the models 
into the instantiation module (which turned into a package). The reporting and 
exception handling mechanism is remain to be remodeled.
undefined: <@U53P75YTD> <@U546PEP9S> can you please subscribe to dev@ using 
your cloudify accounts?
undefined: ah, thanks for reminding us ... our accounts changed automagically 
today, i didn't even notice
 is there a way to change the current account subscription?
undefined: your email addresses changed?
undefined: yes :confused:
 gigaspaces has split into separate business units. long live 
!
 i'm going through ezmlm docs to see how we can do this
 is there a way for the admin to do this in bulk? this would affect all the 
apache mailing lists we are on ...
 apparently there is a "subscribe alternate address" command for ezmlm, but 
that's not exactly what we want to do here
undefined: I can unsubscribe you guys
 if you just subscribe your new emails
undefined: could you do that for the general mailing lists, too, or just aria?
undefined: what general mailing list?
 general@incubator
undefined: here are all the apache mailing lists i am on: dev@ariastosca, 
user@ariatosca, private@ariatosca, general@incubator
 since we are all in different timezones and some are on vacation now, let's 
not unsubscribe anyone, please. (the old @gigaspaces.com addresses will still 
work and forward to the new addressses).
 i will send everyone instructions on how to unsubscribe and resubscribe
 but i guess only private@ariatosca needs your explicit admin?
undefined: yeah
 do you know if arthur and ran resubscribed?
undefined: oops, just occurred to me that we cannot unsubscribe without your 
help :confused: because we can't send messages from the old address to ezmlm to 
unsubscribe :confused:
 i'm sure they did not, the change in addresses literally happened a few hours 
ago
undefined: would you mind dropping them an email internally?
undefined: yes, i will do that
 could you please then unsubscribe me from the following? i will resubscribe 
manually: dev@ariastosca, user@ariatosca, private@ariatosca, general@incubator
undefined: i can unsusbscribe people
undefined: ok, very sorry to have to trouble you with this nonsense. :confused: 
this change was not well thought out for these use cases.
 should i tell people to email you with requests to unsubscribe?
undefined: yeah please
undefined: ok, done. did you also approve/moderate the emails we sent to the 
list today from the new address, or should i resend those?
undefined: yes, i think i got them all
 hence why i came on here to remind you all
undefined: [UPDATE] some progress!

many improvements to the clearwater service template. i finally fixed the issue 
with the Ellis component: apparently i forgot to provision phone numbers. the 
UI error message was not so helpful here...

i also fixed an issue with the Homer component, just to remove a warning 
message about a missing python package.

i think i should open issues on the clearwater project itself for these things.

still, i cannot login to the SIP provider, so there's another issue to fix, but 
at Ellis is working...

RE: Openstack plugin

[D Jayachandran]

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