Re: Property type 'null' validation issue

[Ran Ziv]

This does sound like a bug, and I am not familiar with a JIRA ticket for
it. Feel free to create one.


On Mon, Sep 18, 2017 at 8:13 AM, Vaishnavi K.R 
wrote:

> Hi,
>
>
> I tried using the 'null' property type as mentioned in the TOSCA simple
> YAML 1.0 specification. I get the validation issue saying that the datatype
> specified in the service template is an unknown datatype.
>
>
> I just surfed through the code and found that 'null' is considered as one
> of the primitive datatypes. But when it is validated if its a primitive
> datatype, a class object of Null() is passed as a value. The validation
> fails as it expects a string value of 'null'.
>
>
> Is this a known issue? Do we have a JIRA item opened for this?
>
>
>
>
> Thanks,
>
> /Vaish
>

Re: Unique identification of an instance element across services

[Ran Ziv]

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 <vaishnavi@ericsson.com>
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 <r...@cloudify.co>
> 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 <tnad...@lucidvision.com>
> wrote:
>
> >
> > > On Sep 15, 2017, at 1:53 PM, Tal Liron <t...@cloudify.co> 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 even if a few different ARIA users are using the same cloud
> > > accounts (each ARIA install could create its own "database_1" -- what
> if
> > > you have two hosts with that same DNS name?).
> >
> > I was just going to say the point you made above about DNS name
> > overlap.
> > It sounds like we need to sit down and re-visit the serial number
> > management?
> >
> > —Tom
> >
> >
> > >
> > >
> > > On Fri, Sep 15, 2017 at 12:35 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > >> I get the feeling that you are more gifted typist than most.  Or are
> you
> > >> saying nobody will ever be required to type in one those IDs?
> > >>
> > >> On Fri, Sep 15, 2017 at 9:27 AM, Tal Liron <t...@cloudify.co> wrote:
> > >>
> > >>&g

Re: Unique identification of an instance element across services

[Ran Ziv]

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 even if a few different ARIA users are using the same cloud
> > accounts (each ARIA install could create its own "database_1" -- what if
> > you have two hosts with that same DNS name?).
>
> I was just going to say the point you made above about DNS name
> overlap.
> It sounds like we need to sit down and re-visit the serial number
> management?
>
> —Tom
>
>
> >
> >
> > On Fri, Sep 15, 2017 at 12:35 PM, DeWayne Filppi 
> > wrote:
> >
> >> I get the feeling that you are more gifted typist than most.  Or are you
> >> saying nobody will ever be required to type in one those IDs?
> >>
> >> On Fri, Sep 15, 2017 at 9:27 AM, Tal Liron  wrote:
> >>
> >>> Before we allow users to configure this, we have another JIRA to
> resolve:
> >>> actually, we don't have a mechanism for storing configuration yet! Here
> >> is
> >>> the open JIRA:
> >>>
> >>> https://issues.apache.org/jira/browse/ARIA-229
> >>>
> >>> As for what to configure in this case, our practice until now was that
> >> the
> >>> UUID would be added as an underscored postfix of the object's name. So
> if
> >>> you have a node template named "database" then node instances could be,
> >>> assuming longest form of UUID (alphanumeric, 36 characters):
> >>>
> >>> database_2d79fd86-0877-49ca-81d8-cd2dc9f7b0e2
> >>> database_2819972e-3b07-4923-be94-43e95985155f
> >>> database_45b9faf5-8bf4-482a-a570-d1c058270424
> >>>
> >>> This guarantees names that are universally unique and yet still
> >> meaningful:
> >>> you would be able to tell at a glance what kind of node this is: a
> >>> database. Note that we also have a mechanism in place to warn you if
> the
> >>> final name is more than 63 characters, because such names can't be used
> >> as
> >>> DNS hostnames (a common usage for node names in the cloud). This should
> >>> also be configurable.
> >>>
> >>> I don't see why this needs to be abstracted from the user. If you are
> >> using
> >>> the CLI and see the list of nodes, you can refer to the node you are
> >>> examining with the full name as seen above. I think having a separate
> UI
> >>> name such as "database_1", "database_2', etc., would be confusing.
> >>>
> >>> So, assuming the above, I imagine these kinds of configuration vars:
> >>>
> >>> instance.id_type = 'uuid' | 'alphanumeric' | 'base57' (default?) |
> >> 'serial'
> >>> node.id_max_length = 63
> >>>
> >>> Here are examples of the other types. Alphanumeric (25 characters):
> >>>
> >>> database_t5evps77wp5biqdb1oyw36956
> >>> database_uw5oa530kn9mu73lzjuech02a
> >>> database_nzv3a7umph0g1093abwq6qjd3
> >>>
> >>> And base57 (22 characters):
> >>>
> >>> database_g8KV4qpKep2J2uA473fv6X
> >>> database_M2bLkYsToZ52L3HSy7CCmC
> >>> database_q8se9o5fDDWvT53tnnRiXN
> >>>
> >>> My personal preference for the default has always been base57. It is
> both
> >>> the most compact, meaning less of a chance you would hit the 63
> character
> >>> limit, and also cleverly designed for human readability (no
> >>> visually-ambiguous glyphs).
> >>>
> >>>
> >>>
> >>> 

Re: Use & impact of role/host attribute in ARIA

[Ran Ziv]

t; > relationships are special, as are certain capabilities, data types,
> > > etc. In order to avoid having ARIA look for a specific type name, it
> > > checks the "role" extension. Internally, "role" is inherited (and can
> > > be overridden), so that anything that inherits from
> > > tosca.nodes.Compute, for example, would also have the "host" role.
> > > (For past versions of the NFV Profile, we likely had the VDU type as
> > > having "host" role, even though it did not inherit from
> > tosca.nodes.Compute).
> > >
> > > Then execution plug tries to find out if the operation is hosted
> > > remotely by seeing if the node is hosted: either a host itself, or has
> > > a relationship to a node that is hosted. I'll leave it to Ran to
> > > explain why this needs to be the case. :)
> > >
> > >
> > >
> > > On Wed, Sep 6, 2017 at 6:27 AM, Ran Ziv <r...@cloudify.co> wrote:
> > >
> > > > (I'll let Tal take this one :P)
> > > >
> > > > On Wed, Sep 6, 2017 at 2:26 PM, D Jayachandran <
> > > > d.jayachand...@ericsson.com>
> > > > wrote:
> > > >
> > > > > Yes, I can see that Ran. So that was my question , why was role
> > > > > being added to the types ?
> > > > > TOSCA spec does not say about a parameter called role. I feel this
> > > > > is not aligned with TOSCA spec.
> > > > >
> > > > > Regards,
> > > > > DJ
> > > > >
> > > > > -Original Message-
> > > > > From: Ran Ziv [mailto:r...@cloudify.co]
> > > > > Sent: Wednesday, September 06, 2017 2:16 PM
> > > > > To: dev@ariatosca.incubator.apache.org
> > > > > Subject: Re: Use & impact of role/host attribute in ARIA
> > > > >
> > > > > This is where the execution plugin decides whether to run locally
> > > > > or remotely (ssh):
> > > > > https://github.com/apache/incubator-ariatosca/blob/0.1.
> > > > > 1/aria/orchestrator/execution_plugin/instantiation.py#L42
> > > > >
> > > > > This is indeed related to the "host" role definition.
> > > > >
> > > > > Here you can see the assignment of the "host" role to the Compute
> > type:
> > > > > https://github.com/apache/incubator-ariatosca/blob/
> > > > > 1e883c57abb733b10e13f0b7005cf564886d3fb1/extensions/aria_
> > > > > extension_tosca/profiles/tosca-simple-1.0/nodes.yaml#L63
> > > > >
> > > > >
> > > > > Ran
> > > > >
> > > > > On Wed, Sep 6, 2017 at 10:07 AM, D Jayachandran <
> > > > > d.jayachand...@ericsson.com
> > > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I just noticed the "role" attribute is added for different
> > > "capability"
> > > > > > and "node" types in ARIA profiles. There is no such role with
> > > > > > the TOSCA spec.
> > > > > > Why is this been added in the profiles ? What is the use of them
> ?
> > > > > >
> > > > > > I faced an issue when I run a local script as part of the
> > > > > > Interface operation. The script was provided to the execution
> > > > > > plugin as "run_script_with_ssh" rather than "run_script_locally".
> > > > > > The "role" seemed to have a saying on deciding this. Based on
> > > > > > this role a host is being added to any node instance. With the
> > > > > > host being set a script is configured either as "
> > run_script_with_ssh"
> > > > > > rather than "run_script_locally".
> > > > > >
> > > > > > So I want to understand under which cicumstances is a host being
> > > > > > added to a node and which decided if the script execution is
> > > > > > local
> > > or ssh ?
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > DJ
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Selecting and installing a specific stack

[Ran Ziv]

In your example, did you mean that the pairs A, B, C are supposedly
of the same "abstract type" (e.g. C are both DBs, etc.)?
If so, substitution mapping might be useful here as well.
Otherwise, I'm not really sure why you'd see the two templates as "linked"
or similar in any way.



On Sat, Sep 9, 2017 at 2:09 AM, Tal Liron  wrote:

> The only thing you can configure in pure TOSCA is the inputs, so it's not
> so easy a problem to solve. If we have node templates for all the nodes, we
> could configure their requirements for each using intrinsic functions that
> rely on the inputs, so that the final topology could change.
>
> Let me try to show this with a simpler example, where we have nodes A and B
> and want to pick between them. Node Z could use either one of them
> depending on the input:
>
> topology_template:
>   inputs:
> node_choice:
>   type: string
>   default: A
>   node_templates:
> A:
>   type: MyNode1
> B:
>   type: MyNode2
> Z:
>   type: MyNode3
>   requirements:
> - stack:
> capability: MyCap
> node: { get_input: node_choice }
>
> The problem in this case is that both nodes A and B will be instantiated
> whatever the topology, though there will be only one relationship. If you
> want to the unwanted node to not be instantiated, you need to set its
> default_instances to 0:
>
>   node_templates:
> A:
>   type: MyNode1
>   capabilities:
> scalable:
>   properties:
> default_instances: 0
>
> Two challenges with this:
>
> 1) The expression language in TOSCA is quite thin, so there's no way to do
> an "if" to set default_instances to 0 or 1 depending on the choice. So, we
> would likely have to add more inputs:
>
> topology_template:
>   inputs:
> node_choice:
>   type: string
>   default: A
> A.instances:
>   type: integer
>   default: 1
> B.instances:
>   type: integer
>   default: 0
>   node_templates:
> A:
>   type: MyNode1
>   capabilities:
> scalable:
>   properties:
> default_instances: { get_input: A.instances }
> B: ...
>
> 2) Another problem is that TOSCA normative types only give the "scalable"
> capability to Compute nodes. If your nodes do not inherit from Compute, you
> can either declare the tosca.capabilities.Scalable capability yourself for
> your node types, or with ARIA use the aria.Scaling policy:
> https://cwiki.apache.org/confluence/display/ARIATOSCA/Types
>
> The above is all rather complicated and awkward. This scenario is rather
> poorly handled in pure TOSCA.
>
> I think it's better solved at this point by a higher-level tool that can
> generate the TOSCA YAML code for you according to your needs. ARIA
> intrinsically supports Jinja templates if your service templates end with a
> ".yaml.jinja" extension. With Jinja you have much richer programming logic:
> "if" control flow, "for" loops, etc. So you can generate your final service
> template more powerfully.
>
>
> On Fri, Sep 8, 2017 at 3:56 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > I have a service template with 2 stacks.
> > Stack 1 has nodes A, B and C.
> > Stack 2 has nodes D, E and F.
> > Both stacks must be defined in the same service template.
> >
> > What is the easiest way to describe a service template allowing the ARIA
> > user/orchestrator to select one of them for instantiation?
> > Is it with groups?
> >
> > Regards
> > Steve B
> >
> >
>

Re: operation dependencies

[Ran Ziv]

Avia's mentioned at one point that we might have misunderstood the spec at
this section, and that in fact it can be possible to pass arbitrary inputs
into operations regardless of the interface definition - which would mean
this notion of  "configuration" might be unnecessary.

Also, note that the doc page is talking about "executors", which is
confusing as that's a different concept in ARIA (see the base executor
class); Supposedly up until now we've simply called these "operation
plugins".


On Sat, Sep 9, 2017 at 1:43 AM, Tal Liron  wrote:

> Yes:
> https://cwiki.apache.org/confluence/display/ARIATOSCA/
> Execution+Configuration
>
> On Fri, Sep 8, 2017 at 4:45 PM, DeWayne Filppi 
> wrote:
>
> > I see in the examples a list of dependencies for scripts in operations,
> for
> > example:
> >
> > implementation:
> >   primary: scripts/configure.sh
> >   dependencies:
> > - "ssh.user > { get_input: ssh_username }"
> > - "ssh.key_filename > { get_input: private_key_path }"
> > - "ssh.address > { get_attribute: [ virtual_ip,
> > floating_ip_address ] }"
> >
> > The spec seems to indicate that the dependency list is for resources that
> > need to be made available so the main script can be run.  Clearly that
> > isn't the case in the example.  Is this '>' syntax documented anywhere?
> >
>

Re: openstack plugin

[Ran Ziv]

In TOSCA, properties must have a well-defined schema, and as such it means
that the "server" property's datatype must be defined to have the
"userdata" field for users to be able to use it through there.

This is also true for operation inputs at this time, although AFAIK the
spec does in fact allow for more freedom when it comes to passing operation
inputs which weren't defined in a schema - but we don't support that at
this time.


On Thu, Sep 7, 2017 at 1:08 AM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> Rather than opening a potentially misguided PR, let me ask a simple
> question whos answer may clear things up:  I want to use server "userdata"
> using the Openstack plugin from ARIA.  The question is "how can I make that
> happen?"
>
> On Wed, Sep 6, 2017 at 1:39 AM, Ran Ziv <r...@cloudify.co> wrote:
>
> > Well then, feel free to create an issue, and either submit the smaller
> fix,
> > or create a PR which goes beyond this as you say :)
> >
> >
> > On Tue, Sep 5, 2017 at 6:52 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > Yes, I believe you've got the idea.  The original "server" arg is
> defined
> > > as a map/dict.  TOSCA of course requires something somewhat more
> > explicit.
> > > I'm working around it by adding the following to Server datatype:
> > >
> > >   aria.openstack.datatypes.Server:
> > > description: >-
> > >   openstack Server args.
> > > properties:
> > >   server:
> > > type: map
> > > required: false
> > > entry_schema:
> > >   type: string
> > >   security_groups:
> > > type: list
> > > entry_schema: string
> > > required: false
> > >   availability_zone:
> > > type: string
> > > required: false
> > >
> > > I have my own copy of the plugin.yaml file that I'm making changes to
> so
> > > things will work for me, so this is fine.  I think the PR needs to go
> > > beyond this, and ensure that all potential parameters are defined ( or
> at
> > > least the parameters that the Openstack plugin recognizes).
> > >
> > >
> > >
> > > On Sun, Sep 3, 2017 at 12:26 AM, Ran Ziv <r...@cloudify.co> wrote:
> > >
> > > > Could you link to the relevant place?
> > > > Do you mean that in the original plugin.yaml you could set the
> userdata
> > > > field (under properties? under the "server" property? args?) but only
> > due
> > > > to it not having had to be declared explicitly?
> > > > There's a good chance that if this were possible than it simply got
> > > omitted
> > > > during translation by mistake.
> > > > Feel free to create a PR and add that.
> > > >
> > > > As a workaround, I assume you can simply inherit the type.
> > > >
> > > >
> > > > On Sat, Sep 2, 2017 at 7:02 PM, DeWayne Filppi <dewa...@cloudify.co>
> > > > wrote:
> > > >
> > > > > The openstack plugin.yaml replacement doesn't permit userdata.
> > Unlike
> > > > the
> > > > > regular plugin.yaml, the args contents are specifically defined,
> and
> > > that
> > > > > definition excludes userdata.  Is this a problem or is there some
> > kind
> > > of
> > > > > workaround?
> > > > >
> > > >
> > >
> >
>

Re: Use & impact of role/host attribute in ARIA

[Ran Ziv]

(I'll let Tal take this one :P)

On Wed, Sep 6, 2017 at 2:26 PM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Yes, I can see that Ran. So that was my question , why was role being
> added to the types ?
> TOSCA spec does not say about a parameter called role. I feel this is not
> aligned with TOSCA spec.
>
> Regards,
> DJ
>
> -----Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]
> Sent: Wednesday, September 06, 2017 2:16 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Use & impact of role/host attribute in ARIA
>
> This is where the execution plugin decides whether to run locally or
> remotely (ssh):
> https://github.com/apache/incubator-ariatosca/blob/0.1.
> 1/aria/orchestrator/execution_plugin/instantiation.py#L42
>
> This is indeed related to the "host" role definition.
>
> Here you can see the assignment of the "host" role to the Compute type:
> https://github.com/apache/incubator-ariatosca/blob/
> 1e883c57abb733b10e13f0b7005cf564886d3fb1/extensions/aria_
> extension_tosca/profiles/tosca-simple-1.0/nodes.yaml#L63
>
>
> Ran
>
> On Wed, Sep 6, 2017 at 10:07 AM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > I just noticed the "role" attribute is added for different "capability"
> > and "node" types in ARIA profiles. There is no such role with the
> > TOSCA spec.
> > Why is this been added in the profiles ? What is the use of them ?
> >
> > I faced an issue when I run a local script as part of the Interface
> > operation. The script was provided to the execution plugin as
> > "run_script_with_ssh" rather than "run_script_locally".
> > The "role" seemed to have a saying on deciding this. Based on this
> > role a host is being added to any node instance. With the host being
> > set a script is configured either as " run_script_with_ssh" rather
> > than "run_script_locally".
> >
> > So I want to understand under which cicumstances is a host being added
> > to a node and which decided if the script execution is local or ssh ?
> >
> >
> > Regards,
> > DJ
> >
>

Re: Use & impact of role/host attribute in ARIA

[Ran Ziv]

This is where the execution plugin decides whether to run locally or
remotely (ssh):
https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/orchestrator/execution_plugin/instantiation.py#L42

This is indeed related to the "host" role definition.

Here you can see the assignment of the "host" role to the Compute type:
https://github.com/apache/incubator-ariatosca/blob/1e883c57abb733b10e13f0b7005cf564886d3fb1/extensions/aria_extension_tosca/profiles/tosca-simple-1.0/nodes.yaml#L63


Ran

On Wed, Sep 6, 2017 at 10:07 AM, D Jayachandran  wrote:

> Hi,
>
> I just noticed the "role" attribute is added for different "capability"
> and "node" types in ARIA profiles. There is no such role with the TOSCA
> spec.
> Why is this been added in the profiles ? What is the use of them ?
>
> I faced an issue when I run a local script as part of the Interface
> operation. The script was provided to the execution plugin as
> "run_script_with_ssh" rather than "run_script_locally".
> The "role" seemed to have a saying on deciding this. Based on this role a
> host is being added to any node instance. With the host being set a script
> is configured either as " run_script_with_ssh" rather than
> "run_script_locally".
>
> So I want to understand under which cicumstances is a host being added to
> a node and which decided if the script execution is local or ssh ?
>
>
> Regards,
> DJ
>

Re: openstack plugin

[Ran Ziv]

Well then, feel free to create an issue, and either submit the smaller fix,
or create a PR which goes beyond this as you say :)


On Tue, Sep 5, 2017 at 6:52 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> Yes, I believe you've got the idea.  The original "server" arg is defined
> as a map/dict.  TOSCA of course requires something somewhat more explicit.
> I'm working around it by adding the following to Server datatype:
>
>   aria.openstack.datatypes.Server:
> description: >-
>   openstack Server args.
> properties:
>   server:
> type: map
> required: false
> entry_schema:
>   type: string
>   security_groups:
> type: list
> entry_schema: string
> required: false
>   availability_zone:
> type: string
> required: false
>
> I have my own copy of the plugin.yaml file that I'm making changes to so
> things will work for me, so this is fine.  I think the PR needs to go
> beyond this, and ensure that all potential parameters are defined ( or at
> least the parameters that the Openstack plugin recognizes).
>
>
>
> On Sun, Sep 3, 2017 at 12:26 AM, Ran Ziv <r...@cloudify.co> wrote:
>
> > Could you link to the relevant place?
> > Do you mean that in the original plugin.yaml you could set the userdata
> > field (under properties? under the "server" property? args?) but only due
> > to it not having had to be declared explicitly?
> > There's a good chance that if this were possible than it simply got
> omitted
> > during translation by mistake.
> > Feel free to create a PR and add that.
> >
> > As a workaround, I assume you can simply inherit the type.
> >
> >
> > On Sat, Sep 2, 2017 at 7:02 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > The openstack plugin.yaml replacement doesn't permit userdata.  Unlike
> > the
> > > regular plugin.yaml, the args contents are specifically defined, and
> that
> > > definition excludes userdata.  Is this a problem or is there some kind
> of
> > > workaround?
> > >
> >
>

Re: error after adding "userdata" or "user_data" to plugin.yaml

[Ran Ziv]

DeWayne, highlighting doesn't work too well with the mailing list - we only
see simple text.

The error doesn't ring a bell here.


On Wed, Sep 6, 2017 at 8:43 AM, DeWayne Filppi  wrote:

> I have no idea if its a bug.  Just seeing if it looked familiar to anyone.
> Thought that error message might ring a bell.
>
> On Sep 5, 2017 10:33 PM, "Tal Liron"  wrote:
>
> > Are you reporting a bug here? It would really help to get a complete
> > example with instructions to reproduce.
> >
> > On Tue, Sep 5, 2017 at 7:07 PM, DeWayne Filppi 
> > wrote:
> >
> > > After adding the highlighted content to the ARIA openstack plugin.yaml,
> > >
> > >   aria.openstack.datatypes.Server:
> > > description: >-
> > >   openstack Server args.
> > > properties:
> > >   server:
> > > type: map
> > > required: false
> > > entry_schema:
> > >   type: string
> > >
> > > I get the following error trying to use user_data in a template:
> > >
> > > RuntimeError: Re-definition of yaml-1.1 in specification_url
> > >
> > > Usage looks like:
> > >
> > >   openstack_config: { get_input: openstack_config }
> > >   args:
> > > server:
> > >   user_data: |
> > > #!/bin/sh
> > > echo TEST > /tmp/out
> > >
> >
>

Re: Service Composition / Substitution Mapping

[Ran Ziv]

to implicitly import that custom node type in our top level
> service
> > > template so that the parser recognizes this custom type.
> > > Assuming the abstract node type would be substituted from a
> > stored
> > > substituting service template, we need to at least import the custom
> node
> > > types and have it part of the same CSAR package.
> > > Would this be a challenge for the top-level service template
> > > author in including and importing the custom node types as abstraction
> ?
> > or
> > > Is this how we are looking at custom node types ?
> > > Is it possible to identify an abstract node during parsing ,
> such
> > > as if it does not contain any implementation ( The SPEC does not say
> > > anything on this )?
> > >
> > > Regards,
> > > DJ
> > > -Original Message-
> > > From: Ran Ziv [mailto:r...@cloudify.co]
> > > Sent: Wednesday, August 16, 2017 6:19 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Service Composition / Substitution Mapping
> > >
> > > I agree, especially when the benefit of being able to use an existing
> > > service - yet only one which hasn't been deployed via a workflow -
> > doesn't
> > > seem all that interesting IMO.
> > >
> > > Another concern I could add to the ones you've mentioned is the
> service's
> > > inputs - the substituting template's inputs should be received via the
> > > properties of the abstract node in the top level service template. If
> the
> > > service already exists, these inputs would not be passed as expected.
> > >
> > > Ran
> > >
> > > On Wed, Aug 16, 2017 at 3:25 PM, D Jayachandran <
> > > d.jayachand...@ericsson.com
> > > > wrote:
> > >
> > > > Hi Ran,
> > > >
> > > > When Tal mentioned about "substituting service", I thought it was
> > > > about the services which dint have any associated
> executions/workflows
> > > triggered.
> > > > Am also in favor of  "substituting service templates" rather than
> > > > "substituting service".
> > > > With "substituting service" approach (when the service is not
> > > > instantiated), I see some open points
> > > > - In a multi-user scenario, what will happen when a service
> is
> > > > composed using the substituting service and at the sametime a
> > > > workflow is triggered for the substituting service. ?
> > > > - Is it okay to delete(dissolve) the substituting service
> > > > after it is used to create the composed service. ?
> > > >
> > > > Starting with it might be a good idea to only have "substituting
> > > > service templates" approach.
> > > >
> > > > Regards,
> > > > DJ
> > > > -Original Message-
> > > > From: Ran Ziv [mailto:r...@cloudify.co]
> > > > Sent: Wednesday, August 16, 2017 4:29 PM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: Service Composition / Substitution Mapping
> > > >
> > > > I'd say right now we're looking at "static service composition" which
> > > > is only about "substituting service templates", not "substituting
> > > > service". If a service is already running, it will not be used.
> > > >
> > > > I think what Tal meant was that each service template - whether the
> > > > top level one or one of the substituting templates - needs to resolve
> > > > its inner reqs internally first, and then resolve substitution
> > > > reqs across service templates.
> > > >
> > > >
> > > > On Wed, Aug 16, 2017 at 12:00 PM, D Jayachandran <
> > > > d.jayachand...@ericsson.com> wrote:
> > > >
> > > > > Hi Tal,
> > > > >
> > > > > Thanks for organizing the points.
> > > > > So if I understand correctly we are looking only at "Static service
> > > > > composition" which includes "substituting service template" and
> > > > > "substituting service".
> > > > >
> > > > > As you said with "substituting service template" approach ,we will
> > > > > have all the nodes aggregated from other service templates and a
> > > > > single workflow would 

Re: server create problem

[Ran Ziv]

Got it. I created this JIRA issue for this:
https://issues.apache.org/jira/browse/ARIA-357


On Sat, Sep 2, 2017 at 7:00 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> IMHO, ARIA needs to detect ( or attempt to detect ) such things, at least
> at install time if possible.
>
> On Sat, Sep 2, 2017 at 2:41 AM, Ran Ziv <r...@cloudify.co> wrote:
>
> > You're right. The plugin itself does declare specific versions for the
> > novaclient:
> > https://github.com/cloudify-cosmo/cloudify-openstack-
> > plugin/blob/2.0.1/setup.py
> > Yet those might not be used if you already have these dependencies
> > installed in your environment.
> >
> > Supposedly, you want to work with ARIA on its own virtualenv (i.e. not
> have
> > Openstack clients installed there manually), since all plugins that get
> > installed are isolated from one another yet do take your general ARIA
> > environment into account as constraints. Otherwise, a plugin installation
> > might have messed something else you had installed in your environment.
> > See here:
> > https://github.com/apache/incubator-ariatosca/blob/0.1.
> > 1/aria/orchestrator/plugin.py#L155
> >
> > I'm not sure an issue for this should be created, or at least if we
> create
> > one it should probably be for information, rather than something that
> > requires fixing, I think.
> >
> > -
> > Re ARIA not having an API for removing plugins - yup, that's missing at
> > this time.
> >
> >
> >
> >
> >
> > On Fri, Sep 1, 2017 at 9:35 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > So the problem was that recent versions of the python-novaclient do not
> > > have the expected properties.  Alas, the plugin install ignored the
> fact
> > > that I had a non-compliant version (the latest), and just installed as
> > > normal.  Maybe this needs to be an issue with the plugin installer?
> > >
> > > On Fri, Sep 1, 2017 at 9:31 AM, DeWayne Filppi <dewa...@cloudify.co>
> > > wrote:
> > >
> > > > Alas, no change:
> > > >
> > > > 04:05:57 | I | nova_plugin.server.create | {u'args': OrderedDict(),
> > > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > > 'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
> > > > https://rackspace-api.gigaspaces.com:5000/v3'}} | EXCEPTION:
> 'Client'
> > > > object has no attribute 'images'
> > > >
> > > > Seems unrelated to ARIA.
> > > >
> > > >
> > > > On Fri, Sep 1, 2017 at 2:28 AM, Ran Ziv <r...@cloudify.co> wrote:
> > > >
> > > >> Shouldn't the Nova client actually have an "images" attribute?
> > > >>
> > > >> The plugin was tested in its 2.0.1 version, as can be seen on the
> > README
> > > >> here:
> > > >> https://github.com/cloudify-cosmo/aria-extension-cloudify
> > > >>
> > > >> Here's the plugin code diff between now (~2.2.0) and then:
> > > >> https://github.com/cloudify-cosmo/cloudify-openstack-plugin/
> > > >> compare/2.0.1-devel...master
> > > >>
> > > >> Can't really say I see anything that would cause this, but perhaps
> you
> > > >> should indeed try working with a 2.0.1 wagon.
> > > >> If that works let us know and we could possibly amend the plugin
> > adapter
> > > >> if
> > > >> needed.
> > > >>
> > > >>
> > > >>
> > > >> On Fri, Sep 1, 2017 at 5:41 AM, DeWayne Filppi <dewa...@cloudify.co
> >
> > > >> wrote:
> > > >>
> > > >> > I dug down quite a bit, and see that in
> > openstack_plugin_common.__init
> > > >> __
> > > >> > in
> > > >> > the cosmo_list method of the NovaClientWithSugar class, I wrapped
> a
> > > >> call to
> > > >> > getattr with a try:except and see.
> > > >> >
> > > >> > 02:22:47 | I | nova_plugin.server.create | {u'args':
> OrderedDict(),
> > > >> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > >> > 'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
> > > >> > https://rackspace-api.gigaspaces.com:5000/v3'}} |
> > > >> COSMO_EXCEPTION='Client'
> > > >> > object has no attribute 'images'
> > > >> >
> > &g

Re: openstack plugin

[Ran Ziv]

Could you link to the relevant place?
Do you mean that in the original plugin.yaml you could set the userdata
field (under properties? under the "server" property? args?) but only due
to it not having had to be declared explicitly?
There's a good chance that if this were possible than it simply got omitted
during translation by mistake.
Feel free to create a PR and add that.

As a workaround, I assume you can simply inherit the type.


On Sat, Sep 2, 2017 at 7:02 PM, DeWayne Filppi  wrote:

> The openstack plugin.yaml replacement doesn't permit userdata.  Unlike the
> regular plugin.yaml, the args contents are specifically defined, and that
> definition excludes userdata.  Is this a problem or is there some kind of
> workaround?
>

Re: server create problem

[Ran Ziv]

You're right. The plugin itself does declare specific versions for the
novaclient:
https://github.com/cloudify-cosmo/cloudify-openstack-plugin/blob/2.0.1/setup.py
Yet those might not be used if you already have these dependencies
installed in your environment.

Supposedly, you want to work with ARIA on its own virtualenv (i.e. not have
Openstack clients installed there manually), since all plugins that get
installed are isolated from one another yet do take your general ARIA
environment into account as constraints. Otherwise, a plugin installation
might have messed something else you had installed in your environment.
See here:
https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/orchestrator/plugin.py#L155

I'm not sure an issue for this should be created, or at least if we create
one it should probably be for information, rather than something that
requires fixing, I think.

-
Re ARIA not having an API for removing plugins - yup, that's missing at
this time.





On Fri, Sep 1, 2017 at 9:35 PM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> So the problem was that recent versions of the python-novaclient do not
> have the expected properties.  Alas, the plugin install ignored the fact
> that I had a non-compliant version (the latest), and just installed as
> normal.  Maybe this needs to be an issue with the plugin installer?
>
> On Fri, Sep 1, 2017 at 9:31 AM, DeWayne Filppi <dewa...@cloudify.co>
> wrote:
>
> > Alas, no change:
> >
> > 04:05:57 | I | nova_plugin.server.create | {u'args': OrderedDict(),
> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > 'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
> > https://rackspace-api.gigaspaces.com:5000/v3'}} | EXCEPTION: 'Client'
> > object has no attribute 'images'
> >
> > Seems unrelated to ARIA.
> >
> >
> > On Fri, Sep 1, 2017 at 2:28 AM, Ran Ziv <r...@cloudify.co> wrote:
> >
> >> Shouldn't the Nova client actually have an "images" attribute?
> >>
> >> The plugin was tested in its 2.0.1 version, as can be seen on the README
> >> here:
> >> https://github.com/cloudify-cosmo/aria-extension-cloudify
> >>
> >> Here's the plugin code diff between now (~2.2.0) and then:
> >> https://github.com/cloudify-cosmo/cloudify-openstack-plugin/
> >> compare/2.0.1-devel...master
> >>
> >> Can't really say I see anything that would cause this, but perhaps you
> >> should indeed try working with a 2.0.1 wagon.
> >> If that works let us know and we could possibly amend the plugin adapter
> >> if
> >> needed.
> >>
> >>
> >>
> >> On Fri, Sep 1, 2017 at 5:41 AM, DeWayne Filppi <dewa...@cloudify.co>
> >> wrote:
> >>
> >> > I dug down quite a bit, and see that in openstack_plugin_common.__init
> >> __
> >> > in
> >> > the cosmo_list method of the NovaClientWithSugar class, I wrapped a
> >> call to
> >> > getattr with a try:except and see.
> >> >
> >> > 02:22:47 | I | nova_plugin.server.create | {u'args': OrderedDict(),
> >> > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> >> > 'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
> >> > https://rackspace-api.gigaspaces.com:5000/v3'}} |
> >> COSMO_EXCEPTION='Client'
> >> > object has no attribute 'images'
> >> >
> >> > Maybe somebody who wrote this logic can help. Basically, the logic
> take
> >> the
> >> > 'image' property, makes it plural, and then tries to find it in the
> >> client
> >> > class.  It doesn't find it and it blows up.  Maybe I've got a bad
> >> version
> >> > of the openstack plugin:  2.2.0
> >> >
> >> >
> >> > On Thu, Aug 31, 2017 at 12:53 AM, Ran Ziv <r...@cloudify.co> wrote:
> >> >
> >> > > Is this everything?
> >> > > It seems like this never reached the actual API call telling Nova to
> >> > create
> >> > > a server, but rather failed in the section where image/flavor,
> >> keypair,
> >> > > security groups and nics are configured for the server
> >> > > ( see
> >> > > https://github.com/cloudify-cosmo/cloudify-openstack-
> >> > > plugin/blob/master/nova_plugin/server.py#L282
> >> > > )
> >> > >
> >> > > Unfortunately it seems like the trace from the plugin code hasn't
> >> reached
> >> > > the execution logs somehow (possibly something we've missed in the
> 

Re: server create problem

[Ran Ziv]

Shouldn't the Nova client actually have an "images" attribute?

The plugin was tested in its 2.0.1 version, as can be seen on the README
here:
https://github.com/cloudify-cosmo/aria-extension-cloudify

Here's the plugin code diff between now (~2.2.0) and then:
https://github.com/cloudify-cosmo/cloudify-openstack-plugin/compare/2.0.1-devel...master

Can't really say I see anything that would cause this, but perhaps you
should indeed try working with a 2.0.1 wagon.
If that works let us know and we could possibly amend the plugin adapter if
needed.



On Fri, Sep 1, 2017 at 5:41 AM, DeWayne Filppi <dewa...@cloudify.co> wrote:

> I dug down quite a bit, and see that in openstack_plugin_common.__init__
> in
> the cosmo_list method of the NovaClientWithSugar class, I wrapped a call to
> getattr with a try:except and see.
>
> 02:22:47 | I | nova_plugin.server.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'viBKwW4E', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | COSMO_EXCEPTION='Client'
> object has no attribute 'images'
>
> Maybe somebody who wrote this logic can help. Basically, the logic take the
> 'image' property, makes it plural, and then tries to find it in the client
> class.  It doesn't find it and it blows up.  Maybe I've got a bad version
> of the openstack plugin:  2.2.0
>
>
> On Thu, Aug 31, 2017 at 12:53 AM, Ran Ziv <r...@cloudify.co> wrote:
>
> > Is this everything?
> > It seems like this never reached the actual API call telling Nova to
> create
> > a server, but rather failed in the section where image/flavor, keypair,
> > security groups and nics are configured for the server
> > ( see
> > https://github.com/cloudify-cosmo/cloudify-openstack-
> > plugin/blob/master/nova_plugin/server.py#L282
> > )
> >
> > Unfortunately it seems like the trace from the plugin code hasn't reached
> > the execution logs somehow (possibly something we've missed in the plugin
> > adapter?), so I can't really say what's the exact problem.
> > It should be fairly simple to debug though - the plugin code should be
> > extracted inside your ~/.aria/plugins dir, so you can easily debug the
> > plugin code while it's running and find the real problem as it happens.
> >
> >
> > On Wed, Aug 30, 2017 at 7:28 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > The log:
> > >
> > > Starting execution. Press Ctrl+C cancel
> > > 16:13:43 | I | neutron_plugin.router.create | {u'args': OrderedDict(),
> > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > https://rackspace-api.gigaspaces.com:5000/v3'}} | router_1
> > Standard.create
> > > started...
> > > 16:13:44 | I | neutron_plugin.network.create | {u'args': OrderedDict(),
> > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > > Standard.create
> > > started...
> > > 16:13:44 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > https://rackspace-api.gigaspaces.com:5000/v3'}} | keypair_1
> > > Standard.create
> > > started...
> > > 16:13:51 | I | neutron_plugin.network.create | {u'args': OrderedDict(),
> > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > https://rackspace-api.gigaspaces.com:5000/v3'}} | network_1
> > > Standard.create
> > > successful
> > > 16:13:51 | D | None | {} | network_1 Standard.configure has no
> > > implementation
> > > 16:13:51 | D | None | {} | network_1 Standard.start has no
> implementation
> > > 16:13:52 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > https://rackspace-api.gigaspaces.com:5000/v3'}} | Using external
> > resource
> > > keypair: dfilppi-rs
> > > 16:13:52 | I | nova_plugin.keypair.create | {u'args': OrderedDict(),
> > > u'openstack_config': {'username': 'dewayne', 'tenant_name':
> > > 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> > > https://rackspace-api.gigaspaces.com:5000/v3

Re: server create problem

[Ran Ziv]

nect_subnet |
> {u'openstack_config':
> {'username': 'dewayne', 'tenant_name': 'dewayne-tenant', 'password':
> 'xxx', 'auth_url': 'https://rackspace-api.gigaspaces.com:5000/v3'}} |
> subnet_1->router_1 Configure.add_target started...
> 16:14:12 | I | neutron_plugin.router.connect_subnet |
> {u'openstack_config':
> {'username': 'dewayne', 'tenant_name': 'dewayne-tenant', 'password':
> 'xxx', 'auth_url': 'https://rackspace-api.gigaspaces.com:5000/v3'}} |
> subnet_1->router_1 Configure.add_target successful
> 16:14:15 | I | neutron_plugin.port.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | port_1 Standard.create
> started...
> 16:14:20 | I | neutron_plugin.port.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | port_1 Standard.create
> successful
> 16:14:21 | D | None | {} | port_1->subnet_1 Configure.pre_configure_target
> has no implementation
> 16:14:21 | D | None | {} | port_1->subnet_1 Configure.pre_configure_source
> has no implementation
> 16:14:22 | D | None | {} | port_1 Standard.configure has no implementation
> 16:14:22 | D | None | {} | port_1->subnet_1 Configure.post_configure_
> target
> has no implementation
> 16:14:22 | D | None | {} | port_1->subnet_1 Configure.post_configure_
> source
> has no implementation
> 16:14:23 | D | None | {} | port_1 Standard.start has no implementation
> 16:14:23 | D | None | {} | port_1->subnet_1 Configure.add_source has no
> implementation
> 16:14:23 | D | None | {} | port_1->subnet_1 Configure.add_target has no
> implementation
> 16:14:29 | I | nova_plugin.server.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | vm_1 Standard.create
> started...
> 16:14:32 | D | nova_plugin.server.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | Instance relationship
> target instances: [{u'external_name': u'dfilppi-rs', u'tosca_name':
> u'keypair', u'state': u'initial', u'tosca_id': 'keypair_1', u'external_id':
> u'dfilppi-rs', u'external_type': 'keypair'}, {u'external_name':
> u'aria_helloworld_port', u'tosca_name': u'port', u'state': u'initial',
> u'fixed_ip_address': u'172.16.0.5', u'tosca_id': 'port_1', u'mac_address':
> u'fa:16:3e:76:9b:5f', u'external_id':
> u'044a027b-1cdc-441b-b3fa-953818668f02', u'external_type': 'port'}]
> 16:14:32 | D | nova_plugin.server.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | server.create() server
> before transformations: {'meta': {}, 'name': u'aria_helloworld_vm'}
> 16:14:32 | E | nova_plugin.server.create | {u'args': OrderedDict(),
> u'openstack_config': {'username': 'dewayne', 'tenant_name':
> 'dewayne-tenant', 'password': 'xxx', 'auth_url': '
> https://rackspace-api.gigaspaces.com:5000/v3'}} | vm_1 Standard.create
> failed
> |Traceback (most recent call last):
> |  File
> "/home/vagrant/incubator-ariatosca/aria/orchestrator/
> workflows/executor/process.py",
> line 342, in _main
> |task_func(ctx=ctx, **operation_arguments)
> |  File
> "/home/vagrant/venv/lib/python2.7/site-packages/
> adapters/context_adapter.py",
> line 434, in wrapper
> |ctx.task.retry(str(e), retry_interval=e.retry_after)
> |  File "/usr/lib64/python2.7/contextlib.py", line 36, in __exit__
> |raise RuntimeError("generator didn't stop after throw()")
> |RuntimeError: generator didn't stop after throw()
>
>
> On Wed, Aug 30, 2017 at 4:52 AM, Ran Ziv <r...@cloudify.co> wrote:
>
> > I can't really make sense of this error message.
> > Could you copy paste the full execution logs when running with "-vvv"?
> >
> > The "openstack_config" property/input should have nothing to do with the
> > image/flavor assignment - The former only affects the Openstack client
> > configuration, while the latter is set for a specific API call.
> >
> >
> >
> > On Wed, Aug 30, 2017 at 2:38 AM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > Here's the latest issue.  Got through all the networking con

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

Great! Glad to hear it worked :)


On Wed, Aug 30, 2017 at 4:42 PM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> Ran,
>
>  Per your suggestion, I am no longer modifying the example using sed, but
> am checking out tags/0.1.1.
>
> I now finally have a successful run on ubuntu 16.04 fresh install by
> following the below steps.
>
>
> sudo apt-get update
>
> sudo apt install -y python-pip git
>
> sudo pip install --upgrade pip setuptools
>
> sudo apt-get install -y python-dev gcc libffi-dev libssl-dev
>
> sudo pip install apache-ariatosca[ssh] --no-binary apache-ariatosca
>
> git clone https://github.com/apache/incubator-ariatosca.git
>
> cd incubator-ariatosca
>
> git checkout tags/0.1.1
>
> aria service-templates store examples/hello-world/helloworld.yaml
> my-service-template
>
> aria services create my-service -t my-service-template
>
> aria executions start install -s my-service
>
>
>
> I was also able to launch the url http://:9090 successfully.
>
> Thanks a lot for your patience and guidance.
>
> Vish
>
>
> 
> From: Ran Ziv <r...@cloudify.co>
> Sent: Wednesday, August 30, 2017 6:32 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Seeing error "Validation issues: unknown parent type
> "tosca:Root" in WebServer"
>
> You should not attempt to modify the example yourself using sed the way you
> do in your dockerfile - The change you're making is but a single one, while
> there's been other changes to the example since the 0.1.1 version as well -
> and more so, some changes took place in the service-templates scripts
> rather than the service template yaml file.
>
> See here:
> https://github.com/apache/incubator-ariatosca/blob/
> master/examples/hello-world/scripts/configure.sh#L35
> [https://avatars3.githubusercontent.com/u/47359?v=4=400]<
> https://github.com/apache/incubator-ariatosca/blob/master/examples/hello-
> world/scripts/configure.sh#L35>
>
> apache/incubator-ariatosca<https://github.com/apache/
> incubator-ariatosca/blob/master/examples/hello-world/
> scripts/configure.sh#L35>
> github.com
> incubator-ariatosca - Mirror of Apache incubator
>
>
>
> vs
> https://github.com/apache/incubator-ariatosca/blob/0.1.
> 1/examples/hello-world/scripts/configure.sh#L35
> [https://avatars3.githubusercontent.com/u/47359?v=4=400]<
> https://github.com/apache/incubator-ariatosca/blob/0.1.1/examples/hello-
> world/scripts/configure.sh#L35>
>
> apache/incubator-ariatosca<https://github.com/apache/
> incubator-ariatosca/blob/0.1.1/examples/hello-world/
> scripts/configure.sh#L35>
> github.com
> incubator-ariatosca - Mirror of Apache incubator
>
>
>
>
>
> Since you're using ARIA 0.1.1, it'd be best to use the 0.1.1 example. To do
> this, simply check out the "0.1.1" tag after git cloning the
> incubator-ariatosca repository from github.
>
>
> Ran
>
>
> On Tue, Aug 29, 2017 at 6:12 PM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
> > I edited line 6 in master file from 'tosca:Root' to 'tosca.nodes.Root'
> >
> >
> > Below is the modified Dockerfile that I am using
> >
> >
> > FROM ubuntu:16.04
> >
> >
> > RUN apt-get update && apt-get install -y \
> >
> > python-dev \
> >
> > gcc \
> >
> > libffi-dev \
> >
> > libssl-dev \
> >
> > python-pip \
> >
> > git \
> >
> > wget
> >
> >
> > RUN pip install --upgrade pip setuptools
> >
> >
> > #RUN pip install apache-ariatosca
> >
> >
> > RUN pip install apache-ariatosca[ssh] --no-binary apache-ariatosca
> >
> >
> > WORKDIR /tmp
> >
> >
> > RUN git clone https://github.com/apache/incubator-ariatosca.git
> [https://avatars3.githubusercontent.com/u/47359?v=4=400]<
> https://github.com/apache/incubator-ariatosca.git>
>
> apache/incubator-ariatosca<https://github.com/apache/
> incubator-ariatosca.git>
> github.com
> incubator-ariatosca - Mirror of Apache incubator
>
>
>
> > /tmp/incubator-ariatosca
> >
> >
> > RUN sed -i "s/tosca:Root/tosca.nodes.Root/g" /tmp/incubator-ariatosca/
> > examples/hello-world/helloworld.yaml
> >
> >
> >
> > Vish
> >
> >
> > 
> > From: Vishwanath Jayaraman <vishwana...@hotmail.com>
> > Sent: Tuesday, August 29, 2017 10:09 AM
> > To: dev@ariatosca.incubator.apache.org
>

Re: Podling Report Reminder - September 2017

[Ran Ziv]

I've updated the Podling report here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Podling+Report+2017-09


On Wed, Aug 30, 2017 at 6:54 AM,  wrote:

> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 20 September 2017, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, September 06).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> *   Your project name
> *   A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> *   A list of the three most important issues to address in the move
> towards graduation.
> *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> *   How has the community developed since the last report
> *   How has the project developed since the last report.
> *   How does the podling rate their own maturity.
>
> This should be appended to the Incubator Wiki page at:
>
> https://wiki.apache.org/incubator/September2017
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

You should not attempt to modify the example yourself using sed the way you
do in your dockerfile - The change you're making is but a single one, while
there's been other changes to the example since the 0.1.1 version as well -
and more so, some changes took place in the service-templates scripts
rather than the service template yaml file.

See here:
https://github.com/apache/incubator-ariatosca/blob/master/examples/hello-world/scripts/configure.sh#L35
vs
https://github.com/apache/incubator-ariatosca/blob/0.1.1/examples/hello-world/scripts/configure.sh#L35


Since you're using ARIA 0.1.1, it'd be best to use the 0.1.1 example. To do
this, simply check out the "0.1.1" tag after git cloning the
incubator-ariatosca repository from github.


Ran


On Tue, Aug 29, 2017 at 6:12 PM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> I edited line 6 in master file from 'tosca:Root' to 'tosca.nodes.Root'
>
>
> Below is the modified Dockerfile that I am using
>
>
> FROM ubuntu:16.04
>
>
> RUN apt-get update && apt-get install -y \
>
> python-dev \
>
> gcc \
>
> libffi-dev \
>
> libssl-dev \
>
> python-pip \
>
> git \
>
> wget
>
>
> RUN pip install --upgrade pip setuptools
>
>
> #RUN pip install apache-ariatosca
>
>
> RUN pip install apache-ariatosca[ssh] --no-binary apache-ariatosca
>
>
> WORKDIR /tmp
>
>
> RUN git clone https://github.com/apache/incubator-ariatosca.git
> /tmp/incubator-ariatosca
>
>
> RUN sed -i "s/tosca:Root/tosca.nodes.Root/g" /tmp/incubator-ariatosca/
> examples/hello-world/helloworld.yaml
>
>
>
> Vish
>
>
> 
> From: Vishwanath Jayaraman <vishwana...@hotmail.com>
> Sent: Tuesday, August 29, 2017 10:09 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Seeing error "Validation issues: unknown parent type
> "tosca:Root" in WebServer"
>
>
> Below is what I am using
>
>
> tosca_definitions_version: tosca_simple_yaml_1_0
>
>
> node_types:
>
>
>   WebServer:
>
> derived_from: tosca.nodes.Root
>
> capabilities:
>
>   host:
>
> type: tosca.capabilities.Container
>
>
>   WebApp:
>
> derived_from: tosca.nodes.WebApplication
>
> properties:
>
>   port:
>
> type: integer
>
>
> topology_template:
>
>
>   node_templates:
>
> web_server:
>
>   type: WebServer
>
>
> web_app:
>
>   type: WebApp
>
>   properties:
>
> port: 9090
>
>       requirements:
>
> - host: web_server
>
>   interfaces:
>
> Standard:
>
>   configure: scripts/configure.sh
>
>   start: scripts/start.sh
>
>   stop: scripts/stop.sh
>
>
>   outputs:
>
> port:
>
>   type: integer
>
>   value: { get_property: [ web_app, port ] }
>
>
>
> Vish
>
>
> 
> From: Ran Ziv <r...@cloudify.co>
> Sent: Tuesday, August 29, 2017 10:04 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Seeing error "Validation issues: unknown parent type
> "tosca:Root" in WebServer"
>
> Are you using the hello-world example from the 0.1.1 tag?
>
>
> On Tue, Aug 29, 2017 at 6:00 PM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
> > Ran,
> >
> >  Thanks a lot for figuring out the root cause for the issue and also
> > providing a work around.
> >
> > With the work around you provided I am able to go past the issue related
> > to "ctx" not being found.
> >
> > However, I am seeing the below new issue on ubuntu 16.04 when I execute "
> >
> > aria executions start install -s my-service -vvv"
> >
> >
> >
> > root@3f9951e417b3:/tmp# aria executions start install -s my-service -vvv
> >
> > Starting execution. Press Ctrl+C cancel
> >
> > 14:56:16 | I | install | {} | Starting 'install' workflow execution
> >
> > 14:56:17 | D | None | {} | web_server_1 Standard.create has no
> > implementation
> >
> > 14:56:17 | D | None | {} | web_server_1 Standard.configure has no
> > implementation
> >
> > 14:56:17 | D | None | {} | web_server_1 Standard.start has no
> > implementation
> >
> > 14:56:18 | D | None | {} | web_app_1 Standard.create has no
> implementation
> >
> > 14:56:18 | D | None | {} | web_app_1->web_server_1
> > Configure.pre_configure_source has no implementation
> >
> > 14:

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

Are you using the hello-world example from the 0.1.1 tag?


On Tue, Aug 29, 2017 at 6:00 PM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> Ran,
>
>  Thanks a lot for figuring out the root cause for the issue and also
> providing a work around.
>
> With the work around you provided I am able to go past the issue related
> to "ctx" not being found.
>
> However, I am seeing the below new issue on ubuntu 16.04 when I execute "
>
> aria executions start install -s my-service -vvv"
>
>
>
> root@3f9951e417b3:/tmp# aria executions start install -s my-service -vvv
>
> Starting execution. Press Ctrl+C cancel
>
> 14:56:16 | I | install | {} | Starting 'install' workflow execution
>
> 14:56:17 | D | None | {} | web_server_1 Standard.create has no
> implementation
>
> 14:56:17 | D | None | {} | web_server_1 Standard.configure has no
> implementation
>
> 14:56:17 | D | None | {} | web_server_1 Standard.start has no
> implementation
>
> 14:56:18 | D | None | {} | web_app_1 Standard.create has no implementation
>
> 14:56:18 | D | None | {} | web_app_1->web_server_1
> Configure.pre_configure_source has no implementation
>
> 14:56:18 | D | None | {} | web_app_1->web_server_1
> Configure.pre_configure_target has no implementation
>
> 14:56:20 | I | 
> aria.orchestrator.execution_plugin.operations.run_script_locally
> | {u'process': {}, u'script_path': u'scripts/configure.sh'} | web_app_1
> Standard.configure started...
>
> 14:56:20 | I | 
> aria.orchestrator.execution_plugin.operations.run_script_locally
> | {u'process': {}, u'script_path': u'scripts/configure.sh'} | Executing:
> /tmp/tmposBljn-configure.sh
>
> 14:56:21 | I | 
> aria.orchestrator.execution_plugin.operations.run_script_locally
> | {u'process': {}, u'script_path': u'scripts/configure.sh'} | [
>
> 14:56:22 | I | 
> aria.orchestrator.execution_plugin.operations.run_script_locally
> | {u'process': {}, u'script_path': u'scripts/configure.sh'} | [
>
> 14:56:22 | I | 
> aria.orchestrator.execution_plugin.operations.run_script_locally
> | {u'process': {}, u'script_path': u'scripts/configure.sh'} | Execution
> done (exit_code=1): /tmp/tmposBljn-configure.sh
>
> 14:56:22 | E | 
> aria.orchestrator.execution_plugin.operations.run_script_locally
> | {u'process': {}, u'script_path': u'scripts/configure.sh'} | web_app_1
> Standard.configure failed
>
> |Traceback (most recent call last):
>
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/workflows/executor/process.py", line 342, in _main
>
> |task_func(ctx=ctx, **operation_arguments)
>
> |  File 
> "/usr/local/lib/python2.7/dist-packages/aria/orchestrator/decorators.py",
> line 78, in _wrapper
>
> |return func(**func_kwargs)
>
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/operations.py", line 33, in
> run_script_locally
>
> |**kwargs)
>
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/local.py", line 43, in run_script
>
> |operation_kwargs=kwargs)
>
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/local.py", line 107, in _execute_func
>
> |return common.check_error(ctx, error_check_func=error_check_func)
>
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/common.py", line 150, in check_error
>
> |error_check_func()
>
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/local.py", line 106, in error_check_func
>
> |stderr=stderr_consumer.read_output())
>
> |ProcessException: Traceback (most recent call last):
>
> |  File "/usr/local/bin/ctx", line 11, in 
>
> |load_entry_point('apache-ariatosca==0.1.1', 'console_scripts',
> 'ctx')()
>
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/ctx_proxy/client.py", line 101, in main
>
> |timeout=args.timeout)
>
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/ctx_proxy/client.py", line 65, in
> _client_request
>
> |raise _RequestError(ex_message, ex_type, ex_traceback)
>
> |aria.orchestrator.execution_plugin.ctx_proxy.client._RequestError:
> (_RequestError(...), 'TypeError: download_resource_and_render() takes at
> most 4 arguments (5 given)')
>
> |
>
>
> Thanks a lot for all your help.
>
> Vish
>
>
> 
> From: Ran Ziv <r...@cloudify.co>
> Sent: Tuesday, August 29, 2017 4:22 

Re: subnet connected to router

[Ran Ziv]

Can we re-state the problem at hand? It's been somewhat difficult to follow
this thread.


On Tue, Aug 29, 2017 at 3:45 AM, Tal Liron  wrote:

> Great! So, now let's think what makes your full Openstack example
> different... I'm off for the day, will continue looking tomorrow.
>
> On Mon, Aug 28, 2017 at 7:43 PM, DeWayne Filppi 
> wrote:
>
> > It validated and seems correct via show -f.
> >
> >
> > On Mon, Aug 28, 2017 at 5:31 PM, Tal Liron  wrote:
> >
> > > OK, let's please go back to my simpler example on master. If that works
> > for
> > > you, we're on the same page and can try to reproduce the bug there.
> > >
> > > On Mon, Aug 28, 2017 at 7:23 PM, DeWayne Filppi 
> > > wrote:
> > >
> > > > Hopefully.  Has nothing to do with the Openstack plugin.  My example
> > had
> > > no
> > > > reference to it.  Just switched to master branch, and it had no
> effect.
> > > > The subnet node has a direct "node:" reference to the router node.
> > > >
> > > > On Mon, Aug 28, 2017 at 3:52 PM, Tal Liron  wrote:
> > > >
> > > > > As I said, if you're not using git master, you need to add a "node"
> > > field
> > > > > to the requirement to solve this error.
> > > > >
> > > > > If you must use the Openstack plugin, I can't help you much because
> > I'm
> > > > not
> > > > > very familiar with it. Perhaps someone else on the list could
> assist?
> > > > >
> > > > > But I have a feeling this is a higher-level issue, we just need to
> be
> > > > > patient and try to isolate it.
> > > > >
> > > > > On Mon, Aug 28, 2017 at 5:49 PM, DeWayne Filppi <
> dewa...@cloudify.co
> > >
> > > > > wrote:
> > > > >
> > > > > > Sent this before:
> > > > > >
> > > > > > I got this:
> > > > > >
> > > > > > Validation issues:
> > > > > >   5: requirement "my_requirement" of node "my_node2_1" has no
> > target
> > > > node
> > > > > > template
> > > > > >
> > > > > >
> > > > > > I'm rushing because I need a workaround at least very soon.
> > > > > >
> > > > > > On Mon, Aug 28, 2017 at 3:46 PM, Tal Liron 
> > wrote:
> > > > > >
> > > > > > > DeWayne, please slow down. We need to be on the same page here.
> > At
> > > > the
> > > > > > very
> > > > > > > least we need to use the same versions of ARIA.
> > > > > > >
> > > > > > > Why couldn't you use my example?
> > > > > > >
> > > > > > > On Mon, Aug 28, 2017 at 5:38 PM, DeWayne Filppi <
> > > dewa...@cloudify.co
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Note that creating a subtype of Subnet had no effect.   Tried
> > to
> > > > > force
> > > > > > > the
> > > > > > > > settings into a common subtype as a workaround, but had no
> > luck.
> > > > > > > >
> > > > > > > > On Mon, Aug 28, 2017 at 2:31 PM, DeWayne Filppi <
> > > > dewa...@cloudify.co
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I couldn't use your example.  The one I just sent
> illustrates
> > > the
> > > > > > > problem
> > > > > > > > > and has no openstack dependency.  I just forgot to delete
> the
> > > > > import
> > > > > > > > > statement.
> > > > > > > > >
> > > > > > > > > On Mon, Aug 28, 2017 at 2:24 PM, Tal Liron <
> t...@cloudify.co>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > >> DeWayne, could please use the example I provided? I prefer
> > to
> > > > > start
> > > > > > > with
> > > > > > > > >> something without Openstack or any other dependencies so
> we
> > > can
> > > > > > > isolate
> > > > > > > > >> the
> > > > > > > > >> bug precisely.
> > > > > > > > >>
> > > > > > > > >> On Mon, Aug 28, 2017 at 3:53 PM, DeWayne Filppi <
> > > > > > dewa...@cloudify.co>
> > > > > > > > >> wrote:
> > > > > > > > >>
> > > > > > > > >> > OK.  Here's the example with no dependencies.  Two
> nodes.
> > > > > > > > >> >
> > > > > > > > >> > tosca_definitions_version: tosca_simple_yaml_1_0
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > imports:
> > > > > > > > >> >   -
> > > > > > > > >> > https://raw.githubusercontent.com/cloudify-cosmo/aria-
> > > > > > > > >> > extension-cloudify/master/plugins/openstack/plugin.yaml
> > > > > > > > >> >   - aria-1.0
> > > > > > > > >> >
> > > > > > > > >> > dsl_definitions:
> > > > > > > > >> >   openstack_config: _config
> > > > > > > > >> > username: dewayne
> > > > > > > > >> >
> > > > > > > > >> > data_types:
> > > > > > > > >> >   config:
> > > > > > > > >> > properties:
> > > > > > > > >> >   username:
> > > > > > > > >> > type: string
> > > > > > > > >> > default: 'NOT SET'
> > > > > > > > >> >
> > > > > > > > >> > relationship_types:
> > > > > > > > >> >   subnet_connected_to_router:
> > > > > > > > >> > derived_from: ConnectsTo
> > > > > > > > >> > interfaces:
> > > > > > > > >> >   Configure:
> > > > > > > > >> > add_target:
> > > > > > > > >> >   implementation: connect.sh
> > > > > > > > >> >   inputs:
> > > > > > > > >> >   

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

Well, this is awkward.
After some short testing, it seems the problem is that the 0.1.1 (and
0.1.0) wheels don't treat "ctx" as an entry points (as is evident by
unzipping the wheel and viewing the "entry_points.txt" file).
One simple way to work around this is to install ARIA not via wheel, e.g.
by running:
pip install apache-ariatosca[ssh] --no-binary apache-ariatosca


I still can't quite say what's caused this - if I try to build a wheel from
the current state of master (0.2.0), the wheel does treat "ctx" as an entry
point, and it's indeed recognized post-install.
AFAIK, nothing's changed about the installation mechanism since 0.1.1.

It's likely to be related to the fact that "ctx" is not set directly into
"entry_points" in "setup.py", but rather is added dynamically by default:
https://github.com/apache/incubator-ariatosca/blob/0.1.1/setup.py#L101
However, as I mentioned, nothing much has changed there since 0.1.1, and I
don't see any changes in pip, wheel, or setuptools that might have caused
this either.

The easiest way to avoid this in the future is possibly to simply make
"ctx" written statically into the "entry_points". I'll create a JIRA for
this.





On Tue, Aug 29, 2017 at 11:42 AM, Ran Ziv <r...@cloudify.co> wrote:

> Vishwanath,
> Sorry for not having followed up this issue earlier.
> I tried launching a 16.04 container earlier and following your steps, and
> indeed ctx was nowhere to be found.
> I'm looking into this.
>
>
>
> On Mon, Aug 28, 2017 at 11:17 PM, Tal Liron <t...@cloudify.co> wrote:
>
>> Vish, I would very much appreciate if you could verify if ctx is available
>> in these cases:
>>
>> 1) 0.1.1: system install
>> 2) 0.1.1: virtualenv
>> 3) git master: system install
>> 4) git master: virtualenv
>>
>> Also, what OS are you using, and is there anything special about your
>> install?
>>
>>
>> On Mon, Aug 28, 2017 at 1:42 PM, DeWayne Filppi <dewa...@cloudify.co>
>> wrote:
>>
>> > I have 0.1.1 and ctx is there.
>> >
>> > On Mon, Aug 28, 2017 at 11:34 AM, Vishwanath Jayaraman <
>> > vishwana...@hotmail.com> wrote:
>> >
>> > > Tal,
>> > >
>> > >  Appreciate the prompt response.
>> > >
>> > > Looks like the apache-ariatosca version that gets installed when
>> > following
>> > > instructions at http://ariatosca.incubator.apa
>> che.org/getting-started/
>> > > is 0.1.1 (in my case) and in your output, the version is 0.2.0.
>> > >
>> > > So, like you mentioned in your earlier email, there could be a bug in
>> > > 0.1.1.
>> > >
>> > > Also, I do not see in the "Requires:" section of the output anything
>> > > related to "ctx", I am guessing ctx is installed when
>> apache-ariatosca is
>> > > installed.
>> > >
>> > >
>> > > If one other person can confirm that "ctx" is not installed when
>> > > apache-ariatosca version 0.1.1 is installed, do you think we should
>> open
>> > a
>> > > bug?
>> > >
>> > > Thoughts, suggestions?
>> > >
>> > > Thanks
>> > >
>> > > Vish
>> > >
>> > >
>> > > 
>> > > From: Tal Liron <t...@cloudify.co>
>> > > Sent: Monday, August 28, 2017 1:11 PM
>> > > To: dev@ariatosca.incubator.apache.org
>> > > Subject: Re: Seeing error "Validation issues: unknown parent type
>> > > "tosca:Root" in WebServer"
>> > >
>> > > Name: apache-ariatosca
>> > > Version: 0.2.0
>> > > Summary: ARIA
>> > > Home-page: http://ariatosca.incubator.apache.org/
>> > > Welcome to The Apache Software Foundation!<http://ariatosca.
>> > > incubator.apache.org/>
>> > > ariatosca.incubator.apache.org
>> > > Open. The Apache Software Foundation. provides support for the Apache
>> > > Community of open-source software projects, which provide software
>> > products
>> > > for the public good.
>> > >
>> > >
>> > >
>> > > Author: ARIA
>> > > Author-email: dev@ariatosca.incubator.apache.org
>> > > License: Apache License 2.0
>> > > Location: /home/user/ariatosca
>> > > Requires: requests, networkx, retrying, blinker, jsonpickle,
>> ruamel.yaml,
>> > > J

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

d and below is the console output. Which of
> > the
> > > > > below is related to "ctx"? Also, the /usr/local/bin/ is missing the
> > > 'ctx'
> > > > > binary on the 16.04 ubuntu, however, I do see the 'aria' binary in
> > that
> > > > > location.
> > > > >
> > > > >
> > > > > ==Begin Console Output===
> > > > >
> > > > > Name: apache-ariatosca
> > > > >
> > > > > Version: 0.1.1
> > > > >
> > > > > Summary: ARIA
> > > > >
> > > > > Home-page: http://ariatosca.incubator.apache.org/
> > > Welcome to The Apache Software Foundation!<http://ariatosca.
> > > incubator.apache.org/>
> > > ariatosca.incubator.apache.org
> > > Open. The Apache Software Foundation. provides support for the Apache
> > > Community of open-source software projects, which provide software
> > products
> > > for the public good.
> > >
> > >
> > >
> > > > Welcome to The Apache Software Foundation!<http://ariatosca.
> > > > incubator.apache.org/>
> > > > ariatosca.incubator.apache.org
> > > > Open. The Apache Software Foundation. provides support for the Apache
> > > > Community of open-source software projects, which provide software
> > > products
> > > > for the public good.
> > > >
> > > >
> > > >
> > > > >
> > > > > Author: ARIA
> > > > >
> > > > > Author-email: dev@ariatosca.incubator.apache.org
> > > > >
> > > > > License: Apache License 2.0
> > > > >
> > > > > Location: /usr/local/lib/python2.7/dist-packages
> > > > >
> > > > > Requires: psutil, ruamel.yaml, SQLAlchemy, logutils, requests,
> > > > > PrettyTable, jsonpickle, click-didyoumean, blinker,
> > > > > backports.shutil-get-terminal-size, clint, colorama, wagon,
> > > > CacheControl,
> > > > > retrying, bottle, click, setuptools, networkx, shortuuid, Jinja2
> > > > >
> > > > > ==End Console output=
> > > > >
> > > > >
> > > > > Vish
> > > > >
> > > > >
> > > > > 
> > > > > From: Vishwanath Jayaraman <vishwana...@hotmail.com>
> > > > > Sent: Friday, August 25, 2017 11:20 AM
> > > > > To: dev@ariatosca.incubator.apache.org
> > > > > Subject: Re: Seeing error "Validation issues: unknown parent type
> > > > > "tosca:Root" in WebServer"
> > > > >
> > > > >
> > > > > Ran,
> > > > >
> > > > > On a fresh Ubuntu 16.04.3 LTS install, I followed the below steps
> > > > >
> > > > > 1  sudo apt-get update -y
> > > > > 2  sudo apt install -y python-pip git
> > > > > 3  sudo pip install --upgrade pip setuptools
> > > > > 4  sudo apt-get install -y python-dev gcc libffi-dev libssl-dev
> > > > > 5  sudo pip install apache-ariatosca
> > > > > 6  sudo pip install apache-ariatosca[ssh]
> > > > > 7 ctx (console output message is "ctx: command not found")
> > > > >
> > > > > From the above steps, does it look like I could be missing
> something
> > > that
> > > > > is not installing the 'ctx' binary.
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > Vish
> > > > >
> > > > >
> > > > > 
> > > > > From: Ran Ziv <r...@cloudify.co>
> > > > > Sent: Friday, August 25, 2017 4:43 AM
> > > > > To: dev@ariatosca.incubator.apache.org
> > > > > Subject: Re: Seeing error "Validation issues: unknown parent type
> > > > > "tosca:Root" in WebServer"
> > > > >
> > > > > Hi Vishwanath,
> > > > >
> > > > > Thanks for helping in updating the hello-world example readme.
> Sorry
> > > > about
> > > > > the lack of clarity there regarding the need to copy the template's
> > > > > resources as well.
> > > > >
> > > > > Re

Re: uninstall behavior

[Ran Ziv]

Not really. There's a JIRA ticket about this

Have you tried resuming the workflow?


On Thu, Aug 24, 2017 at 9:08 PM, DeWayne Filppi  wrote:

> Uninstall fails upon error.  This has bad consequences for cleaning up
> partial installs.  Here's what I see:
>
> 1. Run install to create a chain of dependent nodes, say network -> subnet
> -> port -> instance.
> 2. For whatever reason, install fails on "create port" for example.
> 3. Running uninstall fails immediately trying to delete the instance.
>
> Is there a way to make uninstall behave like Cloudify (IOW continue on
> error)?
>

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

DeWayne, not really sure how the port-floatingip issue got linked on this
thread, but in any case it's a known issue and the problem has already been
fixed in this PR:
https://github.com/cloudify-cosmo/aria-extension-cloudify/pull/52

But it hasn't been merged yet. Should happen over the next week.


Ran

On Fri, Aug 25, 2017 at 12:43 PM, Ran Ziv <r...@cloudify.co> wrote:

> Hi Vishwanath,
>
> Thanks for helping in updating the hello-world example readme. Sorry about
> the lack of clarity there regarding the need to copy the template's
> resources as well.
>
> Regarding the ctx error, the ctx is a binary that should get installed in
> your environment when you install ARIA. It should not be installed
> separately.
> try reinstalling ARIA and running "ctx" from the shell - that should give
> you an error, but one from the "ctx" program, not one that such a program
> was not found.
>
>
> On Fri, Aug 25, 2017 at 4:40 AM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
>> For a first time user, its not apparent in the instructions at
>>
>> http://ariatosca.incubator.apache.org/getting-started/ that they may
>> need to copy the entire examples directory or clone the github repo, I will
>> go ahead and open a JIRA to update the README.rst with those additional
>> details.
>>
>> Only issue pending at this time is "ctx: command not found" error. Once,
>> I get a response on how that gets installed, I will include that in the
>> dependencies section.
>>
>>
>> Vish
>>
>>
>> 
>> From: DeWayne Filppi <dewa...@cloudify.co>
>> Sent: Thursday, August 24, 2017 1:28 PM
>> To: dev@ariatosca.incubator.apache.org
>> Subject: Re: Seeing error "Validation issues: unknown parent type
>> "tosca:Root" in WebServer"
>>
>> I'm running in a cloned github repo, so all is there.  On another front,
>> the Aria port type for Openstack requires that every port have a
>> public/floating ip.
>>
>> On Thu, Aug 24, 2017 at 11:11 AM, Tal Liron <t...@cloudify.co> wrote:
>>
>> > You need not just the helloworld YAML file, but also all the scripts it
>> > references. Try copying the whole examples directory to make sure.
>> >
>> > We are planning to eventually display a validation error if the YAML
>> file
>> > references artifacts that don't exist, so you wouldn't have to wait
>> until
>> > execution to see the error. This would be part of our general work on
>> > improving artifact support.
>> >
>> > On Thu, Aug 24, 2017 at 12:26 PM, Vishwanath Jayaraman <
>> > vishwana...@hotmail.com> wrote:
>> >
>> > > I copied the helloworld.yaml to '~/examples'  (i.e home directory) on
>> my
>> > > box.
>> > >
>> > >
>> > > From the instructions at http://ariatosca.incubator.
>> > > apache.org/getting-started/
>> > >
>> > > I executed the
>> > >
>> > > aria service-templates store examples/helloworld.yaml
>> my-service-template
>> > >
>> > > command from the home directory.
>> > >
>> > >
>> > >
>> > > Additional Info:
>> > >
>> > > - I am running this on a fresh Ubuntu 16.04 system
>> > >
>> > >
>> > > ARIA Installation sequence followed is below
>> > >
>> > > - sudo apt-get update
>> > >
>> > > - sudo apt-install python-pip
>> > >
>> > > - pip install --upgrade pip setuptools
>> > >
>> > > - sudo pip install apache-ariatosca
>> > >
>> > > - sudo apt-get install -y python-dev gcc libffi-dev libssl-dev
>> > >
>> > > - sudo pip install apache-ariatosca[ssh]
>> > >
>> > >
>> > > After I execute
>> > >
>> > > 'aria service-templates store examples/helloworld.yaml
>> > my-service-template
>> > > -vvv'
>> > >
>> > > I do not see the 'images', 'index.html' and 'scripts' in the
>> > >
>> > > '.aria/resources/service_template/1/'.
>> > >
>> > > I am guessing this is generated by the code.
>> > >
>> > >
>> > > Vish
>> > >
>> > >
>> > > 
>> > > From: Ran Ziv <r...@cloudify.co>
>> > > Sent: Thursday, August 24, 2017 4:22 AM
>

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

Hi Vishwanath,

Thanks for helping in updating the hello-world example readme. Sorry about
the lack of clarity there regarding the need to copy the template's
resources as well.

Regarding the ctx error, the ctx is a binary that should get installed in
your environment when you install ARIA. It should not be installed
separately.
try reinstalling ARIA and running "ctx" from the shell - that should give
you an error, but one from the "ctx" program, not one that such a program
was not found.


On Fri, Aug 25, 2017 at 4:40 AM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> For a first time user, its not apparent in the instructions at
>
> http://ariatosca.incubator.apache.org/getting-started/ that they may need
> to copy the entire examples directory or clone the github repo, I will go
> ahead and open a JIRA to update the README.rst with those additional
> details.
>
> Only issue pending at this time is "ctx: command not found" error. Once, I
> get a response on how that gets installed, I will include that in the
> dependencies section.
>
>
> Vish
>
>
> 
> From: DeWayne Filppi <dewa...@cloudify.co>
> Sent: Thursday, August 24, 2017 1:28 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Seeing error "Validation issues: unknown parent type
> "tosca:Root" in WebServer"
>
> I'm running in a cloned github repo, so all is there.  On another front,
> the Aria port type for Openstack requires that every port have a
> public/floating ip.
>
> On Thu, Aug 24, 2017 at 11:11 AM, Tal Liron <t...@cloudify.co> wrote:
>
> > You need not just the helloworld YAML file, but also all the scripts it
> > references. Try copying the whole examples directory to make sure.
> >
> > We are planning to eventually display a validation error if the YAML file
> > references artifacts that don't exist, so you wouldn't have to wait until
> > execution to see the error. This would be part of our general work on
> > improving artifact support.
> >
> > On Thu, Aug 24, 2017 at 12:26 PM, Vishwanath Jayaraman <
> > vishwana...@hotmail.com> wrote:
> >
> > > I copied the helloworld.yaml to '~/examples'  (i.e home directory) on
> my
> > > box.
> > >
> > >
> > > From the instructions at http://ariatosca.incubator.
> > > apache.org/getting-started/
> > >
> > > I executed the
> > >
> > > aria service-templates store examples/helloworld.yaml
> my-service-template
> > >
> > > command from the home directory.
> > >
> > >
> > >
> > > Additional Info:
> > >
> > > - I am running this on a fresh Ubuntu 16.04 system
> > >
> > >
> > > ARIA Installation sequence followed is below
> > >
> > > - sudo apt-get update
> > >
> > > - sudo apt-install python-pip
> > >
> > > - pip install --upgrade pip setuptools
> > >
> > > - sudo pip install apache-ariatosca
> > >
> > > - sudo apt-get install -y python-dev gcc libffi-dev libssl-dev
> > >
> > > - sudo pip install apache-ariatosca[ssh]
> > >
> > >
> > > After I execute
> > >
> > > 'aria service-templates store examples/helloworld.yaml
> > my-service-template
> > > -vvv'
> > >
> > > I do not see the 'images', 'index.html' and 'scripts' in the
> > >
> > > '.aria/resources/service_template/1/'.
> > >
> > > I am guessing this is generated by the code.
> > >
> > >
> > > Vish
> > >
> > >
> > > 
> > > From: Ran Ziv <r...@cloudify.co>
> > > Sent: Thursday, August 24, 2017 4:22 AM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Seeing error "Validation issues: unknown parent type
> > > "tosca:Root" in WebServer"
> > >
> > > No, it doesn't :)
> > > This is what mine looks like:
> > >
> > > $ ls ~/.aria/resources/service_template/2/
> > > hello-world.yaml  images  index.html  scripts
> > >
> > > How did you store the service-template? What was the directory you were
> > in
> > > when running the store command? (not that it should matter, but I don't
> > > have any better clue at the moment)
> > >
> > >
> > >
> > > On Thu, Aug 24, 2017 at 10:51 AM, Vishwanath Jayaraman <
> > > vishwana...@hotmail.com> wrote:
> > >
> > > 

Re: cli throwing PresenterNotFoundError

[Ran Ziv]

Hey DeWayne,
Did you manage to resolve this problem? What was it?


On Fri, Aug 18, 2017 at 7:18 AM, DeWayne Filppi  wrote:

> Thanks.  Yeah I saw that.  I didn't install with pip.  Tried "make install"
> and it didn't work.  Tried "make install-virtual" and that didn't work.
> The "pth" file is in the right place with the right contents.  Centos 7.
>
> On Thu, Aug 17, 2017 at 6:25 PM, Avia Efrat  wrote:
>
> > A quick late night thought - try this:
> > https://issues.apache.org/jira/browse/ARIA-110
> >
> > Another solution, try installing via 'make install' only.
> >
> > On Fri, Aug 18, 2017 at 3:47 AM, DeWayne Filppi 
> > wrote:
> >
> > > I'm running 'aria service-template validate' against a CSAR, and
> getting
> > a
> > > 'PresenterNotFoundError'.  I installed from source using 'make
> > > install-virtual'.  Version 0.1.1.
> > >
> >
>

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

Interesting. The script resource should have been placed in that directory
when you stored the service-template.
Try looking inside ~/.aria and see what you can find under the model
storage directory - the "service_template/1/.." path mentioned above should
be relative to there.


On Wed, Aug 23, 2017 at 11:52 PM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> THanks for making me aware of the -vvv option
>
>
> Below is what I see now
>
> Console output START
>
> ubuntu@intellij:~$ aria service-templates store /tmp/helloworld.yaml
> my-service-template
> Storing service template my-service-template...
> Service template my-service-template stored
> ubuntu@intellij:~$ aria services create my-service -t my-service-template
> -vvv
> Creating new service from service template my-service-template...
> Service created. The service's name is my-service
> ubuntu@intellij:~$ aria executions start install -s my-service -vvv
> Starting execution. Press Ctrl+C cancel
> 20:49:28 | I | install | {} | Starting 'install' workflow execution
> 20:49:30 | D | None | {} | web_server_1 Standard.create has no
> implementation
> 20:49:30 | D | None | {} | web_server_1 Standard.configure has no
> implementation
> 20:49:31 | D | None | {} | web_server_1 Standard.start has no
> implementation
> 20:49:33 | D | None | {} | web_app_1 Standard.create has no implementation
> 20:49:34 | D | None | {} | web_app_1->web_server_1
> Configure.pre_configure_source has no implementation
> 20:49:34 | D | None | {} | web_app_1->web_server_1
> Configure.pre_configure_target has no implementation
> 20:49:41 | I | 
> aria.orchestrator.execution_plugin.operations.run_script_locally
> | {u'process': {}, u'script_path': u'scripts/configure.sh'} | web_app_1
> Standard.configure started...
> 20:49:42 | E | 
> aria.orchestrator.execution_plugin.operations.run_script_locally
> | {u'process': {}, u'script_path': u'scripts/configure.sh'} | web_app_1
> Standard.configure failed
> |Traceback (most recent call last):
> |  File "/tmp/pip-build-7Wa36U/apache-ariatosca/aria/orchestrator/
> workflows/executor/process.py", line 342, in _main
> |  File 
> "/usr/local/lib/python2.7/dist-packages/aria/orchestrator/decorators.py",
> line 78, in _wrapper
> |return func(**func_kwargs)
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/operations.py", line 33, in
> run_script_locally
> |**kwargs)
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/local.py", line 37, in run_script
> |script_path = common.download_script(ctx, script_path)
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/execution_plugin/common.py", line 50, in download_script
> |ctx.download_resource(destination=dest_script_path,
> path=script_path)
> |  File "/usr/local/lib/python2.7/dist-packages/aria/
> orchestrator/context/common.py", line 163, in download_resource
> |path=path)
> |  File 
> "/usr/local/lib/python2.7/dist-packages/aria/storage/filesystem_rapi.py",
> line 128, in download
> |format(resource_relative_path))
> |StorageError: Resource service_template/1/scripts/configure.sh
> does not exist
>
> 20:50:18 | I | 
> aria.orchestrator.execution_plugin.operations.run_script_locally
> | {u'process': {}, u'script_path': u'scripts/configure.sh'}
> =END CONSOLE OUTPUT=
>
>
> Vish
>
>
> 
> From: Ran Ziv <r...@cloudify.co>
> Sent: Wednesday, August 23, 2017 3:29 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Seeing error "Validation issues: unknown parent type
> "tosca:Root" in WebServer"
>
> Nope - It works fine for me.
> Try to run it with "-vvv" for more verbose execution logging information.
>
>
> On Wed, Aug 23, 2017 at 7:17 PM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
> > Hi Ran,
> >
> > Appreciate your response.
> >
> > I edited the helloworld.yaml (changed from tosca:Root to
> tosca.nodes.Root)
> > and was able to make progress.
> >
> > However, I see the below "web_app_1 Standard.configure failed" - refer
> > console output below
> >
> >
> > console output start
> >
> > ubuntu@intellij:~$ aria service-templates store /tmp/helloworld.yaml
> > my-service-template
> > Sto

Re: cloudify openstack plugin example

[Ran Ziv]

I actually think it still might be related to the issue I mentioned above :)
if the operation input isn't set with actual values, the node property
should take hold - but because of the bug I mentioned the operation input
receives empty yet still set values and therefore possibly overrides the
node properties.

On Thu, Aug 24, 2017 at 3:34 AM, DeWayne Filppi  wrote:

> Found it.  Turns out "openstack_config" in node properties is deprecated
> with extreme prejudice (IOW it doesn't work).  Putting it in the operation
> inputs makes it work.
>
> On Wed, Aug 23, 2017 at 11:02 AM, Tal Liron  wrote:
>
> > Input files indeed look like that (as long as they have a .yaml suffix).
> >
> > If you do "aria services show -f" you can get a complete dump of the
> entire
> > model. Can you check that everything is correct there before we move on
> to
> > debugging the execution?
> >
> > On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi 
> > wrote:
> >
> > > Having trouble with inputs when trying to run the openstack helloworld.
> > I
> > > provide inputs that look like this:
> > >
> > > ssh_username: ubuntu
> > > external_network_name: public_net
> > > webserver_port: 8080
> > > private_key_path: ~/dfilppi-rs.pen
> > > image: some image id
> > > flavor: "2"
> > > openstack_config:
> > >   username: dewayne
> > >   password: xxx
> > >   tenant_name: dewayne-tenant
> > >   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
> > >
> > > Openstack config map entry values all become empty strings in the
> > > execution.  Am I specifying it wrong?  There is no example inputs file
> to
> > > compare with, alas.
> > >
> >
>

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

Nope - It works fine for me.
Try to run it with "-vvv" for more verbose execution logging information.


On Wed, Aug 23, 2017 at 7:17 PM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> Hi Ran,
>
> Appreciate your response.
>
> I edited the helloworld.yaml (changed from tosca:Root to tosca.nodes.Root)
> and was able to make progress.
>
> However, I see the below "web_app_1 Standard.configure failed" - refer
> console output below
>
>
> console output start
>
> ubuntu@intellij:~$ aria service-templates store /tmp/helloworld.yaml
> my-service-template
> Storing service template my-service-template...
> Service template my-service-template stored
> ubuntu@intellij:~$ aria services create my-service -t my-service-template
> Creating new service from service template my-service-template...
> Service created. The service's name is my-service
> ubuntu@intellij:~$ aria executions start install -s my-service
> Starting execution. Press Ctrl+C cancel
> Starting 'install' workflow execution
> web_app_1 Standard.configure started...
> web_app_1 Standard.configure failed
> web_app_1 Standard.configure started...
> web_app_1 Standard.configure failed
> console output end========
>
>
> Is the above you saw as well?
>
> Thanks
>
> Vish
>
>
> 
> From: Ran Ziv <r...@cloudify.co>
> Sent: Tuesday, August 22, 2017 2:29 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Seeing error "Validation issues: unknown parent type
> "tosca:Root" in WebServer"
>
> Hi Vishwanath,
>
> I just tried it myself and the service template parses fine.
>
> This is related to this change:
> https://github.com/apache/incubator-ariatosca/commit/
> c2b8e65b41c013bfd4ee14ea47268083f8b20822
> [https://avatars0.githubusercontent.com/u/29885907?v=4=200]<https://
> github.com/apache/incubator-ariatosca/commit/
> c2b8e65b41c013bfd4ee14ea47268083f8b20822>
>
> ARIA-277 Support for Type Qualified Name · apache/incubator-ariatosca@
> c2b8e65<https://github.com/apache/incubator-ariatosca/commit/
> c2b8e65b41c013bfd4ee14ea47268083f8b20822>
> github.com
> incubator-ariatosca - Mirror of Apache incubator
>
>
>
>
>
> The commit was introduced after 0.1.1 was released, so I think what might
> be the case here is that there's a mismatch between the code version and
> the example version.
> If you've installed 0.1.1, please download/checkout the correct version for
> the example, rather than use the one from the master branch.
>
> If you'd like to run the example off the master branch, make sure you
> install this branch and not the version on PyPI (the master branch's
> version is 0.2.0).
> You may also want to consider installing in editable mode so you won't need
> to reinstall after each pull.
>
>
> Ran
>
>
>
> On Tue, Aug 22, 2017 at 12:10 AM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
> >
> > When I execute the command "aria service-templates store
> > examples/hello-world/helloworld.yaml my-service-template" from the
> > 'Getting Started' section at https://github.com/apache/
> [https://avatars1.githubusercontent.com/u/47359?v=4=200]<
> https://github.com/apache/>
>
> The Apache Software Foundation · GitHub<https://github.com/apache/>
> github.com
> GitHub is where people build software. More than 23 million people use
> GitHub to discover, fork, and contribute to over 64 million projects.
>
>
>
> > incubator-ariatosca/blob/master/README.rst , I see the below message
> >
> >
> > Storing service template my-service-template...
> >
> > Validation issues:
> >
> >   4: unknown parent type "tosca.Root" in "WebServer"
> >
> >  @"/home/ubuntu/incubator-ariatosca/examples/hello-
> > world/helloworld.yaml":6:19
> >
> > Failed to parse service template
> >
> >
> > Is this a known issue?
> >
> > Thanks
> >
> > -Vish
> >
> > [https://avatars3.githubusercontent.com/u/47359?v=4=400]<
> > https://github.com/apache/incubator-ariatosca/blob/master/README.rst>
> [https://avatars3.githubusercontent.com/u/47359?v=4=400]<
> https://github.com/apache/incubator-ariatosca/blob/master/README.rst>
>
> incubator-ariatosca/README.rst at master · apache ...<
> https://github.com/apache/incubator-ariatosca/blob/master/README.rst>
> github.com
> ARIA is a an open-source, TOSCA-based, lightweight library and CLI for
> orchestration and for consumption by projects buil

Re: cloudify openstack plugin example

[Ran Ziv]

Might be related to this bug:
https://issues.apache.org/jira/browse/ARIA-349

Which was recently fixed in this PR:
https://github.com/apache/incubator-ariatosca/commit/8981791a10f91cb4f99ff8c01fd6b130b470ffae


On Wed, Aug 23, 2017 at 9:15 PM, DeWayne Filppi  wrote:

> I see this related to inputs:
>
>  openstack_config: {'username': '', 'nova_url': '', 'tenant_name': '',
> 'region': '', 'password': '', 'neutron_url': '', 'auth_url': ''}
>
> The model appears fine.  I'm just using the one directly from github.
>
>
> On Wed, Aug 23, 2017 at 11:02 AM, Tal Liron  wrote:
>
> > Input files indeed look like that (as long as they have a .yaml suffix).
> >
> > If you do "aria services show -f" you can get a complete dump of the
> entire
> > model. Can you check that everything is correct there before we move on
> to
> > debugging the execution?
> >
> > On Wed, Aug 23, 2017 at 12:54 PM, DeWayne Filppi 
> > wrote:
> >
> > > Having trouble with inputs when trying to run the openstack helloworld.
> > I
> > > provide inputs that look like this:
> > >
> > > ssh_username: ubuntu
> > > external_network_name: public_net
> > > webserver_port: 8080
> > > private_key_path: ~/dfilppi-rs.pen
> > > image: some image id
> > > flavor: "2"
> > > openstack_config:
> > >   username: dewayne
> > >   password: xxx
> > >   tenant_name: dewayne-tenant
> > >   auth_url: https://rackspace-api.gigaspaces.com:5000/v3
> > >
> > > Openstack config map entry values all become empty strings in the
> > > execution.  Am I specifying it wrong?  There is no example inputs file
> to
> > > compare with, alas.
> > >
> >
>

Re: aria install plugin openstack

[Ran Ziv]

Please see Wagon's README here:
https://github.com/cloudify-cosmo/wagon

The archive's format has been changed from tar.gz to zip - This means that
you're either using a .wgn file which is too old, or if you built the wagon
file yourself - wagon code that is not up to date.
ARIA only supports wagons implemented using zip archives (the new kind).



On Wed, Aug 23, 2017 at 1:18 AM, DeWayne Filppi  wrote:

> When attempting 'aria plugins install' on the openstack plugin wagon from
> the website, I get the error:
>
> Archive
> cloudify_openstack_plugin-2.2.0-py27-none-linux_x86_64-centos-Core.wgn is
> of an unsupported type. Only zip/wgn is allowed
>
> aria 0.1.1
>
> The wgn looks ok (i.e. tar tzf works).
>

Re: Seeing error "Validation issues: unknown parent type "tosca:Root" in WebServer"

[Ran Ziv]

Hi Vishwanath,

I just tried it myself and the service template parses fine.

This is related to this change:
https://github.com/apache/incubator-ariatosca/commit/c2b8e65b41c013bfd4ee14ea47268083f8b20822


The commit was introduced after 0.1.1 was released, so I think what might
be the case here is that there's a mismatch between the code version and
the example version.
If you've installed 0.1.1, please download/checkout the correct version for
the example, rather than use the one from the master branch.

If you'd like to run the example off the master branch, make sure you
install this branch and not the version on PyPI (the master branch's
version is 0.2.0).
You may also want to consider installing in editable mode so you won't need
to reinstall after each pull.


Ran



On Tue, Aug 22, 2017 at 12:10 AM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

>
> When I execute the command "aria service-templates store
> examples/hello-world/helloworld.yaml my-service-template" from the
> 'Getting Started' section at https://github.com/apache/
> incubator-ariatosca/blob/master/README.rst , I see the below message
>
>
> Storing service template my-service-template...
>
> Validation issues:
>
>   4: unknown parent type "tosca.Root" in "WebServer"
>
>  @"/home/ubuntu/incubator-ariatosca/examples/hello-
> world/helloworld.yaml":6:19
>
> Failed to parse service template
>
>
> Is this a known issue?
>
> Thanks
>
> -Vish
>
> [https://avatars3.githubusercontent.com/u/47359?v=4=400]<
> https://github.com/apache/incubator-ariatosca/blob/master/README.rst>
>
> incubator-ariatosca/README.rst at master · apache ...<
> https://github.com/apache/incubator-ariatosca/blob/master/README.rst>
> github.com
> ARIA is a an open-source, TOSCA-based, lightweight library and CLI for
> orchestration and for consumption by projects building TOSCA-based
> solutions for resources and ...
>
>
> Vish
>

Re: pip executable expected as part of plugin install.

[Ran Ziv]

Can you try to explain again what's the issue you're seeing with the way
Wagon works right now?
We could create a pull request for Wagon as well, but I'm not sure I
understand the problem at the moment.

On Wed, Aug 16, 2017 at 6:04 PM, D Jayachandran  wrote:

> Even if we fix the issue in ARIA. Wagon library still uses the same logic
> in finding the pip path and it is wrong.
> Am not sure how to fix this with wagon.
>
> Regards,
> DJ
> -Original Message-
> From: D Jayachandran [mailto:d.jayachand...@ericsson.com]
> Sent: Thursday, August 03, 2017 5:00 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: RE: pip executable expected as part of plugin install.
>
> Thanks Avia, I will open an issue.
>
> Regards,
> DJ
>
> -Original Message-
> From: Avia Efrat [mailto:a...@cloudify.co]
> Sent: Thursday, August 03, 2017 4:01 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: pip executable expected as part of plugin install.
>
> Hi DJ,
> It seems you are correct, I don't see a reason for not using the pip
> library.
> Maybe it was that way since we didn't want to add pip as a dependency
> explicitly (this code is from the beginning of ARIA).
>
> Feel free to open an issue about that =)
>
> On Wed, Aug 2, 2017 at 10:19 AM, D Jayachandran <
> d.jayachand...@ericsson.com
> > wrote:
>
> > Hi,
> >
> > Am using a Ubuntu version of linux for my development and ARIA does
> > not find the correct path of pip during the plugin install.
> > To be precise this happens when pip freeze is executed.
> >
> > @staticmethod
> > def _pip_freeze():
> > """Run pip freeze in current environment and return the output"""
> > bin_dir = 'Scripts' if os.name == 'nt' else 'bin'
> > pip_path = os.path.join(sys.prefix, bin_dir,
> > 'pip{0}'.format('.exe' if os.name ==
> 'nt'
> > else ''))
> > pip_freeze = subprocess.Popen([pip_path, 'freeze'],
> > stdout=subprocess.PIPE)
> > pip_freeze_output, _ = pip_freeze.communicate()
> > assert not pip_freeze.poll()
> > return pip_freeze_output
> >
> > Now the question is why are we executing a pip command directly and
> > not using pip as a library.
> >
> >
> > Regards,
> > DJ
> >
>

Re: JIRA: Assign button not available

[Ran Ziv]

It seems like you have to be added as a "contributor" role before you can
be assigned to an issue at the moment.
I can't change this permission scheme myself. I think it might actually be
a single permissions scheme across Apache projects, but I'm not sure about
that.

In any case I added you as a "contributor" role on our project's JIRA, and
assigned you the ticket. Also made a comment on the PR.

Thanks!


On Sun, Aug 20, 2017 at 2:11 AM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> I opened a JIRA bug https://issues.apache.org/jira/browse/ARIA-352 and
> worked on a fix.
>
> However, I am unable to assign the JIRA bug to myself, I am guessing since
> I am a new contributor, it could be permissions issue. Would appreciate if
> the JIRA admin would give me the relevant permissions.
>
> Thanks
>
> Vish
>

Re: Running into issue when installing aria[ssh] on Ubuntu 16.04

[Ran Ziv]

Feel free to open a JIRA ticket, or possibly even submit a pull request
with a fix.

You can read more about it on our Confluence:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+to+ARIA

Ran


On Fri, Aug 18, 2017 at 5:42 PM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> Ran,
>
>  Thanks for the prompt response.
>
> Should I open a bug to track this documentation issue? If Yes, is there a
> process documented that I can refer and open a bug. I am new to Apache
> projects as well, but have worked on OpenStack projects in the past.
>
> Thanks
>
> Vish
>
>
> 
> From: Ran Ziv <r...@cloudify.co>
> Sent: Friday, August 18, 2017 9:31 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Running into issue when installing aria[ssh] on Ubuntu 16.04
>
> This seems like a simple mistake, the package's name was changed when ARIA
> became an Apache incubator project.
>
> Please try to install "apache-ariatosca[ssh]" instead of "aria[ssh]".
>
> On Fri, Aug 18, 2017 at 5:14 PM, Vishwanath Jayaraman <
> vishwana...@hotmail.com> wrote:
>
> > Hi,
> >
> >  I am new to ARIA and was trying out the "getting started" instructions
> at
> > link http://ariatosca.incubator.apache.org/getting-started/ on Ubuntu
> > 16.04
> >
> > One of the steps "pip install aria[ssh]" for Ubuntu 16.04 displays the
> > message "
> >
> > Could not find a version that satisfies the requirement aria[ssh] (from
> > versions: )
> >
> > No matching distribution found for aria[ssh]
> >
> > "
> >
> > Has anyone else encountered this and if Yes, how did you go about
> > resolving this? Thanks in advance for all your help.
> >
> > Vish
> >
>

Re: Running into issue when installing aria[ssh] on Ubuntu 16.04

[Ran Ziv]

This seems like a simple mistake, the package's name was changed when ARIA
became an Apache incubator project.

Please try to install "apache-ariatosca[ssh]" instead of "aria[ssh]".

On Fri, Aug 18, 2017 at 5:14 PM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

> Hi,
>
>  I am new to ARIA and was trying out the "getting started" instructions at
> link http://ariatosca.incubator.apache.org/getting-started/ on Ubuntu
> 16.04
>
> One of the steps "pip install aria[ssh]" for Ubuntu 16.04 displays the
> message "
>
> Could not find a version that satisfies the requirement aria[ssh] (from
> versions: )
>
> No matching distribution found for aria[ssh]
>
> "
>
> Has anyone else encountered this and if Yes, how did you go about
> resolving this? Thanks in advance for all your help.
>
> Vish
>

Re: subscribe

[Ran Ziv]

Hi Vishwanath,

In order to subscribe to the lists, you need to send your subscription
request to "user-subscr...@ariatosca.incubator.apache.org" and "
dev-subscr...@ariatosca.incubator.apache.org", rather than to the actual
lists.


Ran


On Fri, Aug 18, 2017 at 5:30 AM, Vishwanath Jayaraman <
vishwana...@hotmail.com> wrote:

>
>
> Vish
>

Re: Service Composition / Substitution Mapping

[Ran Ziv]

I agree, especially when the benefit of being able to use an existing
service - yet only one which hasn't been deployed via a workflow - doesn't
seem all that interesting IMO.

Another concern I could add to the ones you've mentioned is the service's
inputs - the substituting template's inputs should be received via the
properties of the abstract node in the top level service template. If the
service already exists, these inputs would not be passed as expected.

Ran

On Wed, Aug 16, 2017 at 3:25 PM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Ran,
>
> When Tal mentioned about "substituting service", I thought it was about
> the services which dint have any associated executions/workflows triggered.
> Am also in favor of  "substituting service templates" rather than
> "substituting service".
> With "substituting service" approach (when the service is not
> instantiated), I see some open points
> - In a multi-user scenario, what will happen when a service is
> composed using the substituting service and at the sametime a  workflow is
> triggered for the substituting service. ?
> - Is it okay to delete(dissolve) the substituting service after it
> is used to create the composed service. ?
>
> Starting with it might be a good idea to only have "substituting service
> templates" approach.
>
> Regards,
> DJ
> -Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]
> Sent: Wednesday, August 16, 2017 4:29 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Service Composition / Substitution Mapping
>
> I'd say right now we're looking at "static service composition" which is
> only about "substituting service templates", not "substituting service". If
> a service is already running, it will not be used.
>
> I think what Tal meant was that each service template - whether the top
> level one or one of the substituting templates - needs to resolve its inner
> reqs internally first, and then resolve substitution reqs across
> service templates.
>
>
> On Wed, Aug 16, 2017 at 12:00 PM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Tal,
> >
> > Thanks for organizing the points.
> > So if I understand correctly we are looking only at "Static service
> > composition" which includes "substituting service template" and
> > "substituting service".
> >
> > As you said with "substituting service template" approach ,we will
> > have all the nodes aggregated from other service templates and a
> > single workflow would be triggered to perform life-cycle operation on
> all the nodes.
> > Am not sure why the workflows needs to be "boundary aware" for nodes
> > being substituted ? I see nodes are already part of the composed
> > service, Could you please help me understand this ?
> >
> >
> > Regards,
> > DJ
> > -Original Message-
> > From: Tal Liron [mailto:t...@cloudify.co]
> > Sent: Saturday, August 12, 2017 4:52 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Service Composition / Substitution Mapping
> >
> > You are correct -- to participate in this "multi-VIM" scenario, the
> > Openstack plugin would have to know how to translate the TOSCA
> > properties to a flavor ID. This could all be done in 100% TOSCA via
> > policies (say, an aria.Openstack).
> >
> > Doing this automatically might not be a good idea, or even necessary.
> > Worst case is you get a validation error if the ARIA plugin can't find
> > a flavor in the table to match your requirements, in which you case
> > you can go and manually find the right ID and add it to the table.
> >
> > And I agree about being fine with imperfection: the rule of thumb for
> > our work is always to allow for sensible defaults even if no explicit
> > policy is given.
> >
> > Anyway, we've gone way off the topic of this thread. We can talk about
> > it more once it comes closer to an implementation.
> >
> > On Fri, Aug 11, 2017 at 3:52 PM, DeWayne Filppi <dewa...@cloudify.co>
> > wrote:
> >
> > > Interesting.  Take Openstack (please ).  If you model a
> > > compute OS as explicitly as you like, there still has to be a "match"
> > > to an Openstack image ID.  Or are you saying you must supply the
> > > image
> > ID for
> > > OSs.   Likewise, you can't supply RAM and CPUs without a flavor ID.
> > > Openstack does allow for custom flavors, but I doubt the plugin is
> > > doing that.  Much be

Re: ARIA install on MAC

[Ran Ziv]

Seems like you don't have the necessary permissions to change file flags
with your current user.

Please note that this error doesn't really seem related to ARIA in any way..

On Tue, Aug 15, 2017 at 7:02 PM, <steve.baillarg...@videotron.ca> wrote:

> Hi Ran
> I succeeded to upgrade setuptools using --user python option.
>
> The pip install did not work.
> The error message is operations not permitted.
> See below
>
>
>
>
>
>
>
> Exception:
>
> Traceback (most recent call last):
>
>  File 
> "/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/basecommand.py",
> line 215, in main
>
>  status = self.run(options, args)
>
>  File 
> "/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/commands/install.py",
> line 342, in run
>
>  prefix=options.prefix_path,
>
>  File 
> "/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/req/req_set.py",
> line 778, in install
>
>  requirement.uninstall(auto_confirm=True)
>
>  File 
> "/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/req/req_install.py",
> line 754, in uninstall
>
>  paths_to_remove.remove(auto_confirm)
>
>  File 
> "/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/req/req_uninstall.py",
> line 115, in remove
>
>  renames(path, new_path)
>
>  File 
> "/Library/Python/2.7/site-packages/pip-9.0.1-py2.7.egg/pip/utils/__init__.py",
> line 267, in renames
>
>  shutil.move(old, new)
>
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py",
> line 302, in move
>
>  copy2(src, real_dst)
>
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py",
> line 131, in copy2
>
>  copystat(src, dst)
>
>  File 
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/shutil.py",
> line 103, in copystat
>
>  os.chflags(dst, st.st_flags)
>
> OSError: [Errno 1] Operation not permitted: '/var/folders/73/sq1jnvgx0l7_
> 18h9kc7v09_rgp/T/pip-w_p4Ck-uninstall/System/Library/
> Frameworks/Python.framework/Versions/2.7/Extras/lib/
> python/six-1.4.1-py2.7.egg-info'
>
>
>
> >
> >
> >
> > -Original Message-
> > From: Ran Ziv [mailto:r...@cloudify.co] <r...@cloudify.co]>
> > Sent: Monday, August 14, 2017 7:13 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: ARIA install on MAC
> >
> > Hi Steve,
> >
> > It does sound like an issue related to the setuptools version. What made
> you unable to upgrade it?
> >
> > Also, these links might be helpful:
> > https://bitbucket.org/ruamel/yaml/issues/86/osx-cannot-install
> > https://bitbucket.org/ruamel/yaml/issues/32/cannot-run-
> setup-script-on-python-2710
> > https://bitbucket.org/ruamel/yaml/issues/37/osx-not-able-
> to-install-using-pip
> >
> >
> > Ran
> >
> > On Mon, Aug 14, 2017 at 7:08 PM, <steve.baillarg...@videotron.ca> wrote:
> >
> > > Hi
> > > I am trying to install ARIA on MACBook Pro.
> > > It did not work.
> > > See below.
> > > Please advise.
> > >
> > > This is what I have running:
> > >
> > > - MacOS Sierra
> > > - pip version 9.0.1
> > > - Python version 2.7.10
> > > - setuptools 18.5 ( I could not upgrade it)
> > >
> > > This is the error message I got during ARIA install:
> > >
> > > >
> > > >
> > > > Command "python setup.py egg_info" failed with error code 1 in
> > > /private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn
> > > /T/pip-build-Gjmmpp/ruamel.yaml/
> > > >
> > > >
> > >
> > >
> > > Complete output is below
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > >
> > > >
> > > > Steves-Macbook-Pro:Documents steve$ cd incubator-ariatosca-0.1.1/
> > > >
> > > > Steves-Macbook-Pro:incubator-ariatosca-0.1.1 steve$ ls
> > > >
> > > > CHANGELOG.rst MANIFEST.in VERSION examples setup.py
> > > >
> > > > CONTRIBUTING Makefile appveyor.yml extensions tests
> > > >
> > > > DISCLAIMER NOTICE aria requirements.in tox.ini
> > > >
> > > > LICENSE README.rst docs requirements.txt
> > > >
> > > > Steves-Macbook-Pro:incubator-ariatosca-0.1.1 steve$ pip install .
> &g

Re: Service Composition / Substitution Mapping

[Ran Ziv]

I'd say right now we're looking at "static service composition" which is
only about "substituting service templates", not "substituting service". If
a service is already running, it will not be used.

I think what Tal meant was that each service template - whether the top
level one or one of the substituting templates - needs to resolve its inner
reqs internally first, and then resolve substitution reqs across
service templates.


On Wed, Aug 16, 2017 at 12:00 PM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi Tal,
>
> Thanks for organizing the points.
> So if I understand correctly we are looking only at "Static service
> composition" which includes "substituting service template" and
> "substituting service".
>
> As you said with "substituting service template" approach ,we will have
> all the nodes aggregated from other service templates and a single workflow
> would be triggered to perform life-cycle operation on all the nodes.
> Am not sure why the workflows needs to be "boundary aware" for nodes being
> substituted ? I see nodes are already part of the composed service, Could
> you please help me understand this ?
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Saturday, August 12, 2017 4:52 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Service Composition / Substitution Mapping
>
> You are correct -- to participate in this "multi-VIM" scenario, the
> Openstack plugin would have to know how to translate the TOSCA properties
> to a flavor ID. This could all be done in 100% TOSCA via policies (say, an
> aria.Openstack).
>
> Doing this automatically might not be a good idea, or even necessary.
> Worst case is you get a validation error if the ARIA plugin can't find a
> flavor in the table to match your requirements, in which you case you can
> go and manually find the right ID and add it to the table.
>
> And I agree about being fine with imperfection: the rule of thumb for our
> work is always to allow for sensible defaults even if no explicit policy is
> given.
>
> Anyway, we've gone way off the topic of this thread. We can talk about it
> more once it comes closer to an implementation.
>
> On Fri, Aug 11, 2017 at 3:52 PM, DeWayne Filppi 
> wrote:
>
> > Interesting.  Take Openstack (please ).  If you model a
> > compute OS as explicitly as you like, there still has to be a "match"
> > to an Openstack image ID.  Or are you saying you must supply the image
> ID for
> > OSs.   Likewise, you can't supply RAM and CPUs without a flavor ID.
> > Openstack does allow for custom flavors, but I doubt the plugin is
> > doing that.  Much better to have a "caps-init" interface in some low
> > down base type that can be triggered at service creation to support
> > reqs/caps (IMHO).  Then the plugin can verify whether the service can
> > be construct based on fuzzy constraints.  Maybe this is a case that
> > the "general solution" is a nightmare of complexity, but having a
> > plugin scan the available flavors to make sure a requirement can be
> > met doesn't seem that tough.  If TOSCA provided a formal lifecycle
> > interface for it, then orchestrators or just plugins could determine
> > how tricky they wanted to be.  IOW, let not the perfect be the enemy of
> the good.
> >
> > DeWayne
> >
> >
> > On Fri, Aug 11, 2017 at 1:26 PM, Tal Liron  wrote:
> >
> > > OK, that's a whole different can of worms. :)
> > >
> > > TOSCA's Compute capabilities (Container and OperatingSystem) are
> > explicit.
> > > You specify which OS you want, how much RAM you want, how many CPUs,
> etc.
> > > ARIA's explicit node types (for example, the AWS Compute node) are
> > likewise
> > > explicit. So there is not querying here: the plugin will attempt to
> > > spin
> > up
> > > exactly the virtual machine you asked for. If it fails, the workflow
> > > will fail.
> > >
> > > This is not good enough, I think, for real world scenarios. There
> > > are two possible solutions:
> > >
> > > 1) Support ranges or fallbacks. So instead of saying "I need 4 GB of
> RAM"
> > > you can say "I would like 4 GB of RAM, but 2 GB would also be OK."
> > There's
> > > no easy way to do this now without totally changing how the
> > > capability types are designed. But, it may be possible to override
> > > this via
> > policies.
> > > So, the capabilities would perhaps specify the minimal requirements,
> > while
> > > policies specify preferences. Some aspects of this were discussed in
> > > the OPEN-O project. DeWayne, has any of this survived in ONAP, or
> > > have we not reached that point in the discussion yet?
> > >
> > > 2) Incorporate this into the bigger topic of resource orchestration.
> > This a
> > > huge challenge for the industry. The problem field contains not just
> > > "I need X amount of RAM" but also "I want all my virtual machines
> > > and containers running on the same high-performance network backend
> > > and have these two 

Re: Service Composition / Substitution Mapping

[Ran Ziv]

I'd say right now we're looking at "static service composition" which is
only about "substituting service templates", not "substituting service". If
a service is already running, it will not be used.

I think what Tal meant was that each service template - whether the top
level one or one of the substituting templates - needs to resolve its inner
reqs internally first, and then resolve substitution reqs across
service templates.


On Wed, Aug 16, 2017 at 12:00 PM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi Tal,
>
> Thanks for organizing the points.
> So if I understand correctly we are looking only at "Static service
> composition" which includes "substituting service template" and
> "substituting service".
>
> As you said with "substituting service template" approach ,we will have
> all the nodes aggregated from other service templates and a single workflow
> would be triggered to perform life-cycle operation on all the nodes.
> Am not sure why the workflows needs to be "boundary aware" for nodes being
> substituted ? I see nodes are already part of the composed service, Could
> you please help me understand this ?
>
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@cloudify.co]
> Sent: Saturday, August 12, 2017 4:52 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Service Composition / Substitution Mapping
>
> You are correct -- to participate in this "multi-VIM" scenario, the
> Openstack plugin would have to know how to translate the TOSCA properties
> to a flavor ID. This could all be done in 100% TOSCA via policies (say, an
> aria.Openstack).
>
> Doing this automatically might not be a good idea, or even necessary.
> Worst case is you get a validation error if the ARIA plugin can't find a
> flavor in the table to match your requirements, in which you case you can
> go and manually find the right ID and add it to the table.
>
> And I agree about being fine with imperfection: the rule of thumb for our
> work is always to allow for sensible defaults even if no explicit policy is
> given.
>
> Anyway, we've gone way off the topic of this thread. We can talk about it
> more once it comes closer to an implementation.
>
> On Fri, Aug 11, 2017 at 3:52 PM, DeWayne Filppi 
> wrote:
>
> > Interesting.  Take Openstack (please ).  If you model a
> > compute OS as explicitly as you like, there still has to be a "match"
> > to an Openstack image ID.  Or are you saying you must supply the image
> ID for
> > OSs.   Likewise, you can't supply RAM and CPUs without a flavor ID.
> > Openstack does allow for custom flavors, but I doubt the plugin is
> > doing that.  Much better to have a "caps-init" interface in some low
> > down base type that can be triggered at service creation to support
> > reqs/caps (IMHO).  Then the plugin can verify whether the service can
> > be construct based on fuzzy constraints.  Maybe this is a case that
> > the "general solution" is a nightmare of complexity, but having a
> > plugin scan the available flavors to make sure a requirement can be
> > met doesn't seem that tough.  If TOSCA provided a formal lifecycle
> > interface for it, then orchestrators or just plugins could determine
> > how tricky they wanted to be.  IOW, let not the perfect be the enemy of
> the good.
> >
> > DeWayne
> >
> >
> > On Fri, Aug 11, 2017 at 1:26 PM, Tal Liron  wrote:
> >
> > > OK, that's a whole different can of worms. :)
> > >
> > > TOSCA's Compute capabilities (Container and OperatingSystem) are
> > explicit.
> > > You specify which OS you want, how much RAM you want, how many CPUs,
> etc.
> > > ARIA's explicit node types (for example, the AWS Compute node) are
> > likewise
> > > explicit. So there is not querying here: the plugin will attempt to
> > > spin
> > up
> > > exactly the virtual machine you asked for. If it fails, the workflow
> > > will fail.
> > >
> > > This is not good enough, I think, for real world scenarios. There
> > > are two possible solutions:
> > >
> > > 1) Support ranges or fallbacks. So instead of saying "I need 4 GB of
> RAM"
> > > you can say "I would like 4 GB of RAM, but 2 GB would also be OK."
> > There's
> > > no easy way to do this now without totally changing how the
> > > capability types are designed. But, it may be possible to override
> > > this via
> > policies.
> > > So, the capabilities would perhaps specify the minimal requirements,
> > while
> > > policies specify preferences. Some aspects of this were discussed in
> > > the OPEN-O project. DeWayne, has any of this survived in ONAP, or
> > > have we not reached that point in the discussion yet?
> > >
> > > 2) Incorporate this into the bigger topic of resource orchestration.
> > This a
> > > huge challenge for the industry. The problem field contains not just
> > > "I need X amount of RAM" but also "I want all my virtual machines
> > > and containers running on the same high-performance network backend
> > > and have these two 

Re: ARIA install on PC

[Ran Ziv]

Hi Steve,

I'd definitely not give up, this seems like a rather weird yet simple error
all in all :) For some reason you have the wrong file there.
I did not see anything attached.

Is the file you see the same as the CLI exceptions file (i.e.
https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/cli/exceptions.py
) ?




On Tue, Aug 15, 2017 at 5:16 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi Ran
>
> Line 20 from version 0.1.1 on my PC has the following line:
> from ..exceptions import AriaError
>
> I have downloaded and install version 0.2.0.
> I have the same error when I run aria --version.
> Line 20 from version 0.2.0 on my PC has the following line:
> from ..exceptions import AriaError
> I have attached the doc.
>
> Should I give up :) ?
>
> -Steve
>
> -Original Message-
> From: Ran Ziv [mailto:r...@cloudify.co]
> Sent: Tuesday, August 15, 2017 4:29 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: ARIA install on PC
>
> Hi Steve,
>
> It seems like your aria\exceptions.py file is of a wrong version somehow.
> If you take a look at its 0.1.1 revision, you'll see the import line in
> line 20 (the last line in your stack trace) is a different one than the one
> mentioned in the error:
> https://github.com/apache/incubator-ariatosca/blob/0.1.
> 1/aria/orchestrator/exceptions.py#L20
> (The same line appears in the 0.1.0 and master revisions, by the way)
>
> A quick search for "from ..exceptions import AriaError" shows that this
> line only appears in the aria/cli/exceptions.py module (in line 20 as well)
> - I'd suggest maybe somehow this module gets loaded instead of the right
> one, if I didn't have the stack trace to show me that it's specifically
> "aria/exceptions.py" that's loaded - But try to open the
> "aria/exceptions.py" file and see if it might look like this:
> https://github.com/apache/incubator-ariatosca/blob/0.1.
> 1/aria/cli/exceptions.py
>
>
> Ran
>
>
>
>
>
> On Mon, Aug 14, 2017 at 10:59 PM, Steve Baillargeon <
> steve.baillarg...@ericsson.com> wrote:
>
> > Hi
> > I am trying to install ARIA on PC.
> > It appears the install is successful but ARIA is not working as expected.
> >
> > This is what I have on PC:
> >
> >
> >   *   Windows 7, 32 bits
> >   *   pip version 9.0.1
> >   *   python 2.7.9
> >   *   setuptools 36.2.7
> >
> > When I try to install ARIA ( I tried a couple of times), this is what
> > I
> > get:
> >
> > C:\Users\estebai\Documents\incubator-ariatosca-0.1.1>pip install .
> > Processing c:\users\estebai\documents\incubator-ariatosca-0.1.1
> >   Requirement already satisfied (use --upgrade to upgrade):
> > apache-ariatosca==0.1.1 from file:///C:/Users/estebai/
> > Documents/incubator-ariatosca-0.1.1 in c:\python27\lib\site-packages
> > Requirement already satisfied: requests<2.14.0,>=2.3.0 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: networkx<1.10,>=1.9 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: retrying<1.4.0,>=1.3.0 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: blinker<1.5,>1.3 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: jsonpickle<=0.9.4,>0.9.0 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: ruamel.yaml<0.12.0,>=0.11.12 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: Jinja2<2.9,>=2.8 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: shortuuid<0.6,>=0.5 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: CacheControl[filecache]<0.13,>=0.11.0
> > in c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: clint<0.6,>=0.5.0 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: SQLAlchemy<1.2,>=1.1.0 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: wagon==0.6.0 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Requirement already satisfied: bottle<0.13,>=0.12.0 in
> > c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> > Collecting setuptools<36.0.0,>=35.0.0 

Re: ARIA install on PC

[Ran Ziv]

Hi Steve,

It seems like your aria\exceptions.py file is of a wrong version somehow.
If you take a look at its 0.1.1 revision, you'll see the import line in
line 20 (the last line in your stack trace) is a different one than the one
mentioned in the error:
https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/orchestrator/exceptions.py#L20
(The same line appears in the 0.1.0 and master revisions, by the way)

A quick search for "from ..exceptions import AriaError" shows that this
line only appears in the aria/cli/exceptions.py module (in line 20 as well)
- I'd suggest maybe somehow this module gets loaded instead of the right
one, if I didn't have the stack trace to show me that it's specifically
"aria/exceptions.py" that's loaded - But try to open the
"aria/exceptions.py" file and see if it might look like this:
https://github.com/apache/incubator-ariatosca/blob/0.1.1/aria/cli/exceptions.py


Ran



On Mon, Aug 14, 2017 at 10:59 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> I am trying to install ARIA on PC.
> It appears the install is successful but ARIA is not working as expected.
>
> This is what I have on PC:
>
>
>   *   Windows 7, 32 bits
>   *   pip version 9.0.1
>   *   python 2.7.9
>   *   setuptools 36.2.7
>
> When I try to install ARIA ( I tried a couple of times), this is what I
> get:
>
> C:\Users\estebai\Documents\incubator-ariatosca-0.1.1>pip install .
> Processing c:\users\estebai\documents\incubator-ariatosca-0.1.1
>   Requirement already satisfied (use --upgrade to upgrade):
> apache-ariatosca==0.1.1 from file:///C:/Users/estebai/
> Documents/incubator-ariatosca-0.1.1 in c:\python27\lib\site-packages
> Requirement already satisfied: requests<2.14.0,>=2.3.0 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: networkx<1.10,>=1.9 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: retrying<1.4.0,>=1.3.0 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: blinker<1.5,>1.3 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: jsonpickle<=0.9.4,>0.9.0 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: ruamel.yaml<0.12.0,>=0.11.12 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: Jinja2<2.9,>=2.8 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: shortuuid<0.6,>=0.5 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: CacheControl[filecache]<0.13,>=0.11.0 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: clint<0.6,>=0.5.0 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: SQLAlchemy<1.2,>=1.1.0 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: wagon==0.6.0 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: bottle<0.13,>=0.12.0 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Collecting setuptools<36.0.0,>=35.0.0 (from apache-ariatosca==0.1.1)
>   Using cached setuptools-35.0.2-py2.py3-none-any.whl
> Requirement already satisfied: click<7.0,>=6.0 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: colorama<=0.3.9,>=0.3.7 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: PrettyTable<0.8,>=0.7 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: click_didyoumean==0.0.3 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: backports.shutil_get_terminal_size==1.0.0
> in c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: logutils==0.3.4.1 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: psutil<6.0.0,>=5.2.2 in
> c:\python27\lib\site-packages (from apache-ariatosca==0.1.1)
> Requirement already satisfied: decorator>=3.4.0 in
> c:\python27\lib\site-packages (from networkx<1.10,>=1.9->apache-
> ariatosca==0.1.1)
> Requirement already satisfied: six>=1.7.0 in c:\python27\lib\site-packages
> (from retrying<1.4.0,>=1.3.0->apache-ariatosca==0.1.1)
> Requirement already satisfied: ruamel.ordereddict in
> c:\python27\lib\site-packages (from ruamel.yaml<0.12.0,>=0.11.12->
> apache-ariatosca==0.1.1)
> Requirement already satisfied: MarkupSafe in c:\python27\lib\site-packages
> (from Jinja2<2.9,>=2.8->apache-ariatosca==0.1.1)
> Requirement already satisfied: msgpack-python in
> c:\python27\lib\site-packages (from CacheControl[filecache]<0.13,>
> =0.11.0->apache-ariatosca==0.1.1)
> Requirement already satisfied: lockfile>=0.9 

Re: ARIA install on MAC

[Ran Ziv]

Hi Steve,

It does sound like an issue related to the setuptools version. What made
you unable to upgrade it?

Also, these links might be helpful:
https://bitbucket.org/ruamel/yaml/issues/86/osx-cannot-install
https://bitbucket.org/ruamel/yaml/issues/32/cannot-run-setup-script-on-python-2710
https://bitbucket.org/ruamel/yaml/issues/37/osx-not-able-to-install-using-pip


Ran

On Mon, Aug 14, 2017 at 7:08 PM,  wrote:

> Hi
> I am trying to install ARIA on MACBook Pro.
> It did not work.
> See below.
> Please advise.
>
> This is what I have running:
>
> - MacOS Sierra
> - pip version 9.0.1
> - Python version 2.7.10
> - setuptools 18.5 ( I could not upgrade it)
>
> This is the error message I got during ARIA install:
>
> >
> >
> > Command "python setup.py egg_info" failed with error code 1 in
> /private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn
> /T/pip-build-Gjmmpp/ruamel.yaml/
> >
> >
>
>
> Complete output is below
>
> >
> >
> >
> >
> >
>
>
> >
> >
> > Steves-Macbook-Pro:Documents steve$ cd incubator-ariatosca-0.1.1/
> >
> > Steves-Macbook-Pro:incubator-ariatosca-0.1.1 steve$ ls
> >
> > CHANGELOG.rst MANIFEST.in VERSION examples setup.py
> >
> > CONTRIBUTING Makefile appveyor.yml extensions tests
> >
> > DISCLAIMER NOTICE aria requirements.in tox.ini
> >
> > LICENSE README.rst docs requirements.txt
> >
> > Steves-Macbook-Pro:incubator-ariatosca-0.1.1 steve$ pip install .
> >
> > Processing /Users/steve/Documents/incubator-ariatosca-0.1.1
> >
> > Collecting requests<2.14.0,>=2.3.0 (from apache-ariatosca==0.1.1)
> >
> >  Downloading requests-2.13.0-py2.py3-none-any.whl (584kB)
> >
> >  100% || 593kB 759kB/s
> >
> > Collecting networkx<1.10,>=1.9 (from apache-ariatosca==0.1.1)
> >
> >  Downloading networkx-1.9.1-py2.py3-none-any.whl (1.2MB)
> >
> >  100% || 1.2MB 673kB/s
> >
> > Collecting retrying<1.4.0,>=1.3.0 (from apache-ariatosca==0.1.1)
> >
> >  Downloading retrying-1.3.3.tar.gz
> >
> > Collecting blinker<1.5,>1.3 (from apache-ariatosca==0.1.1)
> >
> >  Downloading blinker-1.4.tar.gz (111kB)
> >
> >  100% || 112kB 1.4MB/s
> >
> > Collecting jsonpickle<=0.9.4,>0.9.0 (from apache-ariatosca==0.1.1)
> >
> >  Downloading jsonpickle-0.9.4.tar.gz (65kB)
> >
> >  100% || 71kB 3.3MB/s
> >
> > Collecting ruamel.yaml<0.12.0,>=0.11.12 (from apache-ariatosca==0.1.1)
> >
> >  Downloading ruamel.yaml-0.11.15.tar.gz (223kB)
> >
> >  100% || 225kB 1.7MB/s
> >
> >  Complete output from command python setup.py egg_info:
> >
> >  Traceback (most recent call last):
> >
> >  File "", line 1, in 
> >
> >  File "/private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn
> /T/pip-build-Gjmmpp/ruamel.yaml/setup.py", line 715, in 
> >
> >  main()
> >
> >  File "/private/var/folders/z4/2qt0n7ys58sfch0qvc9zmdwcgn
> /T/pip-build-Gjmmpp/ruamel.yaml/setup.py", line 712, in main
> >
> >  setup(**kw)
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7/distutils/core.py", line 111, in setup
> >
> >  _setup_distribution = dist = klass(attrs)
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> Extras/lib/python/setuptools/dist.py", line 272, in __init__
> >
> >  _Distribution.__init__(self,attrs)
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> lib/python2.7/distutils/dist.py", line 287, in __init__
> >
> >  self.finalize_options()
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> Extras/lib/python/setuptools/dist.py", line 326, in finalize_options
> >
> >  ep.require(installer=self.fetch_build_egg)
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> Extras/lib/python/pkg_resources/__init__.py", line 2385, in require
> >
> >  reqs = self.dist.requires(self.extras)
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> Extras/lib/python/pkg_resources/__init__.py", line 2617, in requires
> >
> >  dm = self._dep_map
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> Extras/lib/python/pkg_resources/__init__.py", line 2606, in _dep_map
> >
> >  if invalid_marker(marker):
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> Extras/lib/python/pkg_resources/__init__.py", line 1424, in
> is_invalid_marker
> >
> >  cls.evaluate_marker(text)
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> Extras/lib/python/pkg_resources/__init__.py", line 1549, in
> _markerlib_evaluate
> >
> >  env = cls._translate_metadata2(_markerlib.default_environment())
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> Extras/lib/python/pkg_resources/__init__.py", line 1537, in
> _translate_metadata2
> >
> >  for key, value in env
> >
> >  File "/System/Library/Frameworks/Python.framework/Versions/2.7/
> 

Re: Openstack plugin

[Ran Ziv]

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: Service Composition / Substitution Mapping

[Ran Ziv]

The sensible defaults Tal's mentioned sound indeed sensible to me.
I'd also like users to have control over this, though I'm a bit worried
about us getting too carried away with how arbitrarily we use policies for
configuring, well, pretty much anything. It might not be a problem right
now but I'm not certain that will remain the case in the future when the
number of them grows..


On Wed, Aug 2, 2017 at 7:14 PM, Tal Liron  wrote:

> Our goal with adding new "conventions" to ARIA, such as policies, is to
> always make them optional. The idea is that a plain-vanilla TOSCA template
> would "just work" in ARIA via sensible defaults. The extra stuff is there
> if you know you are using ARIA and you want to make use of its features.
> (The opposite is true, too: we make sure that any additions are still pure
> TOSCA and would be parsed validly by other TOSCA parsers.)
>
> On Wed, Aug 2, 2017 at 9:08 AM, DeWayne Filppi 
> wrote:
>
> > Cool.  Missed that.  That leaves things almost completely wide open from
> > the orchestrator side, IOW few predefined keys.  Too few IMHO, but if
> > everyone uses ARIA conventions it could work.
> >
> > On Tue, Aug 1, 2017 at 11:49 PM, Tal Liron  wrote:
> >
> > > I agree! Luckily metadata exists in the 1.0 spec. :)
> > >
> > > http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> > > YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#_
> Toc379455044
> > >
> > > On Tue, Aug 1, 2017 at 7:16 PM, DeWayne Filppi 
> > > wrote:
> > >
> > > > It occurs that it might be useful to be able to tag service templates
> > > with
> > > > arbitrary meta-data.  Perhaps at one level carried forward from a
> CSAR
> > > > manifest, but also user definable.  This would allow inter-service
> > > > references to be definitive, if desired.  This could be implicitly
> > > defined
> > > > as a capability by the orchestrator, but some kind of special
> > requirement
> > > > type(s) would be needed to utilize it.  This way, external repos
> could
> > be
> > > > used safely and directly without the separate load step.
> > > >
> > > > On Tue, Aug 1, 2017 at 12:43 PM, Tal Liron  wrote:
> > > >
> > > > > Thanks for the kudos. :)
> > > > >
> > > > > This topic was discussed on this list a while ago. It's indeed
> tricky
> > > to
> > > > > get right, because TOSCA leaves a lot of room for the orchestrator
> to
> > > > > implement.
> > > > >
> > > > > I'm thinking of it working something like this:
> > > > >
> > > > > 1. The reqs-and-caps engine by default will always look for
> > satisfiable
> > > > > capabilities within the currently instantiated service. HOWEVER, if
> > > such
> > > > a
> > > > > capability is not present, the option is there to look for another
> > > > > instantiated service that exposes the capabilities in substitution
> > > > > mappings.
> > > > >
> > > > > 2. If we DON'T have another instantiated service, but DO have a
> > service
> > > > > template that could fit the bill, perhaps we need to instantiate
> that
> > > > other
> > > > > service first. One obvious option is to do this automatically. But
> I
> > > feel
> > > > > like this can create unforeseen consequences -- for example, some
> > dummy
> > > > > test template that someone happened to have in the database might
> get
> > > > > instantiated by mistake. Also, it might need to trigger multiple
> > > install
> > > > > workflows at once... a big mess. So I suggest that instead we
> > provide a
> > > > > very detailed validation error here saying that the requirement
> > cannot
> > > be
> > > > > satisfied, HOWEVER there exist service templates A, B, and C that
> can
> > > > > substitute for us, so maybe the nice user would like to instantiate
> > > them
> > > > > first? This seems very reasonable to me.
> > > > >
> > > > > 3. If indeed another service satisfies this, a special node is
> added
> > to
> > > > the
> > > > > current service (with the correct type -- but without a service
> > > template
> > > > > foreign key), which serves as a proxy of the other service
> template.
> > > I'm
> > > > > not sure how we would mark this exactly. We can't use the
> service_fk
> > > > field,
> > > > > because it's still in our current service. So perhaps there's need
> > of a
> > > > new
> > > > > fk field, maybe substituted_service_fk?
> > > > >
> > > > > The above might be "sensible defaults," but it seems to me that
> users
> > > > > really need control over this. So I propose to add a new
> > > aria.Composition
> > > > > policy that would let you provide hints for this mechanism. For
> > > example,
> > > > > you might want to "filter" the target service by service template
> > name
> > > > and
> > > > > even by metadata in the service template. For example, you might
> want
> > > to
> > > > > require version 1.2.2 of a specific service, no less.
> > > > >
> > > > > Those are some quick thoughts. Exactly how such a policy would look
> 

Re: Contribution to aria

[Ran Ziv]

Sorry for the late reply, but one more important link to check out is the
contribution guide, here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+to+ARIA
It can also direct you to other Apache and general "how to get started with
Open Source" guides.

On Tue, Aug 1, 2017 at 5:42 PM, Avia Efrat  wrote:

> Hi Yuval, I went over the backlog to find issues that fit the description
> you asked for.
> Here are some suggestions:
>
> *Incredibly trivial, and could be finished very quickly:*
> https://issues.apache.org/jira/browse/ARIA-200
> (Even if it seems trivial, it could serve as a starting point on the
> process of contributing to open source projects).
>
> *CLI-related, requires less understanding of ARIA's internal
> implementation:*
> https://issues.apache.org/jira/browse/ARIA-175
> https://issues.apache.org/jira/browse/ARIA-192
> https://issues.apache.org/jira/browse/ARIA-177 &
> https://issues.apache.org/jira/browse/ARIA-233 (They are related)
>
> *TOSCA-related:*
> https://issues.apache.org/jira/browse/ARIA-267
> https://issues.apache.org/jira/browse/ARIA-102
>
> *Requires some understanding of ARIA:*
> https://issues.apache.org/jira/browse/ARIA-169
> (also, https://issues.apache.org/jira/browse/ARIA-233 from the CLI section
> can fit in here).
>
> Feel free to ask more questions, and/or ask for other options if you don't
> find any of the above as fitting. And if you decide working on one of them,
> please let us know, so we could provide further guidance on how to
> contribute to ARIA, and to open source projects in general.
>
>
> On Tue, Aug 1, 2017 at 5:07 PM, Thomas Nadeau 
> wrote:
>
> >
> > I think people here are pretty welcoming with contributions or
> > figuring things out.
> > At least the ones I’ve spoken with have been. 8)
> >
> > As for what to work on, you can look here at the backlog for
> > unassigned issues here:
> >
> > https://issues.apache.org/jira/secure/RapidBoard.jspa?
> > rapidView=150=ARIA=planning.nodetail <
> > https://issues.apache.org/jira/secure/RapidBoard.jspa?
> > rapidView=150=ARIA=planning.nodetail>
> >
> > —Tom
> >
> >
> >
> > > On Aug 1, 2017:9:44 AM, at 9:44 AM, yuval yaari 
> > wrote:
> > >
> > > Hi,
> > > I was participating on your two days tosca/cloudify course at AT in
> > > israel.
> > > You have talked about aria and i was wondering if and how i can
> > contribute
> > > some code.
> > > Im not really a python developer (have almost 6 years java experience)
> > and
> > > one of my goals is to improve my python skills by contributing to open
> > > source projects.
> > > Is there any easy/low hanging fruits bugs or mini features that you
> > think i
> > > can help with as a starting point?
> > > How do i get started with open source?
> > >
> > > Any help will be much appreciated,
> > >
> > > Thanks,
> > > Yuval
> >
> >
>

[ANNOUNCE] Apache AriaTosca 0.1.1-incubating released

[Ran Ziv]

The Apache AriaTosca (incubating) team is pleased to announce the release
of AriaTosca 0.1.1.

AriaTosca offers an easily consumable SDK and a CLI to implement TOSCA
(Topology and Orchestration Specification of Cloud Applications) based
solutions.

The release is available at:
https://www.apache.org/dyn/closer.cgi/incubator/ariatosca

Thanks,

The Apache AriaTosca (incubating) team


=
*DISCLAIMER*
Apache AriaTosca is an effort undergoing incubation at the Apache Software
Foundation (ASF), sponsored by the Apache Incubator.

Incubation is required of all newly accepted projects until a further review
indicates that the infrastructure, communications, and decision making
process
have stabilized in a manner consistent with other successful ASF projects.

While incubation status is not necessarily a reflection of the completeness
or stability of the code, it does indicate that the project has yet to be
fully endorsed by the ASF.

[RESULT][VOTE] Apache ariatosca 0.1.1 (incubating)

[Ran Ziv]

Dear IPMC Community,

I am pleased to announce that the Incubator PMC has approved the release
of Apache ariatosca 0.1.1 (incubating).

The vote has passed with:
- three binding "+1" votes, and two non-binding "+1" votes
- no "0" votes
- no "-1" votes

The votes were  (
https://lists.apache.org/thread.html/0c5fe55ddeb138bc318242f96d529ce7c2be4c222c0d758562f5ea45@%3Cgeneral.incubator.apache.org%3E
):
- +1, John D. Ament (binding)
- +1, Suneel Marthi (binding)
- +1, sblack...@apache.org (binding)
- +1, Ran Ziv (non-binding)
- +1, Maxim Orlov (non-binding)

Thank you for your support!

We'll continue with the release now.

Ran,
on behalf of Apache ariatosca PPMC

[VOTE] publish ariatosca 0.1.1

[Ran Ziv]

The ariatosca community voted on and has approved a proposal to release
ariatosca 0.1.1.
Pursuant to the Releases section of the Incubation Policy and with the
endorsement of our mentors, we would now like to request the permission of
the Incubator PMC to publish the tarball on Apache's /dist/release.


Proposal:
https://lists.apache.org/thread.html/b0571ee44c5f5bb325cc7f4
9e475e3219c5ca89d78d22a3ac203a77c@%3Cdev.ariatosca.apache.org%3E


Vote result:
https://lists.apache.org/thread.html/a2271fa86a2d0d9926a53c165b9a8a50218d12ca01a651bdd0af5122@%3Cdev.ariatosca.apache.org%3E


Release candidate package may be found at:
https://dist.apache.org/repos/dist/dev/incubator/ariatosca/0.1.1-incubating/
The "source" directory contains the actual source snapshot as required per
an Apache release.
the "sdist" and "bdist" directories are Pythonic source and binary
distributions, to be uploaded on PyPI upon a successful vote.

See more information about the package in the original proposal thread.



Please vote by Sunday, July 16th, at 14:00 UTC.


Thanks,
Ran

[RESULT][VOTE] Apache ariatosca 0.1.1 (incubating)

[Ran Ziv]

The vote has passed with:
 - Three binding "+1" votes
 - no "0" votes
 - no "-1" votes

The votes were:
 - +1, Suneel Marthi (binding)
 - +1, Maxim Orlov (binding)
 - +1, Ran Ziv (binding)

Vote thread:
https://lists.apache.org/thread.html/b0571ee44c5f5bb325cc7f49e475e3
219c5ca89d78d22a3ac203a77c@%3Cdev.ariatosca.apache.org%3E


I'll send this to the incubator's general list for the official incubator
vote now.

Thanks,
Ran

Re: Congrats on the First Release!

[Ran Ziv]

I've documented the release process on our Confluence:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Release+Process

This, together with the release automation script
<https://issues.apache.org/jira/browse/ARIA-307>, should hopefully make
things much simpler for the release manager of the next release.


Please let me know if you have any comments on the document or if you think
I might have missed something.



On Mon, Jul 10, 2017 at 4:11 PM, Ran Ziv <r...@gigaspaces.com> wrote:

> Done:
> https://issues.apache.org/jira/browse/ARIA-306 ( with sub-tasks
> https://issues.apache.org/jira/browse/ARIA-307 and
> https://issues.apache.org/jira/browse/ARIA-308 )
> https://issues.apache.org/jira/browse/ARIA-309
>
>
> On Mon, Jul 10, 2017 at 3:54 PM, John D. Ament <johndam...@apache.org>
> wrote:
>
>> Ran,
>>
>> Do you want to create JIRAs for these?
>>
>> John
>>
>> On Mon, Jul 10, 2017 at 8:13 AM Ran Ziv <r...@gigaspaces.com> wrote:
>>
>> > Thanks :)
>> >
>> > 1) Documenting the release process - I have it on my list and will get
>> it
>> > on our Confluence soon. I also wrote some scripts to ease this process,
>> > we'll probably merge them onto the repo one way or another soon.
>> > 2) The sdist comes with generated HTML pages; We should probably have
>> these
>> > on our website as well.
>> > 3) One already exists on our confluence - here:
>> > https://cwiki.apache.org/confluence/display/ARIATOSCA/Contri
>> buting+to+ARIA
>> > and here:
>> > https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+Code
>> > 4) Making things easily discoverable - IMO that's mostly website work,
>> need
>> > to make sure the website links everywhere needed including our
>> Confluence
>> > etc..
>> > 5) Downloads page - yup, more website work :)
>> >
>> >
>> > Thanks for the tips, I hope we'll be able to follow up on those shortly.
>> >
>> >
>> >
>> > On Mon, Jul 10, 2017 at 1:04 AM, Suneel Marthi <suneel.mar...@gmail.com
>> >
>> > wrote:
>> >
>> > > Same here, congrats Team on first release.
>> > >
>> > > On Sun, Jul 9, 2017 at 5:20 PM, John D. Ament <johndam...@apache.org>
>> > > wrote:
>> > >
>> > > > All,
>> > > >
>> > > > I wanted to express my well wishes to you all on a successful first
>> > > > release.  Most podlings see this as a milestone, I'll be updating
>> the
>> > > > various tracking sheets shortly with this note.
>> > > >
>> > > > So what's next?  Once the mechanics of a release are squared away,
>> > > projects
>> > > > figure out ways to grow the community.  Here's a short list of
>> things
>> > I'd
>> > > > recommend:
>> > > >
>> > > > - Make sure the release process is documented and that the next
>> release
>> > > has
>> > > > a different release manager.
>> > > > - Start putting together developer centric documentation.  This may
>> > > include
>> > > > some high level architecture, written designs.
>> > > > - Put together a contributor's guide.  This may explain how the
>> project
>> > > > works (via github pull requests), creating JIRA tickets, browsing
>> > > fisheye,
>> > > > testing locally.
>> > > > - Make all of this easily discoverable.  We have a lot of these
>> > > documents,
>> > > > but they may be hard to find.
>> > > > - Make sure we have a downloads page that points to the source
>> release
>> > > (ASF
>> > > > requirement).
>> > > >
>> > > > John
>> > > >
>> > >
>> >
>>
>
>

Re: workflow runner error

[Ran Ziv]

I think upgrade paths is not really a topic that should be discussed at the
moment - we're at a 0.x.y release with no backward compatibility
guarantees, plus, the version that was used prior to the current version in
this case was an unreleased version, so an upgrade path wouldnt have been
viable to begin with.

Providing a nicer error message could possibly be a nice improvement
though. Feel free to create a JIRA issue for this.


On Thu, Jul 13, 2017 at 10:51 AM, Tal Liron <t...@gigaspaces.com> wrote:

> I wonder if we should provide a better upgrade path here. Perhaps we need
> to add a file with some meta information about the version of the database.
> We don't necessarily have to provide an automatic upgrade to a new database
> format, but least we can tell the user that the database is out of date and
> needs resetting. What do you think?
>
> On Thu, Jul 13, 2017 at 3:40 AM, DeWayne Filppi <dewa...@gigaspaces.com>
> wrote:
>
> > Yes, that absolutely could be the case.  I'll try a reset.
> >
> > On Wed, Jul 12, 2017 at 3:40 PM, Ran Ziv <r...@gigaspaces.com> wrote:
> >
> > > Could it be that you first used an older, non-release version of ARIA,
> > and
> > > then used 0.1.0 without first resetting your ARIA working directory
> (e.g.
> > > "aria reset -f")?
> > >
> > > The task table should indeed have the said column, as can be seen here:
> > > https://github.com/apache/incubator-ariatosca/blob/0.1.
> > > 0/aria/modeling/orchestration.py#L410
> > >
> > >
> > > If this is not the cause for your problem, perhaps attach the workflow
> in
> > > question as well, since the problem occurs during the workflow
> > compilation
> > > phase.
> > >
> > >
> > >
> > > On Wed, Jul 12, 2017 at 7:41 PM, DeWayne Filppi <
> dewa...@gigaspaces.com>
> > > wrote:
> > >
> > > > When executing this:
> > > >
> > > >   runner = WorkflowRunner(model_storage, resource_storage,
> > > plugin_manager,
> > > >   service_id = service_id,
> > > >   workflow_name = workflow_name,
> > > >   inputs = inputs,
> > > >   executor = executor,
> > > >   task_max_attempts =  task_max_attempts,
> > > >   task_retry_interval = task_retry_interval)
> > > >
> > > > I get this:
> > > >
> > > >   File
> > > > "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> > > > workflow_runner.py",
> > > > line 102, in __init__
> > > > compiler.compile(self._tasks_graph)
> > > >   File
> > > > "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> > > > workflows/core/graph_compiler.py",
> > > > line 44, in compile
> > > > start_stub_type, depends_on, self._start_graph_suffix(task_
> > graph.id
> > > ),
> > > > task_graph.name,
> > > >   File
> > > > "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> > > > workflows/core/graph_compiler.py",
> > > > line 80, in _create_stub_task
> > > > self._ctx.model.task.put(model_task)
> > > >   File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_
> > mapi.py",
> > > > line 124, in put
> > > > self._safe_commit()
> > > >   File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_
> > mapi.py",
> > > > line 187, in _safe_commit
> > > > raise exceptions.StorageError('SQL Storage error:
> > > {0}'.format(str(e)))
> > > > StorageError: SQL Storage error: (sqlite3.OperationalError) *table
> task
> > > has
> > > > no column named interface_name* [SQL: u'INSERT INTO task (name,
> status,
> > > > due_at, started_at, ended_at, attempts_count, function, max_attempts,
> > > > retry_interval, ignore_failure, interface_name, operation_name,
> > _api_id,
> > > > _executor, _context_cls, _stub_type, plugin_fk, execution_fk,
> > > > relationship_fk, node_fk) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> > ?,
> > > ?,
> > > > ?, ?, ?, ?, ?, ?)'] [parameters:
> > > > ('install.fdf601e4-4d14-4ddf-9e57-f2c09b5293f7', 'pending',
> > '2017-07-10
> > > > 04:14:20.892673', None, None, 1, None, 1, 0.0, 0, None, None, None,
> > > > ,
> None,
> > > > 'start_workflow', None, 1, None, None)]
> > > >
> > > > I'm running 0.1.0.
> > > >
> > > > -- DeWayne
> > > >
> > > > --
> > > > DeWayne Filppi, Director, Solutions Architect <http://cloudify.co>
> > > > --
> > > > M: +17145121706 http://cloudify.co @dfilppi
> > > > <https://twitter.com/CloudifySource>
> > > > <https://www.linkedin.com/company-beta/17918192/>
> > > > <https://github.com/cloudify-cosmo>
> > > > <https://www.youtube.com/cloudifysource>
> > > >
> > >
> >
> >
> >
> > --
> > DeWayne Filppi, Director, Solutions Architect <http://cloudify.co>
> > --
> > M: +17145121706 http://cloudify.co @dfilppi
> > <https://twitter.com/CloudifySource>
> > <https://www.linkedin.com/company-beta/17918192/>
> > <https://github.com/cloudify-cosmo>
> > <https://www.youtube.com/cloudifysource>
> >
>

Re: workflow runner error

[Ran Ziv]

Could it be that you first used an older, non-release version of ARIA, and
then used 0.1.0 without first resetting your ARIA working directory (e.g.
"aria reset -f")?

The task table should indeed have the said column, as can be seen here:
https://github.com/apache/incubator-ariatosca/blob/0.1.0/aria/modeling/orchestration.py#L410


If this is not the cause for your problem, perhaps attach the workflow in
question as well, since the problem occurs during the workflow compilation
phase.



On Wed, Jul 12, 2017 at 7:41 PM, DeWayne Filppi 
wrote:

> When executing this:
>
>   runner = WorkflowRunner(model_storage, resource_storage, plugin_manager,
>   service_id = service_id,
>   workflow_name = workflow_name,
>   inputs = inputs,
>   executor = executor,
>   task_max_attempts =  task_max_attempts,
>   task_retry_interval = task_retry_interval)
>
> I get this:
>
>   File
> "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> workflow_runner.py",
> line 102, in __init__
> compiler.compile(self._tasks_graph)
>   File
> "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> workflows/core/graph_compiler.py",
> line 44, in compile
> start_stub_type, depends_on, self._start_graph_suffix(task_graph.id),
> task_graph.name,
>   File
> "/home/vagrant/src/incubator-ariatosca/aria/orchestrator/
> workflows/core/graph_compiler.py",
> line 80, in _create_stub_task
> self._ctx.model.task.put(model_task)
>   File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_mapi.py",
> line 124, in put
> self._safe_commit()
>   File "/home/vagrant/src/incubator-ariatosca/aria/storage/sql_mapi.py",
> line 187, in _safe_commit
> raise exceptions.StorageError('SQL Storage error: {0}'.format(str(e)))
> StorageError: SQL Storage error: (sqlite3.OperationalError) *table task has
> no column named interface_name* [SQL: u'INSERT INTO task (name, status,
> due_at, started_at, ended_at, attempts_count, function, max_attempts,
> retry_interval, ignore_failure, interface_name, operation_name, _api_id,
> _executor, _context_cls, _stub_type, plugin_fk, execution_fk,
> relationship_fk, node_fk) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?,
> ?, ?, ?, ?, ?, ?)'] [parameters:
> ('install.fdf601e4-4d14-4ddf-9e57-f2c09b5293f7', 'pending', '2017-07-10
> 04:14:20.892673', None, None, 1, None, 1, 0.0, 0, None, None, None,
> , None,
> 'start_workflow', None, 1, None, None)]
>
> I'm running 0.1.0.
>
> -- DeWayne
>
> --
> DeWayne Filppi, Director, Solutions Architect 
> --
> M: +17145121706 http://cloudify.co @dfilppi
> 
> 
> 
> 
>

Re: Missing support for type qualified name

[Ran Ziv]

Thanks DJ, I noticed :) Actually, Maxim has already started reviewing the
PR.

On Wed, Jul 12, 2017 at 9:15 AM, D Jayachandran <d.jayachand...@ericsson.com
> wrote:

> Hi Ran,
>
> I had some issue with committing changes to this PR. I closed the PR and
> opened a new one.
> Now the CI tests and build jobs are successful. Kindly check and let me
> know if its fine.
>
> Regards,
> DJ
> -----Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Tuesday, July 11, 2017 2:07 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Missing support for type qualified name
>
> Hi DJ,
>
> You shouldn't create another PR - the current should simply update when
> you push your changes into the relevant branch in your fork (in this case,
> the master branch).
>
> At the moment I see 4 commits on the PR, and it seems to still be broken.
> If it hasn't updated yet, please update it.
> If it is already updated, please have a look at the errors, or let me know
> if you need any help with debugging it :)
>
> Ran
>
> On Tue, Jul 11, 2017 at 10:53 AM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
> > Hi Ran,
> >
> > I fixed those issues. I have commited those with changes , am not sure
> > if I have to make another PR ?
> > Could you please advice me here ?
> >
> >
> > Regards,
> > DJ
> >
> > -Original Message-
> > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > Sent: Friday, July 07, 2017 3:28 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: Missing support for type qualified name
> >
> > Hi DJ,
> >
> > Thank you for creating this pull request.
> > I've added you as a Contributor (role) on JIRA, so you can now be
> > assigned to ARIA issues. I've assigned you to ARIA-277 as well.
> >
> > Regarding the PR itself, it seems to be currently failing some CI tests.
> > Please see these links:
> > https://github.com/apache/incubator-ariatosca/pull/179
> > https://travis-ci.org/apache/incubator-ariatosca/builds/
> > 251017348?utm_source=github_status_medium=notification
> > https://ci.appveyor.com/project/ApacheSoftwareFoundation/
> > incubator-ariatosca/build/1.0.2410
> >
> >
> > Let me know if you need any help trying to debug or figure out these
> > issues
> > :)
> >
> > Ran
> >
> > On Sun, Jun 11, 2017 at 11:36 AM, Ran Ziv <r...@gigaspaces.com> wrote:
> >
> > > Thanks DJ.
> > >
> > > Note that in order for the project to be able to accept your pull
> > > request, you'd first have to sign up Apache's ICLA agreement.
> > > See more here <https://www.apache.org/dev/new-committers-guide.html>.
> > >
> > > Ran
> > >
> > > On Fri, Jun 9, 2017 at 2:04 PM, D Jayachandran <
> > > d.jayachand...@ericsson.com> wrote:
> > >
> > >> Hi Ran/Tal,
> > >>
> > >> Thanks for the confirmation. I have created a JIRA issue
> > >> https://issues.apache.org/jira/browse/ARIA-277
> > >> We will let you know when we fork and make a pull request for this.
> > >>
> > >> Regards,
> > >> DJ
> > >> -Original Message-
> > >> From: Tal Liron [mailto:t...@gigaspaces.com]
> > >> Sent: Thursday, June 08, 2017 11:47 PM
> > >> To: dev@ariatosca.incubator.apache.org
> > >> Subject: Re: Missing support for type qualified name
> > >>
> > >> Thanks, DJ. This was on the list of things to do but we indeed
> > >> forgot to create a JIRA for it...
> > >>
> > >> On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv <r...@gigaspaces.com> wrote:
> > >>
> > >> > Hi DJ,
> > >> >
> > >> > Sounds good. Feel free to create a new JIRA yourself!  And thanks
> > >> > for posting on the dev list before creating this issue.
> > >> > One small note, I'd personally think of this as a "story" rather
> > >> > than a "bug" - We don't yet claim to be 100% TOSCA complaint, and
> > >> > we're familiar with several other missing spec sections
> > >> > implementations at
> > >> the moment.
> > >> >
> > >> > Let me know if you need any help.
> > >> > Tal might have more to add on this (Type qualified name) as well.
> > >> >
> > >> > Thank you
> > >> > Ran
> > >> >
> > >> >
> > >> >

Re: workflow list API

[Ran Ziv]

There's actually a JIRA issue for it:
https://issues.apache.org/jira/browse/ARIA-246

Although, as Tal's mentioned, we've never been 100% certain yet about what
should be the behavior here.


On Wed, Jul 12, 2017 at 8:33 AM, Tal Liron  wrote:

> Do you mean the CLI command?
>
> We actually have talked about this in the past, and the question was just
> how much the "built-in" (normative lifecycle) workflows should be
> considered as equivalent to any arbitrary workflow. Can you think of
> arguments for or against this thinking?
>
> On Wed, Jul 12, 2017 at 12:52 AM, DeWayne Filppi 
> wrote:
>
> > The workflow list API call doesn't return "normative" workflows (like
> > "install").  Intentional?
> >
> > -- DeWayne
> >
>

Re: [VOTE] publish ariatosca 0.1.1

[Ran Ziv]

1) Validated signature & checksums
2) Validated LICENSE, NOTICE, DISCLAIMER, "-incubating" in file name
3) Ran RAT check
4) Made a clean install using "pip install ."
5) Ran tests using "make test"


+1 binding



On Tue, Jul 11, 2017 at 12:08 PM, Maxim Orlov <ma...@gigaspaces.com> wrote:

>1. Validated signature & checksums
>2. Validated LICENSE, NOTICE, DISCLAIMER, "-incubating" in file name
>3. Ran RAT check
>4. Made a clean install using "pip install ."
>5. Ran tests using "make test"
>
> +1
>
> On Tue, Jul 11, 2017 at 2:27 AM, Suneel Marthi <smar...@apache.org> wrote:
>
> > +1 binding
> >
> > 1. Checked Sigs and Hashes
> > 2. Verified RAT check
> >
> >
> > On Mon, Jul 10, 2017 at 1:04 PM, Ran Ziv <r...@gigaspaces.com> wrote:
> >
> > > This is a vote to release Apache AriaTosca (Incubating) 0.1.1.
> > > If the vote passes, another vote for approving the release will take
> > place
> > > on the Apache Incubator's PMC.
> > >
> > >
> > > I created a tarball candidate for the 0.1.1 release and placed it in
> > ARIA's
> > > /dist/dev folder:
> > > *https://dist.apache.org/repos/dist/dev/incubator/
> > > ariatosca/0.1.1-incubating/
> > > <https://dist.apache.org/repos/dist/dev/incubator/
> > > ariatosca/0.1.1-incubating/>*
> > >
> > > The directory contains three packages:
> > > source - The canonical Apache release - a snapshot of the repository.
> > > sdist - The pythonic source distribution - contains generated docs,
> > > examples, and files needed for install from source (yet doesn't contain
> > > tests etc.).
> > > bdist - The pythonic binary distribution - contains compiled code.
> > >
> > >
> > > The sdist and bdist packages have been uploaded to test-PyPI:
> > > https://test.pypi.org/project/apache-ariatosca/0.1.1/
> > >
> > >
> > > The list of issues Resolved for this release can be found in the
> > CHANGELOG
> > > or here:
> > > <https://issues.apache.org/jira/browse/ARIA-295?filter=-
> > > 1=project%3Dariatosca%20and%20status%20in%20(
> resolved%2C%20closed)>
> > > https://issues.apache.org/jira/browse/ARIA-312?filter=-
> > > 1=project%3Dariatosca%20and%20status%20in%20(
> > > resolved%2C%20closed)%20and%20fixVersion%3D0.1.1
> > >
> > >
> > > Instructions for installation etc. may be found in the README file
> inside
> > > the tarball.
> > > (Please note that the relevant installation instructions are for
> "source
> > > installation", not "install from PyPI")
> > >
> > >
> > > To use RAT to validate package conformance with ASF standards, please
> use
> > > the ".rat-excludes" file, for example:
> > > java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes
> > >
> > >
> > >
> > > The vote will last 72 hours.
> > >
> > > Please vote:
> > >
> > > [ ] +1: Good to go!
> > > [ ] 0: I don't care
> > > [ ] -1: Don't release this because...
> > >
> > >
> > > Thanks,
> > > Ran
> > >
> >
>

Re: Missing support for type qualified name

[Ran Ziv]

Hi DJ,

You shouldn't create another PR - the current should simply update when you
push your changes into the relevant branch in your fork (in this case, the
master branch).

At the moment I see 4 commits on the PR, and it seems to still be broken.
If it hasn't updated yet, please update it.
If it is already updated, please have a look at the errors, or let me know
if you need any help with debugging it :)

Ran

On Tue, Jul 11, 2017 at 10:53 AM, D Jayachandran <
d.jayachand...@ericsson.com> wrote:

> Hi Ran,
>
> I fixed those issues. I have commited those with changes , am not sure if
> I have to make another PR ?
> Could you please advice me here ?
>
>
> Regards,
> DJ
>
> -----Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Friday, July 07, 2017 3:28 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Missing support for type qualified name
>
> Hi DJ,
>
> Thank you for creating this pull request.
> I've added you as a Contributor (role) on JIRA, so you can now be assigned
> to ARIA issues. I've assigned you to ARIA-277 as well.
>
> Regarding the PR itself, it seems to be currently failing some CI tests.
> Please see these links:
> https://github.com/apache/incubator-ariatosca/pull/179
> https://travis-ci.org/apache/incubator-ariatosca/builds/
> 251017348?utm_source=github_status_medium=notification
> https://ci.appveyor.com/project/ApacheSoftwareFoundation/
> incubator-ariatosca/build/1.0.2410
>
>
> Let me know if you need any help trying to debug or figure out these issues
> :)
>
> Ran
>
> On Sun, Jun 11, 2017 at 11:36 AM, Ran Ziv <r...@gigaspaces.com> wrote:
>
> > Thanks DJ.
> >
> > Note that in order for the project to be able to accept your pull
> > request, you'd first have to sign up Apache's ICLA agreement.
> > See more here <https://www.apache.org/dev/new-committers-guide.html>.
> >
> > Ran
> >
> > On Fri, Jun 9, 2017 at 2:04 PM, D Jayachandran <
> > d.jayachand...@ericsson.com> wrote:
> >
> >> Hi Ran/Tal,
> >>
> >> Thanks for the confirmation. I have created a JIRA issue
> >> https://issues.apache.org/jira/browse/ARIA-277
> >> We will let you know when we fork and make a pull request for this.
> >>
> >> Regards,
> >> DJ
> >> -Original Message-
> >> From: Tal Liron [mailto:t...@gigaspaces.com]
> >> Sent: Thursday, June 08, 2017 11:47 PM
> >> To: dev@ariatosca.incubator.apache.org
> >> Subject: Re: Missing support for type qualified name
> >>
> >> Thanks, DJ. This was on the list of things to do but we indeed forgot
> >> to create a JIRA for it...
> >>
> >> On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv <r...@gigaspaces.com> wrote:
> >>
> >> > Hi DJ,
> >> >
> >> > Sounds good. Feel free to create a new JIRA yourself!  And thanks
> >> > for posting on the dev list before creating this issue.
> >> > One small note, I'd personally think of this as a "story" rather
> >> > than a "bug" - We don't yet claim to be 100% TOSCA complaint, and
> >> > we're familiar with several other missing spec sections
> >> > implementations at
> >> the moment.
> >> >
> >> > Let me know if you need any help.
> >> > Tal might have more to add on this (Type qualified name) as well.
> >> >
> >> > Thank you
> >> > Ran
> >> >
> >> >
> >> > On Wed, Jun 7, 2017 at 3:35 PM, D Jayachandran <
> >> > d.jayachand...@ericsson.com>
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > TOSCA Simple Yaml 1.0 profile specification supports usage of
> >> > > the following Namespace Alias
> >> > >
> >> > >   1.  Shorthand Name
> >> > >   2.  Type Qualified Name
> >> > >   3.  Type URI
> >> > >
> >> > > ARIA currently supports only "Shorthand Name" and "Type URI". The
> >> > > support for "Type Qualified Name" is missing which is required to
> >> > > adhere with the TOSCA Simple yaml 1.0 specifications. Could this
> >> > > be considered as bug
> >> > and a
> >> > > JIRA issue opened for this ?
> >> > > We would like to start our contribution with this.
> >> > >
> >> > >
> >> > > Regards,
> >> > > DJ
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Tal Liron
> >> Senior Engineer
> >> t...@gigaspaces.com | +1 (773) 828-9339 Cloudify |
> >> http://getcloudify.org
> >> <http://getcloudify.org?utm_source=signaturesatori_mediu
> >> m=email_campaign=general_signature>
> >>
> >> <https://twitter.com/CloudifySource>
> >> <https://www.linkedin.com/groups/8467478>
> >> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-
> cosmo>
> >> [image: Azure Webinar]
> >> <http://getcloudify.org/webinars/Azure-plugin-for-cloudify-
> >> webinar.html?utm_source=signaturesatori_medium=
> >> email_campaign=general_signature>
> >>
> >
> >
>

Re: Inputs to a life cycle operation

[Ran Ziv]

The issue was indeed merged a few days ago.
Note however that it's not a part of the 0.1.0 release (nor will it be a
part of the 0.1.1 one, as it wasn't categorized as a bug fix but as a new
feature). It will be a part of a future 0.2.0 release.

On Mon, Jul 3, 2017 at 1:39 PM, Ran Ziv <r...@gigaspaces.com> wrote:

> Hi DJ,
>
> You're definitely correct - this issue is in fact already in a pull
> request <https://github.com/apache/incubator-ariatosca/pull/145>, and
> will hopefully be merged soon.
>
>
> Ran
>
> On Mon, Jul 3, 2017 at 1:04 PM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
>> Hi,
>>
>> With the current ARIA implementation,
>>
>>
>>   *   Only the operation level inputs, (inputs under
>> "create","configure","start","stop") are passed during a workflow
>> execution.
>>   *   As per TOSCA spec Interface level inputs ( inputs under
>> "Standard" Interface) can also be defined
>>
>> With the above points, don't the interface level inputs also be passed
>> for any operation Task ?
>> I think interface level inputs needs to be merged with operation level
>> but the operation level inputs taking precedence.
>> Please let us know if the above understanding is correct and could be
>> fixed in ARIA ?
>>
>> Regards,
>> DJ
>>
>
>

Re: Installation issue in 0.1.0 release

[Ran Ziv]

I created a new voting thread for a 0.1.1 release candidate.

I understand it's important someone else does the release manager's role as
well, but since this is a quick fix version I hope it's ok I took it again
upon myself.
We'll make sure next time someone else takes this role.


On Mon, Jul 10, 2017 at 4:28 PM, Suneel Marthi <smar...@apache.org> wrote:

> ...and that's something i follow even on the TLPs I am involved with - more
> frequent releases
>
> On Mon, Jul 10, 2017 at 8:54 AM, John D. Ament <johndam...@apache.org>
> wrote:
>
> > IMHO, podlings should try to cut releases frequently.  Gets in the habit
> of
> > how to do it.  So if you or someone else has the cycles to cut the
> release
> > I say do it.
> >
> > I personally don't care what version it is, its just a number.
> >
> > John
> >
> > On Mon, Jul 10, 2017 at 8:13 AM Ran Ziv <r...@gigaspaces.com> wrote:
> >
> > > I've found the following issue with the 0.1.0 release:
> > > https://issues.apache.org/jira/browse/ARIA-304
> > >
> > > A fix for this has already been merged into master; PR can be seen
> here:
> > > https://github.com/apache/incubator-ariatosca/pull/178
> > >
> > >
> > >
> > > I'm proposing the possibility of creating a quick 0.1.1 release for
> > fixing
> > > this bug.
> > > On one hand it's not necessarily in the main path (requires optional
> > > dependency installation, not relevant for Windows) and has a simple
> > > workaround (see comment on the JIRA issue); On the other hand, it's a
> > > pretty annoying bug that could deter users from using the 0.1.0, and
> the
> > > fix is simple.
> > >
> > >
> > > If we're to release a 0.1.1 package, there are a few other bug fixes
> that
> > > have been merged since the original 0.1.0 proposal, that we could have
> > as a
> > > part of this release as well:
> > > https://issues.apache.org/jira/browse/ARIA-296
> > > https://issues.apache.org/jira/browse/ARIA-202
> > > https://issues.apache.org/jira/browse/ARIA-298
> > > https://issues.apache.org/jira/browse/ARIA-287
> > >
> > >
> > > What do you think?
> > >
> > > Ran
> > >
> >
>

Re: Query on operation inputs

[Ran Ziv]

onInputs
> > >
> > > regards,
> > > DJ
> > >
> > > -Original Message-
> > > From: Tal Liron [mailto:t...@gigaspaces.com]
> > > Sent: Thursday, June 01, 2017 9:59 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: Query on operation inputs
> > >
> > > I'm still a bit confused by all this. DJ, could you possibly create a
> > > quick git repo with your complete example to make sure we're all on the
> > > same page here?
> > >
> > > On Thu, Jun 1, 2017 at 7:10 AM, Ran Ziv <r...@gigaspaces.com> wrote:
> > >
> > > > Right, it makes more sense now :) But now I simply have to say again
> > > > that as far as I can tell this should in fact be the intended
> behavior.
> > > >
> > > > What would you rather happen? the "labels" parameter be assigned with
> > > > "None" instead?
> > > > We considered this but part of the problem here is that the
> > > > information about whether an input is required or not is no longer
> > > > available at this stage so it's impossible to know whether to use
> > "None"
> > > or raise an error.
> > > > Tal and I have talked about it in the past, and from what I remember,
> > > > Tal said the "required" field information in fact should not be
> > > > stored, and is only relevant for parsing phase. It is possible I'm
> > > > getting this wrong though :)
> > > >
> > > > I'm open for changes here as it is a somewhat confusing behavior -
> > > > although I think it does make sense after all.
> > > >
> > > >
> > > >
> > > > On Thu, Jun 1, 2017 at 3:04 PM, D Jayachandran <
> > > > d.jayachand...@ericsson.com>
> > > > wrote:
> > > >
> > > > > Hi Ran/Tal,
> > > > >
> > > > > I was wrong, Tal's branch still throws the validation error (I was
> > > > loading
> > > > > a different service template) :). So the issue which I told still
> > > > > exists
> > > > >
> > > > > [root@DJ-DEV tal-test]# python /root/tal-test/incubator-
> > > > ariatosca/aria/cli/main.py
> > > > > executions start install -s s2
> > > > > Declared parameters "labels" have not been provided values
> > > > >
> > > > > Regards,
> > > > > DJ
> > > > >
> > > > > -Original Message-
> > > > > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > > > > Sent: Thursday, June 01, 2017 5:24 PM
> > > > > To: dev@ariatosca.incubator.apache.org
> > > > > Subject: Re: Query on operation inputs
> > > > >
> > > > > Again, there's a difference between the "required" validation and
> > > > > the actual runtime validation. the runtime one cannot be done
> during
> > > > > instantiation phase, which is why there are two separate
> validations.
> > > > >
> > > > > I do not know how come Tal's branch (which by now has been merged
> to
> > > > > master) helped fixing your issue, so I might have misunderstood
> > > > > something about your problem :)
> > > > >
> > > > > Ran
> > > > >
> > > > > On Thu, Jun 1, 2017 at 2:11 PM, D Jayachandran <
> > > > > d.jayachand...@ericsson.com>
> > > > > wrote:
> > > > >
> > > > > > Hi Tal,
> > > > > >
> > > > > > I did test your branch  https://github.com/apache/
> > > > > > incubator-ariatosca/tree/ARIA-149-functions-in-operation-
> configura
> > > > > > tion and it seems to have the fix for operation/interface inputs.
> > > > > >
> > > > > > Regards,
> > > > > > DJ
> > > > > > -Original Message-
> > > > > > From: D Jayachandran
> > > > > > Sent: Thursday, June 01, 2017 4:40 PM
> > > > > > To: dev@ariatosca.incubator.apache.org
> > > > > > Subject: RE: Query on operation inputs
> > > > > >
> > > > > > Hi Ran,
> > > > > >
> > > > > > The validation of operation inputs is also done during
> > instantiation.
> > > > > >

[VOTE] publish ariatosca 0.1.1

[Ran Ziv]

This is a vote to release Apache AriaTosca (Incubating) 0.1.1.
If the vote passes, another vote for approving the release will take place
on the Apache Incubator's PMC.


I created a tarball candidate for the 0.1.1 release and placed it in ARIA's
/dist/dev folder:
*https://dist.apache.org/repos/dist/dev/incubator/ariatosca/0.1.1-incubating/
*

The directory contains three packages:
source - The canonical Apache release - a snapshot of the repository.
sdist - The pythonic source distribution - contains generated docs,
examples, and files needed for install from source (yet doesn't contain
tests etc.).
bdist - The pythonic binary distribution - contains compiled code.


The sdist and bdist packages have been uploaded to test-PyPI:
https://test.pypi.org/project/apache-ariatosca/0.1.1/


The list of issues Resolved for this release can be found in the CHANGELOG
or here:

https://issues.apache.org/jira/browse/ARIA-312?filter=-1=project%3Dariatosca%20and%20status%20in%20(resolved%2C%20closed)%20and%20fixVersion%3D0.1.1


Instructions for installation etc. may be found in the README file inside
the tarball.
(Please note that the relevant installation instructions are for "source
installation", not "install from PyPI")


To use RAT to validate package conformance with ASF standards, please use
the ".rat-excludes" file, for example:
java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes



The vote will last 72 hours.

Please vote:

[ ] +1: Good to go!
[ ] 0: I don't care
[ ] -1: Don't release this because...


Thanks,
Ran

Re: [VOTE] Add an 'entry-level' label to some of our Jira issues

[Ran Ziv]

"Simple" sounds good (and simple :))

Re providing links to the TOSCA theoretical overview, this is one more
website task we need to do.
I added it to the JIRA issue here:
https://issues.apache.org/jira/browse/ARIA-309




On Mon, Jul 10, 2017 at 3:58 PM, Steve Baillargeon <
steve.baillarg...@ericsson.com> wrote:

> Hi
> Do you intend to introduce "other levels" or just one label for beginners?
> If you only need one level, then maybe it is best to call it "simple" or
> 'basic"?
>
> Hi Avia and Tal,
> Is it possible to store the quick introduction to TOSCA and theoretical
> overview for everyone to see?
> Thanks
>
> Steve B
>
>
>
>
> -Original Message-
> From: Ran Ziv [mailto:r...@gigaspaces.com]
> Sent: Monday, July 10, 2017 4:39 AM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: [VOTE] Add an 'entry-level' label to some of our Jira issues
>
> I'm all for it, though I don't really like "entry-level" for the name of
> the label :) Any other suggestions?
>
>
> On Mon, Jul 10, 2017 at 5:09 AM, John D. Ament <johndam...@apache.org>
> wrote:
>
> > I think it's a good idea.  Lots of other projects do something
> > similar.  We could link to a query with this from the proposed
> > contributing guide I emailed about earlier.  If we put the
> > contributing guide on confluence, I believe we can even embed a report.
> >
> > John
> >
> > On Sun, Jul 9, 2017 at 9:34 PM Avia Efrat <a...@gigaspaces.com> wrote:
> >
> > > Today Tal (t...@gigaspaces.com) and myself had a very long and
> > > productive face-to-face session with some AT developers about
> > > ARIA. We did a quick introduction to TOSCA (as some of them where
> > > already familiar with it), followed by an theoretical overview and
> live demo of ARIA 0.1.0.
> > >
> > > Some of the AT guys were very interested in contributing to ARIA,
> > > and raised what I think is a very good suggestion. They said that
> > > since sometimes you don't know where to start when contributing to a
> > > large and unfamiliar project, and since some of them or only novice
> > > python programmers, it would very good for them to have Jiras marked
> > > with a special label, such as 'entry-level', to signal that these
> > > Jiras are suitable for beginners.
> > >
> > > So first, I would like to hear your opinions on this suggestion, and
> > > second, if you support it, maybe you have some better input on the
> > > name
> > of
> > > such a label, as I'm not sure I'm pleased with 'entry-level'. (Some
> > > other suggestions were 'first-time-contributor' and 'trivial', but
> > > feel free to suggest your own)
> > >
> > > --
> > > Avia Efrat
> > > SW Engineer
> > > a...@gigaspaces.com | +972546204553 <+972%2054-620-4553> Cloudify |
> > > http://getcloudify.org <
> > > http://getcloudify.org?utm_source=signaturesatori_
> > medium=email_campaign=general_signature
> > > >
> > >
> > > <https://twitter.com/CloudifySource>
> > > <https://www.linkedin.com/groups/8467478>
> > > <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-
> cosmo
> > >
> > > [image: Azure Webinar]
> > > <
> > > http://getcloudify.org/webinars/Azure-plugin-for-
> > cloudify-webinar.html?utm_source=signaturesatori_
> > medium=email_campaign=general_signature
> > > >
> > >
> >
>

Re: Congrats on the First Release!

[Ran Ziv]

Done:
https://issues.apache.org/jira/browse/ARIA-306 ( with sub-tasks
https://issues.apache.org/jira/browse/ARIA-307 and
https://issues.apache.org/jira/browse/ARIA-308 )
https://issues.apache.org/jira/browse/ARIA-309


On Mon, Jul 10, 2017 at 3:54 PM, John D. Ament <johndam...@apache.org>
wrote:

> Ran,
>
> Do you want to create JIRAs for these?
>
> John
>
> On Mon, Jul 10, 2017 at 8:13 AM Ran Ziv <r...@gigaspaces.com> wrote:
>
> > Thanks :)
> >
> > 1) Documenting the release process - I have it on my list and will get it
> > on our Confluence soon. I also wrote some scripts to ease this process,
> > we'll probably merge them onto the repo one way or another soon.
> > 2) The sdist comes with generated HTML pages; We should probably have
> these
> > on our website as well.
> > 3) One already exists on our confluence - here:
> > https://cwiki.apache.org/confluence/display/ARIATOSCA/
> Contributing+to+ARIA
> > and here:
> > https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+Code
> > 4) Making things easily discoverable - IMO that's mostly website work,
> need
> > to make sure the website links everywhere needed including our Confluence
> > etc..
> > 5) Downloads page - yup, more website work :)
> >
> >
> > Thanks for the tips, I hope we'll be able to follow up on those shortly.
> >
> >
> >
> > On Mon, Jul 10, 2017 at 1:04 AM, Suneel Marthi <suneel.mar...@gmail.com>
> > wrote:
> >
> > > Same here, congrats Team on first release.
> > >
> > > On Sun, Jul 9, 2017 at 5:20 PM, John D. Ament <johndam...@apache.org>
> > > wrote:
> > >
> > > > All,
> > > >
> > > > I wanted to express my well wishes to you all on a successful first
> > > > release.  Most podlings see this as a milestone, I'll be updating the
> > > > various tracking sheets shortly with this note.
> > > >
> > > > So what's next?  Once the mechanics of a release are squared away,
> > > projects
> > > > figure out ways to grow the community.  Here's a short list of things
> > I'd
> > > > recommend:
> > > >
> > > > - Make sure the release process is documented and that the next
> release
> > > has
> > > > a different release manager.
> > > > - Start putting together developer centric documentation.  This may
> > > include
> > > > some high level architecture, written designs.
> > > > - Put together a contributor's guide.  This may explain how the
> project
> > > > works (via github pull requests), creating JIRA tickets, browsing
> > > fisheye,
> > > > testing locally.
> > > > - Make all of this easily discoverable.  We have a lot of these
> > > documents,
> > > > but they may be hard to find.
> > > > - Make sure we have a downloads page that points to the source
> release
> > > (ASF
> > > > requirement).
> > > >
> > > > John
> > > >
> > >
> >
>

Installation issue in 0.1.0 release

[Ran Ziv]

I've found the following issue with the 0.1.0 release:
https://issues.apache.org/jira/browse/ARIA-304

A fix for this has already been merged into master; PR can be seen here:
https://github.com/apache/incubator-ariatosca/pull/178



I'm proposing the possibility of creating a quick 0.1.1 release for fixing
this bug.
On one hand it's not necessarily in the main path (requires optional
dependency installation, not relevant for Windows) and has a simple
workaround (see comment on the JIRA issue); On the other hand, it's a
pretty annoying bug that could deter users from using the 0.1.0, and the
fix is simple.


If we're to release a 0.1.1 package, there are a few other bug fixes that
have been merged since the original 0.1.0 proposal, that we could have as a
part of this release as well:
https://issues.apache.org/jira/browse/ARIA-296
https://issues.apache.org/jira/browse/ARIA-202
https://issues.apache.org/jira/browse/ARIA-298
https://issues.apache.org/jira/browse/ARIA-287


What do you think?

Ran

Re: Congrats on the First Release!

[Ran Ziv]

Thanks :)

1) Documenting the release process - I have it on my list and will get it
on our Confluence soon. I also wrote some scripts to ease this process,
we'll probably merge them onto the repo one way or another soon.
2) The sdist comes with generated HTML pages; We should probably have these
on our website as well.
3) One already exists on our confluence - here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+to+ARIA
and here:
https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+Code
4) Making things easily discoverable - IMO that's mostly website work, need
to make sure the website links everywhere needed including our Confluence
etc..
5) Downloads page - yup, more website work :)


Thanks for the tips, I hope we'll be able to follow up on those shortly.



On Mon, Jul 10, 2017 at 1:04 AM, Suneel Marthi 
wrote:

> Same here, congrats Team on first release.
>
> On Sun, Jul 9, 2017 at 5:20 PM, John D. Ament 
> wrote:
>
> > All,
> >
> > I wanted to express my well wishes to you all on a successful first
> > release.  Most podlings see this as a milestone, I'll be updating the
> > various tracking sheets shortly with this note.
> >
> > So what's next?  Once the mechanics of a release are squared away,
> projects
> > figure out ways to grow the community.  Here's a short list of things I'd
> > recommend:
> >
> > - Make sure the release process is documented and that the next release
> has
> > a different release manager.
> > - Start putting together developer centric documentation.  This may
> include
> > some high level architecture, written designs.
> > - Put together a contributor's guide.  This may explain how the project
> > works (via github pull requests), creating JIRA tickets, browsing
> fisheye,
> > testing locally.
> > - Make all of this easily discoverable.  We have a lot of these
> documents,
> > but they may be hard to find.
> > - Make sure we have a downloads page that points to the source release
> (ASF
> > requirement).
> >
> > John
> >
>

Re: [VOTE] Add an 'entry-level' label to some of our Jira issues

[Ran Ziv]

I'm all for it, though I don't really like "entry-level" for the name of
the label :)
Any other suggestions?


On Mon, Jul 10, 2017 at 5:09 AM, John D. Ament 
wrote:

> I think it's a good idea.  Lots of other projects do something similar.  We
> could link to a query with this from the proposed contributing guide I
> emailed about earlier.  If we put the contributing guide on confluence, I
> believe we can even embed a report.
>
> John
>
> On Sun, Jul 9, 2017 at 9:34 PM Avia Efrat  wrote:
>
> > Today Tal (t...@gigaspaces.com) and myself had a very long and productive
> > face-to-face session with some AT developers about ARIA. We did a quick
> > introduction to TOSCA (as some of them where already familiar with it),
> > followed by an theoretical overview and live demo of ARIA 0.1.0.
> >
> > Some of the AT guys were very interested in contributing to ARIA, and
> > raised what I think is a very good suggestion. They said that since
> > sometimes you don't know where to start when contributing to a large and
> > unfamiliar project, and since some of them or only novice python
> > programmers, it would very good for them to have Jiras marked with a
> > special label, such as 'entry-level', to signal that these Jiras are
> > suitable for beginners.
> >
> > So first, I would like to hear your opinions on this suggestion, and
> > second, if you support it, maybe you have some better input on the name
> of
> > such a label, as I'm not sure I'm pleased with 'entry-level'. (Some other
> > suggestions were 'first-time-contributor' and 'trivial', but feel free to
> > suggest your own)
> >
> > --
> > Avia Efrat
> > SW Engineer
> > a...@gigaspaces.com | +972546204553 <+972%2054-620-4553>
> > Cloudify | http://getcloudify.org
> > <
> > http://getcloudify.org?utm_source=signaturesatori_
> medium=email_campaign=general_signature
> > >
> >
> > 
> > 
> >     >
> > [image: Azure Webinar]
> > <
> > http://getcloudify.org/webinars/Azure-plugin-for-
> cloudify-webinar.html?utm_source=signaturesatori_
> medium=email_campaign=general_signature
> > >
> >
>

[RESULT][VOTE] Apache ariatosca 0.1.0 (incubating)

[Ran Ziv]

Dear IPMC Community,

I am pleased to announce that the Incubator PMC has approved the release
of Apache ariatosca 0.1.0 (incubating).

The vote has passed with:
- three binding "+1" votes, and three non-binding "+1" votes
- no "0" votes
- no "-1" votes

The votes were 
(*https://lists.apache.org/thread.html/2892955f2f0f58e7e4a7a293e70fe5c0602a9ecd3e10ac2a39f12754@%3Cgeneral.incubator.apache.org%3E
<https://lists.apache.org/thread.html/2892955f2f0f58e7e4a7a293e70fe5c0602a9ecd3e10ac2a39f12754@%3Cgeneral.incubator.apache.org%3E>*
):
- +1, John D. Ament (binding)
- +1, Suneel Marthi (binding)
- +1, Justin Mclean (binding)
- +1, Ran Ziv (non-binding)
- +1, Avia Efrat (non-binding)
- +1, Tal Liron (non-binding)

Thank you for your support!

We'll continue with the release now.

Ran,
on behalf of Apache ariatosca PPMC

Re: create_template

[Ran Ziv]

Hi DeWayne,

The error probably means that the ARIA TOSCA extension isn't properly
installed, and therefore the parser can't find a valid reader.
The error message could probably have been somewhat clearer.. Feel free to
create a JIRA issue over this (or I'll create one if you don't :)).

Note that the ARIA TOSCA extension gets installed when running "pip
install" over the apache-ariatosca project as expected - but when
installing in editable mode, a bug in setuptools causes only the main
("aria") package to get installed properly instead.
See this JIRA issue: https://issues.apache.org/jira/browse/ARIA-110 - which
also describes the workaround.
(This is also documented on our Confluence)

Finally, you can run "make install-virtual" to install inside a Python
virtualenv, and that will also take care of making the mentioned workaround
for you, resulting in a proper installation of the TOSCA extension.
( See make target here:
https://github.com/apache/incubator-ariatosca/blob/master/Makefile#L38 )


Ran


On Sat, Jul 8, 2017 at 7:10 AM, DeWayne Filppi 
wrote:

> I'm getting a validation error out of core.create_service_template, but it
> complains about there being no presenter, so I can't figure out what the
> error is (no details are dumped).  The code essentially copies the CLI
> code:
>
>
>   service_template_path = service_template_utils.get(
> service_template_path,
>
>  service_template_filename)
>   core = Core(model_storage, resource_storage, plugin_manager)
>   try:
> core.create_service_template(service_template_path,
>  os.path.dirname(service_template_path),
>  template_name)
>

Re: Missing support for type qualified name

[Ran Ziv]

Hi DJ,

Thank you for creating this pull request.
I've added you as a Contributor (role) on JIRA, so you can now be assigned
to ARIA issues. I've assigned you to ARIA-277 as well.

Regarding the PR itself, it seems to be currently failing some CI tests.
Please see these links:
https://github.com/apache/incubator-ariatosca/pull/179
https://travis-ci.org/apache/incubator-ariatosca/builds/251017348?utm_source=github_status_medium=notification
https://ci.appveyor.com/project/ApacheSoftwareFoundation/incubator-ariatosca/build/1.0.2410


Let me know if you need any help trying to debug or figure out these issues
:)

Ran

On Sun, Jun 11, 2017 at 11:36 AM, Ran Ziv <r...@gigaspaces.com> wrote:

> Thanks DJ.
>
> Note that in order for the project to be able to accept your pull request,
> you'd first have to sign up Apache's ICLA agreement.
> See more here <https://www.apache.org/dev/new-committers-guide.html>.
>
> Ran
>
> On Fri, Jun 9, 2017 at 2:04 PM, D Jayachandran <
> d.jayachand...@ericsson.com> wrote:
>
>> Hi Ran/Tal,
>>
>> Thanks for the confirmation. I have created a JIRA issue
>> https://issues.apache.org/jira/browse/ARIA-277
>> We will let you know when we fork and make a pull request for this.
>>
>> Regards,
>> DJ
>> -Original Message-
>> From: Tal Liron [mailto:t...@gigaspaces.com]
>> Sent: Thursday, June 08, 2017 11:47 PM
>> To: dev@ariatosca.incubator.apache.org
>> Subject: Re: Missing support for type qualified name
>>
>> Thanks, DJ. This was on the list of things to do but we indeed forgot to
>> create a JIRA for it...
>>
>> On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv <r...@gigaspaces.com> wrote:
>>
>> > Hi DJ,
>> >
>> > Sounds good. Feel free to create a new JIRA yourself!  And thanks for
>> > posting on the dev list before creating this issue.
>> > One small note, I'd personally think of this as a "story" rather than
>> > a "bug" - We don't yet claim to be 100% TOSCA complaint, and we're
>> > familiar with several other missing spec sections implementations at
>> the moment.
>> >
>> > Let me know if you need any help.
>> > Tal might have more to add on this (Type qualified name) as well.
>> >
>> > Thank you
>> > Ran
>> >
>> >
>> > On Wed, Jun 7, 2017 at 3:35 PM, D Jayachandran <
>> > d.jayachand...@ericsson.com>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > TOSCA Simple Yaml 1.0 profile specification supports usage of  the
>> > > following Namespace Alias
>> > >
>> > >   1.  Shorthand Name
>> > >   2.  Type Qualified Name
>> > >   3.  Type URI
>> > >
>> > > ARIA currently supports only "Shorthand Name" and "Type URI". The
>> > > support for "Type Qualified Name" is missing which is required to
>> > > adhere with the TOSCA Simple yaml 1.0 specifications. Could this be
>> > > considered as bug
>> > and a
>> > > JIRA issue opened for this ?
>> > > We would like to start our contribution with this.
>> > >
>> > >
>> > > Regards,
>> > > DJ
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Tal Liron
>> Senior Engineer
>> t...@gigaspaces.com | +1 (773) 828-9339
>> Cloudify | http://getcloudify.org
>> <http://getcloudify.org?utm_source=signaturesatori_mediu
>> m=email_campaign=general_signature>
>>
>> <https://twitter.com/CloudifySource>
>> <https://www.linkedin.com/groups/8467478>
>> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
>> [image: Azure Webinar]
>> <http://getcloudify.org/webinars/Azure-plugin-for-cloudify-
>> webinar.html?utm_source=signaturesatori_medium=
>> email_campaign=general_signature>
>>
>
>

Re: [VOTE] publish ariatosca 0.1.0 (#2)

[Ran Ziv]

With 4 binding +1, the vote passes.
I'll send this to the incubator for the official incubator general list for
the official incubator vote now.

Thanks,
Ran

On Tue, Jul 4, 2017 at 7:51 PM, Avia Efrat <a...@gigaspaces.com> wrote:

> 1) Validated signature & checksums
> 2) Validated LICENSE, NOTICE, DISCLAIMER, "incubating" in archive name
> 3) Made a clean install using "pip install ."
> 4) Ran tests using "make test"
>
> +1
>
> On Mon, Jul 3, 2017 at 3:39 PM, Suneel Marthi <smar...@apache.org> wrote:
>
> > +1 binding
> >
> > 1. Verified {sdist, bdist, source} * {sha, md5} hashes and sigs
> > 2. Built project from {source} with "pip install"
> > 3. Ran tests
> > 4. Verified -incubating in artifacts names.
> >
> >
> > On Mon, Jul 3, 2017 at 7:13 AM, John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > On Sun, Jul 2, 2017 at 9:18 AM Ran Ziv <r...@gigaspaces.com> wrote:
> > >
> > > > Okay. I didn't have anything to go by since as far as I can tell,
> other
> > > > projects don't put their PyPI package candidates on /dist/dev, but to
> > my
> > > > understanding, in the previous voting thread you've requested to have
> > it
> > > on
> > > > there as well.
> > > >
> > >
> > > Nope, the only package I care about is source.  Having the others is an
> > ace
> > > in the hole though, since it's covering the source, binary and sdist
> > > releases needed by pypi (FWIW, there was an effort to spin up an
> internal
> > > pypi service but it's stalled).  When we verify, we can verify the full
> > > package.  Now I know more about pypi dist's to be able to push back
> when
> > > other projects publish bad releases.
> > >
> > > Here's my +1 to release as is.
> > >
> > > I would recommend adding the instructions to the readme at some point,
> > this
> > > block:
> > >
> > > Instructions for installation etc. may be found in the README file
> inside
> > > the tarball.
> > > (Please note that the relevant installation instructions are for
> "source
> > > installation", not "install from PyPI")
> > >
> > >
> > > To use RAT to validate package conformance with ASF standards, please
> use
> > > the ".rat-excludes" file, for example:
> > > java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes
> > >
> > >
> > > In any case, I modified the layout as you'd requested.
> > > >
> > > > Regarding md5 and sha files, note that on PyPI only pgp signatures
> may
> > be
> > > > used. I added them regardless.
> > > >
> > > >
> > > > Thanks,
> > > > Ran
> > > >
> > > >
> > > > On Sun, Jul 2, 2017 at 4:01 PM, John D. Ament <johndam...@apache.org
> >
> > > > wrote:
> > > >
> > > > > Ran,
> > > > >
> > > > > I would recommend a different directory layout, to make it clear
> that
> > > > these
> > > > > are three different artifacts for the same release.  Most projects
> > > > create a
> > > > > version number below their project name, or just dump all of the
> > files
> > > in
> > > > > the root (makes it easier to remember to clean up afterwards).
> > > > >
> > > > > Starting from
> > > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > > > 0.1.0-incubating/
> > > > > create
> > > > > "source", "sdist" and "bdist" directories.
> > > > >
> > > > > Put the current contents of this URL in "source" and move the other
> > two
> > > > to
> > > > > the respective locations.  When sending out the vote, you only need
> > to
> > > > > include the root URL.  Or you can just dump everything directly
> into
> > > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/ .
> > > > >
> > > > > For the contents in sdist and bdist, please include the md5 and sha
> > > > files.
> > > > >
> > > > > John
> > > > >
> > > > > On Sun, Jul 2, 2017 at 8:40 AM Ran Ziv <r...@gigaspaces.com> wrote:
> > > > >
> > > > > > This is a v

Re: imperative workflows (1.1)

[Ran Ziv]

Yup. We have given some thought as to how to implement 1.1 workflows
including conditional tasks ("on_success"/"on_failure") and it maps well
into the workflow engine, but generally speaking supporting TOSCA 1.1 is
not currently a top item.

On Tue, Jul 4, 2017 at 8:12 AM, Tal Liron  wrote:

> Not exactly. We do not support TOSCA 1.1 imperative workflows and it's not
> on the roadmap. Our current plan is to provide a state-of-the-art TOSCA 1.0
> implementation, and we're not at 100% completion yet.
>
> That said, we support something we call "custom workflows". They are not
> defined directly in TOSCA, but rather in a Python function indicated by a
> TOSCA policy (of type aria.Workflow).
>
> To be honest, you can do a lot more with Python than with TOSCA, but of
> course we understand that Python is not an option for many users. And of
> course this is an optional feature.
>
> Bottom line: we do not support TOSCA 1.1 right now, but have a very
> powerful workaround.
>
> On Mon, Jul 3, 2017 at 3:01 PM, DeWayne Filppi 
> wrote:
>
> > Is there any current support for imperative workflows (ala 1.1)?  If not,
> > is it a priority roadmap item?
> >
> > --DeWayne
> >
>
>
>
> --
> Tal Liron, Senior Solutions Architect 
> --
> M: +1-312-375-8299 http://cloudify.co @cloudifysource
> 
> 
> 
> 
>

Re: [VOTE] publish ariatosca 0.1.0 (#2)

[Ran Ziv]

Thanks John.
I took a note of adding the relevant instructions to the readme. I'll make
sure it's added soon.


On Mon, Jul 3, 2017 at 2:13 PM, John D. Ament <johndam...@apache.org> wrote:

> On Sun, Jul 2, 2017 at 9:18 AM Ran Ziv <r...@gigaspaces.com> wrote:
>
> > Okay. I didn't have anything to go by since as far as I can tell, other
> > projects don't put their PyPI package candidates on /dist/dev, but to my
> > understanding, in the previous voting thread you've requested to have it
> on
> > there as well.
> >
>
> Nope, the only package I care about is source.  Having the others is an ace
> in the hole though, since it's covering the source, binary and sdist
> releases needed by pypi (FWIW, there was an effort to spin up an internal
> pypi service but it's stalled).  When we verify, we can verify the full
> package.  Now I know more about pypi dist's to be able to push back when
> other projects publish bad releases.
>
> Here's my +1 to release as is.
>
> I would recommend adding the instructions to the readme at some point, this
> block:
>
> Instructions for installation etc. may be found in the README file inside
> the tarball.
> (Please note that the relevant installation instructions are for "source
> installation", not "install from PyPI")
>
>
> To use RAT to validate package conformance with ASF standards, please use
> the ".rat-excludes" file, for example:
> java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes
>
>
> In any case, I modified the layout as you'd requested.
> >
> > Regarding md5 and sha files, note that on PyPI only pgp signatures may be
> > used. I added them regardless.
> >
> >
> > Thanks,
> > Ran
> >
> >
> > On Sun, Jul 2, 2017 at 4:01 PM, John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > Ran,
> > >
> > > I would recommend a different directory layout, to make it clear that
> > these
> > > are three different artifacts for the same release.  Most projects
> > create a
> > > version number below their project name, or just dump all of the files
> in
> > > the root (makes it easier to remember to clean up afterwards).
> > >
> > > Starting from
> > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > 0.1.0-incubating/
> > > create
> > > "source", "sdist" and "bdist" directories.
> > >
> > > Put the current contents of this URL in "source" and move the other two
> > to
> > > the respective locations.  When sending out the vote, you only need to
> > > include the root URL.  Or you can just dump everything directly into
> > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/ .
> > >
> > > For the contents in sdist and bdist, please include the md5 and sha
> > files.
> > >
> > > John
> > >
> > > On Sun, Jul 2, 2017 at 8:40 AM Ran Ziv <r...@gigaspaces.com> wrote:
> > >
> > > > This is a vote to release Apache AriaTosca (Incubating) 0.1.0.
> > > > If the vote passes, another vote for approving the release will take
> > > place
> > > > on the Apache Incubator's PMC.
> > > >
> > > >
> > > > I created a tarball candidate for the 0.1.0 release and placed it in
> > > ARIA's
> > > > /dist/dev folder:
> > > > *
> > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > 0.1.0-incubating/
> > > > <
> > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > 0.1.0-incubating/
> > > > >*
> > > > The file is signed (.asc) and its MD5 / SHA512 checksums may be found
> > in
> > > > that folder as well.
> > > >
> > > >
> > > > In addition, I've created packages for (Pythonic-)source & binary
> > > > distributions, which would be uploaded to PyPI if the release is
> > > approved.
> > > > These artifacts may be found here:
> > > > Source distribution:
> > > >
> > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/0.1.0-sdist/
> > > > Binary distribution:
> > > >
> > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/0.1.0-bdist/
> > > >
> > > >
> > > >
> > > > The list of issues Resolved for this release are simply all the
> issues
> > > that
> > > > have been resolved thus far, seeing as this would be the first
> release
> > :)
> > > > Those can be found here:
> > > > https://issues.apache.org/jira/browse/ARIA-295?filter=-1;
> > > > jql=project%3Dariatosca%20and%20status%20in%20(resolved%2C%20closed)
> > > >
> > > >
> > > > Instructions for installation etc. may be found in the README file
> > inside
> > > > the tarball.
> > > > (Please note that the relevant installation instructions are for
> > "source
> > > > installation", not "install from PyPI")
> > > >
> > > >
> > > > To use RAT to validate package conformance with ASF standards, please
> > use
> > > > the ".rat-excludes" file, for example:
> > > > java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes
> > > >
> > > >
> > > >
> > > > The vote will last 72 hours.
> > > >
> > > > Please vote:
> > > >
> > > > [ ] +1: Good to go!
> > > > [ ] 0: I don't care
> > > > [ ] -1: Don't release this because...
> > > >
> > > >
> > > > Thanks,
> > > > Ran
> > > >
> > >
> >
>

Re: Inputs to a life cycle operation

[Ran Ziv]

Hi DJ,

You're definitely correct - this issue is in fact already in a pull request
, and will
hopefully be merged soon.


Ran

On Mon, Jul 3, 2017 at 1:04 PM, D Jayachandran 
wrote:

> Hi,
>
> With the current ARIA implementation,
>
>
>   *   Only the operation level inputs, (inputs under
> "create","configure","start","stop") are passed during a workflow
> execution.
>   *   As per TOSCA spec Interface level inputs ( inputs under
> "Standard" Interface) can also be defined
>
> With the above points, don't the interface level inputs also be passed for
> any operation Task ?
> I think interface level inputs needs to be merged with operation level but
> the operation level inputs taking precedence.
> Please let us know if the above understanding is correct and could be
> fixed in ARIA ?
>
> Regards,
> DJ
>

Re: [VOTE] publish ariatosca 0.1.0 (#2)

[Ran Ziv]

Okay. I didn't have anything to go by since as far as I can tell, other
projects don't put their PyPI package candidates on /dist/dev, but to my
understanding, in the previous voting thread you've requested to have it on
there as well.
In any case, I modified the layout as you'd requested.

Regarding md5 and sha files, note that on PyPI only pgp signatures may be
used. I added them regardless.


Thanks,
Ran


On Sun, Jul 2, 2017 at 4:01 PM, John D. Ament <johndam...@apache.org> wrote:

> Ran,
>
> I would recommend a different directory layout, to make it clear that these
> are three different artifacts for the same release.  Most projects create a
> version number below their project name, or just dump all of the files in
> the root (makes it easier to remember to clean up afterwards).
>
> Starting from
> https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> 0.1.0-incubating/
> create
> "source", "sdist" and "bdist" directories.
>
> Put the current contents of this URL in "source" and move the other two to
> the respective locations.  When sending out the vote, you only need to
> include the root URL.  Or you can just dump everything directly into
> https://dist.apache.org/repos/dist/dev/incubator/ariatosca/ .
>
> For the contents in sdist and bdist, please include the md5 and sha files.
>
> John
>
> On Sun, Jul 2, 2017 at 8:40 AM Ran Ziv <r...@gigaspaces.com> wrote:
>
> > This is a vote to release Apache AriaTosca (Incubating) 0.1.0.
> > If the vote passes, another vote for approving the release will take
> place
> > on the Apache Incubator's PMC.
> >
> >
> > I created a tarball candidate for the 0.1.0 release and placed it in
> ARIA's
> > /dist/dev folder:
> > *
> > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> 0.1.0-incubating/
> > <
> > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> 0.1.0-incubating/
> > >*
> > The file is signed (.asc) and its MD5 / SHA512 checksums may be found in
> > that folder as well.
> >
> >
> > In addition, I've created packages for (Pythonic-)source & binary
> > distributions, which would be uploaded to PyPI if the release is
> approved.
> > These artifacts may be found here:
> > Source distribution:
> > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/0.1.0-sdist/
> > Binary distribution:
> > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/0.1.0-bdist/
> >
> >
> >
> > The list of issues Resolved for this release are simply all the issues
> that
> > have been resolved thus far, seeing as this would be the first release :)
> > Those can be found here:
> > https://issues.apache.org/jira/browse/ARIA-295?filter=-1;
> > jql=project%3Dariatosca%20and%20status%20in%20(resolved%2C%20closed)
> >
> >
> > Instructions for installation etc. may be found in the README file inside
> > the tarball.
> > (Please note that the relevant installation instructions are for "source
> > installation", not "install from PyPI")
> >
> >
> > To use RAT to validate package conformance with ASF standards, please use
> > the ".rat-excludes" file, for example:
> > java -jar ../apache-rat-0.12/apache-rat-0.12.jar . -E .rat-excludes
> >
> >
> >
> > The vote will last 72 hours.
> >
> > Please vote:
> >
> > [ ] +1: Good to go!
> > [ ] 0: I don't care
> > [ ] -1: Don't release this because...
> >
> >
> > Thanks,
> > Ran
> >
>

Re: [VOTE] publish ariatosca 0.1.0

[Ran Ziv]

The vote is cancelled in light of a "-1" vote.
I'll fix the mentioned issues next week and raise another vote.

I could still use some clarification with regards to what constitutes a
"source distribution" for this matter.

Thanks,
Ran

On Thu, Jun 29, 2017 at 7:08 PM, Ran Ziv <r...@gigaspaces.com> wrote:

> Right, I'll need to look more into RAT before creating another RC package
> then.
>
>
> Re source release - so should it contain exactly everything that's in the
> repository? This is somewhat different from the Python concept of a source
> distribution.
> Does it mean the generated doc files can't be there (since they're not in
> the repo)?
> Should files like "MANIFEST.IN" which gets compiled when creating a
> source distribution appear in the source release?
> Do all the tests and CI-related configurations need to appear in the
> source release as well?
>
>
> If that's what's needed I can just tar the repository itself I guess.
> Setting aside the canonical distribution for a moment, would it be ok for
> the source distribution on PyPI to be of the format that I'm using
> currently rather than the one you're describing now?
>
>
>
> On Thu, Jun 29, 2017 at 7:00 PM, John D. Ament <johndam...@apache.org>
> wrote:
>
>> On Thu, Jun 29, 2017 at 11:53 AM Ran Ziv <r...@gigaspaces.com> wrote:
>>
>> > Suneel, re mentioning 72 hours - note that I simply used the recommended
>> > template for these messages from here:
>> >
>> > http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-de
>> v/200601.mbox/%3c43c1c0a0.7040...@roguewave.com%3E
>> >
>> >
>> I'll note this is an email from 10 years ago, and things have been refined
>> since then.  I plan to rewrite that guide to give better examples.  Here's
>> a more up to date example
>>
>> https://lists.apache.org/thread.html/9fd77b14753bbde462bea06
>> fc2e1c03d5cf5a89cea2fabd6751d805a@%3Cdev.ponymail.apache.org%3E
>>
>>
>>
>> >
>> >
>> > John:
>> > Are you reading this off the README? If so, you'll notice that the
>> > installation section mentions that when installing ARIA from source, the
>> > command that should be executed is actually "pip install ." when you're
>> > inside the extracted dir.
>> >
>> > Regarding your other comments:
>> >  - DISCLAIMER file - apparently it was dropped from the manifest file
>> > somehow, i'll add it back.
>> >  - Is RAT to be used for Python projects as well? I thought it was
>> > Java-specific and I'm not familiar with similar tools for Python. We've
>> > done what we can to verify every code file has the license header.
>> >
>>
>> RAT is a tool written in java that checks headers in all languages.  We
>> should have instructions on how to run it here.
>>
>>
>> >  - This is indeed the source release - There are indeed deltas between
>> this
>> > and the repo files but that's because some files are unnecessary for
>> users
>> > (e.g. docs generating files) while some aren't needed in the repo (e.g.
>> > docs generated files).
>> >
>> >
>> The source release is what's in your repo.  Source releases are for
>> everyone to consume.
>>
>>
>> >
>> >
>> > Ran
>> >
>> >
>> > On Thu, Jun 29, 2017 at 6:43 PM, John D. Ament <johndam...@apache.org>
>> > wrote:
>> >
>> > > -1.  Found the following issues:
>> > >
>> > > - BUILD instructions are INSTALL instructions, and the installation
>> > doesn't
>> > > work
>> > >
>> > > pip install apache-ariatosca
>> > >
>> > >
>> > > Collecting apache-ariatosca
>> > >   Could not find a version that satisfies the requirement
>> > apache-ariatosca
>> > > (from versions: )
>> > > No matching distribution found for apache-ariatosca
>> > >
>> > > - There is no DISCLAIMER file
>> > > - No instructions on how to run RAT
>> > > - I'm not sure this is a source release, many files don't match whats
>> in
>> > > the repo (files added/missing?)
>> > >
>> > > Other things look fine:
>> > > - contains incubating
>> > > - files contain headers
>> > >
>> > > On Thu, Jun 29, 2017 at 11:26 AM Ran Ziv <r...@gigaspaces.com> wrote:
>> > >
>> > > > I created a tarball candidate for the 0.1.0 release and placed it in
>> > > ARIA's
>> > > > /dist/dev folder:
>> > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
>> > > > The file is signed (.asc) and its MD5 / SHA512 checksums may be
>> found
>> > in
>> > > > that folder as well.
>> > > >
>> > > >
>> > > > The list of issues Resolved for this release are simply all the
>> issues
>> > > that
>> > > > have been resolved thus far, seeing as this would be the first
>> release
>> > :)
>> > > > Those can be found here:
>> > > > https://issues.apache.org/jira/browse/ARIA-295?filter=-
>> > > > 1=project%3Dariatosca%20and%20status%20in%20(resolved%
>> 2C%20closed)
>> > > >
>> > > >
>> > > > Instructions for installation etc. may be found in the README file
>> > inside
>> > > > the tarball.
>> > > >
>> > > >
>> > > > Please vote to publish this tarball on ARIA's /dist/release folder.
>> > > >
>> > > >
>> > > > Ran
>> > > >
>> > >
>> >
>>
>
>

Re: [VOTE] publish ariatosca 0.1.0

[Ran Ziv]

Right, I'll need to look more into RAT before creating another RC package
then.


Re source release - so should it contain exactly everything that's in the
repository? This is somewhat different from the Python concept of a source
distribution.
Does it mean the generated doc files can't be there (since they're not in
the repo)?
Should files like "MANIFEST.IN" which gets compiled when creating a source
distribution appear in the source release?
Do all the tests and CI-related configurations need to appear in the source
release as well?


If that's what's needed I can just tar the repository itself I guess.
Setting aside the canonical distribution for a moment, would it be ok for
the source distribution on PyPI to be of the format that I'm using
currently rather than the one you're describing now?



On Thu, Jun 29, 2017 at 7:00 PM, John D. Ament <johndam...@apache.org>
wrote:

> On Thu, Jun 29, 2017 at 11:53 AM Ran Ziv <r...@gigaspaces.com> wrote:
>
> > Suneel, re mentioning 72 hours - note that I simply used the recommended
> > template for these messages from here:
> >
> > http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-
> dev/200601.mbox/%3c43c1c0a0.7040...@roguewave.com%3E
> >
> >
> I'll note this is an email from 10 years ago, and things have been refined
> since then.  I plan to rewrite that guide to give better examples.  Here's
> a more up to date example
>
> https://lists.apache.org/thread.html/9fd77b14753bbde462bea06fc2e1c0
> 3d5cf5a89cea2fabd6751d805a@%3Cdev.ponymail.apache.org%3E
>
>
>
> >
> >
> > John:
> > Are you reading this off the README? If so, you'll notice that the
> > installation section mentions that when installing ARIA from source, the
> > command that should be executed is actually "pip install ." when you're
> > inside the extracted dir.
> >
> > Regarding your other comments:
> >  - DISCLAIMER file - apparently it was dropped from the manifest file
> > somehow, i'll add it back.
> >  - Is RAT to be used for Python projects as well? I thought it was
> > Java-specific and I'm not familiar with similar tools for Python. We've
> > done what we can to verify every code file has the license header.
> >
>
> RAT is a tool written in java that checks headers in all languages.  We
> should have instructions on how to run it here.
>
>
> >  - This is indeed the source release - There are indeed deltas between
> this
> > and the repo files but that's because some files are unnecessary for
> users
> > (e.g. docs generating files) while some aren't needed in the repo (e.g.
> > docs generated files).
> >
> >
> The source release is what's in your repo.  Source releases are for
> everyone to consume.
>
>
> >
> >
> > Ran
> >
> >
> > On Thu, Jun 29, 2017 at 6:43 PM, John D. Ament <johndam...@apache.org>
> > wrote:
> >
> > > -1.  Found the following issues:
> > >
> > > - BUILD instructions are INSTALL instructions, and the installation
> > doesn't
> > > work
> > >
> > > pip install apache-ariatosca
> > >
> > >
> > > Collecting apache-ariatosca
> > >   Could not find a version that satisfies the requirement
> > apache-ariatosca
> > > (from versions: )
> > > No matching distribution found for apache-ariatosca
> > >
> > > - There is no DISCLAIMER file
> > > - No instructions on how to run RAT
> > > - I'm not sure this is a source release, many files don't match whats
> in
> > > the repo (files added/missing?)
> > >
> > > Other things look fine:
> > > - contains incubating
> > > - files contain headers
> > >
> > > On Thu, Jun 29, 2017 at 11:26 AM Ran Ziv <r...@gigaspaces.com> wrote:
> > >
> > > > I created a tarball candidate for the 0.1.0 release and placed it in
> > > ARIA's
> > > > /dist/dev folder:
> > > > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > > > The file is signed (.asc) and its MD5 / SHA512 checksums may be found
> > in
> > > > that folder as well.
> > > >
> > > >
> > > > The list of issues Resolved for this release are simply all the
> issues
> > > that
> > > > have been resolved thus far, seeing as this would be the first
> release
> > :)
> > > > Those can be found here:
> > > > https://issues.apache.org/jira/browse/ARIA-295?filter=-
> > > > 1=project%3Dariatosca%20and%20status%20in%20(
> resolved%2C%20closed)
> > > >
> > > >
> > > > Instructions for installation etc. may be found in the README file
> > inside
> > > > the tarball.
> > > >
> > > >
> > > > Please vote to publish this tarball on ARIA's /dist/release folder.
> > > >
> > > >
> > > > Ran
> > > >
> > >
> >
>

Re: [VOTE] publish ariatosca 0.1.0

[Ran Ziv]

Suneel, re mentioning 72 hours - note that I simply used the recommended
template for these messages from here:
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200601.mbox/%3c43c1c0a0.7040...@roguewave.com%3E



John:
Are you reading this off the README? If so, you'll notice that the
installation section mentions that when installing ARIA from source, the
command that should be executed is actually "pip install ." when you're
inside the extracted dir.

Regarding your other comments:
 - DISCLAIMER file - apparently it was dropped from the manifest file
somehow, i'll add it back.
 - Is RAT to be used for Python projects as well? I thought it was
Java-specific and I'm not familiar with similar tools for Python. We've
done what we can to verify every code file has the license header.
 - This is indeed the source release - There are indeed deltas between this
and the repo files but that's because some files are unnecessary for users
(e.g. docs generating files) while some aren't needed in the repo (e.g.
docs generated files).



Ran


On Thu, Jun 29, 2017 at 6:43 PM, John D. Ament <johndam...@apache.org>
wrote:

> -1.  Found the following issues:
>
> - BUILD instructions are INSTALL instructions, and the installation doesn't
> work
>
> pip install apache-ariatosca
>
>
> Collecting apache-ariatosca
>   Could not find a version that satisfies the requirement apache-ariatosca
> (from versions: )
> No matching distribution found for apache-ariatosca
>
> - There is no DISCLAIMER file
> - No instructions on how to run RAT
> - I'm not sure this is a source release, many files don't match whats in
> the repo (files added/missing?)
>
> Other things look fine:
> - contains incubating
> - files contain headers
>
> On Thu, Jun 29, 2017 at 11:26 AM Ran Ziv <r...@gigaspaces.com> wrote:
>
> > I created a tarball candidate for the 0.1.0 release and placed it in
> ARIA's
> > /dist/dev folder:
> > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > The file is signed (.asc) and its MD5 / SHA512 checksums may be found in
> > that folder as well.
> >
> >
> > The list of issues Resolved for this release are simply all the issues
> that
> > have been resolved thus far, seeing as this would be the first release :)
> > Those can be found here:
> > https://issues.apache.org/jira/browse/ARIA-295?filter=-
> > 1=project%3Dariatosca%20and%20status%20in%20(resolved%2C%20closed)
> >
> >
> > Instructions for installation etc. may be found in the README file inside
> > the tarball.
> >
> >
> > Please vote to publish this tarball on ARIA's /dist/release folder.
> >
> >
> > Ran
> >
>

Re: [VOTE] publish ariatosca 0.1.0

[Ran Ziv]

Yes, I'm aware of this, sorry if I've mis-phrased the purpose of the vote.
Thanks for clearing this up.

On Thu, Jun 29, 2017 at 6:37 PM, John D. Ament <johndam...@apache.org>
wrote:

> Ran,
>
> Just to be clear, per incubator voting policies this is the dev vote.
> There's a second vote that happens on general@incubator before actually
> moving it to /dist/release
>
> John
>
> On Thu, Jun 29, 2017 at 11:26 AM Ran Ziv <r...@gigaspaces.com> wrote:
>
> > I created a tarball candidate for the 0.1.0 release and placed it in
> ARIA's
> > /dist/dev folder:
> > https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
> > The file is signed (.asc) and its MD5 / SHA512 checksums may be found in
> > that folder as well.
> >
> >
> > The list of issues Resolved for this release are simply all the issues
> that
> > have been resolved thus far, seeing as this would be the first release :)
> > Those can be found here:
> > https://issues.apache.org/jira/browse/ARIA-295?filter=-
> > 1=project%3Dariatosca%20and%20status%20in%20(resolved%2C%20closed)
> >
> >
> > Instructions for installation etc. may be found in the README file inside
> > the tarball.
> >
> >
> > Please vote to publish this tarball on ARIA's /dist/release folder.
> >
> >
> > Ran
> >
>

[VOTE] publish ariatosca 0.1.0

[Ran Ziv]

I created a tarball candidate for the 0.1.0 release and placed it in ARIA's
/dist/dev folder:
https://dist.apache.org/repos/dist/dev/incubator/ariatosca/
The file is signed (.asc) and its MD5 / SHA512 checksums may be found in
that folder as well.


The list of issues Resolved for this release are simply all the issues that
have been resolved thus far, seeing as this would be the first release :)
Those can be found here:
https://issues.apache.org/jira/browse/ARIA-295?filter=-
1=project%3Dariatosca%20and%20status%20in%20(resolved%2C%20closed)


Instructions for installation etc. may be found in the README file inside
the tarball.


Please vote to publish this tarball on ARIA's /dist/release folder.


Ran

Re: Website Improvements

[Ran Ziv]

(1) + (2) - Arthur will update those on the website.
(3) - The pip links will become valid as soon as we make a release as we'll
have it on there as well.
(4) - Oh that's indeed much better, I wasn't familiar with it. Thanks! I'll
update the readme accordingly.

Ran

On Mon, Jun 26, 2017 at 5:19 PM, John D. Ament 
wrote:

> All,
>
> Just wanted to throw out some website improvements I think you should
> consider.
>
> - There's no way to find the Aria Tosca source code on the website and
> there should be.
> - Even if we don't have any downloads available yet, we should create a
> placeholder page for downloads.
> - The current getting started guide points to pip, which we know is gone
> now.
> - The mail archives, while the current link is valid, I would recommend
> linking to https://lists.apache.org/list.html?ariatosca.apache.org as the
> landing page for our mailing lists.
>
> John
>

Re: aria install from source error

[Ran Ziv]

Oh, I think this is due to a bug that made source installation not have any
requirements during installation under done circumstances. Its since been
fixed.

Six etc. Shouldn't be a problem since they are dependencies of ARIA, and
should get installed automatically.


On Jun 22, 2017 18:39, "DeWayne Filppi" <dewa...@gigaspaces.com> wrote:

> Regarding six etc...   I installed them based on specific errors I saw.
>
> On Thu, Jun 22, 2017 at 2:43 AM, Ran Ziv <r...@gigaspaces.com> wrote:
>
> > I've updated the instructions on the readme. It now also separates ARIA
> > installation from ARIA[ssh] installation, so the basic ARIA package
> > shouldn't actually require any system dependencies anymore, only an
> updated
> > `pip` and `setuptools`.
> >
> >
> > DeWayne, did you run into issues when not manually installing `six`,
> > `packaging`, `appdirs`? I've tried it on Centos 7 and it worked fine
> > without installing these manually.
> > I assume that you simply meant you installed these and things worked, but
> > not necessarily that things wouldn't have worked otherwise. If I'm wrong
> > please let me know so we could update the instructions again.
> >
> >
> > Thanks,
> > Ran
> >
> > On Tue, Jun 20, 2017 at 7:35 PM, DeWayne Filppi <dewa...@gigaspaces.com>
> > wrote:
> >
> > > This worked for me.  Assume repo already cloned:
> > >
> > > OS: CentOS Linux release 7.3.1611 (Core)
> > >
> > > wget http://bootstrap.pypa.io/get-pip.py
> > > sudo python get-pip.py
> > > sudo yum install -y python-virtualenv
> > > virtualenv venv
> > > . venv/bin/activate
> > > sudo yum install -y libffi-devel
> > > sudo yum install -y openssl-devel
> > > sudo yum install -y gcc
> > >
> > > pip install setuptools -U
> > > pip install six
> > > pip install packaging
> > > pip install appdirs
> > >
> > > cd incubator-ariatosca
> > > pip install .
> > >
> > >
> > > On Sat, Jun 17, 2017 at 10:59 AM, Tal Liron <t...@gigaspaces.com>
> wrote:
> > >
> > > > DeWayne, can you detail all the steps you needed from scratch and on
> > > which
> > > > OS?
> > > >
> > > > On Fri, Jun 16, 2017 at 7:21 PM, DeWayne Filppi <
> > dewa...@gigaspaces.com>
> > > > wrote:
> > > >
> > > > > Ran,
> > > > >
> > > > > FYI, that worked, in addition to a ton of other modules I had to
> add.
> > > > The
> > > > > other modules were easy to identity, unlike setuptools.  Thanks.
> > > > >
> > > > > DeWayne
> > > > >
> > > > > On Fri, Jun 16, 2017 at 2:34 PM, Ran Ziv <r...@gigaspaces.com>
> wrote:
> > > > >
> > > > > > Hi DeWayne,
> > > > > >
> > > > > > The readme doesn't specify anything about a centos installation
> by
> > > the
> > > > > way
> > > > > > - there should definitely be some system dependencies that might
> be
> > > > > > required, so if you run into those please let us know so we'll
> > update
> > > > the
> > > > > > readme accordingly.
> > > > > >
> > > > > > Your specific error, however, is caused by an old version of
> > > > setuptools.
> > > > > > please run this:
> > > > > >
> > > > > > pip install -U setuptools
> > > > > >
> > > > > > (possibly upgrading pip itself beforehand)
> > > > > > and then try again.
> > > > > >
> > > > > >
> > > > > > Re attempting to install aria from pypi, it's not on there yet,
> so
> > > that
> > > > > > wouldn't work right now. The readme is ahead of its time in that
> > > > regard.
> > > > > >
> > > > > >
> > > > > > Ran
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 16, 2017 at 11:08 PM, DeWayne Filppi <
> > > > dewa...@gigaspaces.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > When installing Aria per instructions on centos 7 from source
> > (e.g.
> > > > pip
> > > > > > > install .), I get :
> > > > > > >
> > 

Re: Website ready for builds?

[Ran Ziv]

Great, thanks!

On Jun 22, 2017 19:10, "John D. Ament"  wrote:

> Ok, the website is up.  http://ariatosca.incubator.apache.org/
>
> Can you please add the incubator logo + disclaimer on it?
>
> John
>
> On Thu, Jun 22, 2017 at 10:41 AM John D. Ament 
> wrote:
>
> > That should start working after infra does
> > https://issues.apache.org/jira/browse/INFRA-14420
> >
> > John
> >
> >
> > On Thu, Jun 22, 2017 at 10:39 AM Arthur Berezin 
> > wrote:
> >
> >> I'm getting 404 on http://ariatosca.incubator.apache.org/
> >> I assume that now infra team needs to redirect $URL to the site?
> >>
> >> On Thu, Jun 22, 2017 at 5:28 PM John D. Ament 
> >> wrote:
> >>
> >> > Arthur,
> >> >
> >> > I setup a build job.  Looks like we're good.
> >> >
> >> >
> >> https://builds.apache.org/view/A-D/view/AriaTosca/job/
> AriaTosca%20Website/
> >> >
> >> > I'm going to commit the script changes and open an infra ticket to
> setup
> >> > the website.
> >> >
> >> > John
> >> >
> >> > On Thu, Jun 22, 2017 at 10:07 AM Arthur Berezin <
> art...@gigaspaces.com>
> >> > wrote:
> >> >
> >> > > Yes, it shouldn't be a problem.
> >> > >
> >> > > On Thu, Jun 22, 2017 at 5:04 PM John D. Ament <
> john.d.am...@gmail.com
> >> >
> >> > > wrote:
> >> > >
> >> > > > Arthur,
> >> > > >
> >> > > > Can the domain be donated to the ASF?
> >> > > >
> >> > > > John
> >> > > >
> >> > > > On Thu, Jun 22, 2017 at 10:03 AM Arthur Berezin <
> >> art...@gigaspaces.com
> >> > >
> >> > > > wrote:
> >> > > >
> >> > > > > Once this is done, I'll redirect the existing domain
> >> > > > http://ariatosca.org/
> >> > > > > to
> >> > > > > our new ASF homepage
> >> > > > >
> >> > > > > On Thu, Jun 22, 2017 at 4:56 PM Arthur Berezin <
> >> > art...@gigaspaces.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > > > The build command for Jekyll should be:
> >> > > > > > bundle exec Jekyll build --destination $WORKDIR $WORKDIR
> >> > > > > >
> >> > > > > > I added the build script to the website repo and added the
> >> Jekyll
> >> > > > > command,
> >> > > > > > it assumes that all dependencies are already installed and
> it's
> >> a
> >> > > > little
> >> > > > > > challenge to test this
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> https://github.com/apache/incubator-ariatosca-website/
> blob/master/build_site.sh
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On Thu, Jun 22, 2017 at 3:11 PM John D. Ament <
> >> > johndam...@apache.org
> >> > > >
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > >> Arthur,
> >> > > > > >>
> >> > > > > >> Yes, exactly.  If you can get a script like that together, or
> >> tell
> >> > > me
> >> > > > > what
> >> > > > > >> the equivalent of the build would be, I can get it running
> >> into a
> >> > > > build
> >> > > > > >> chain so that we finally have ariatosca.incubator.apache.org
> >> as
> >> > our
> >> > > > > >> website.
> >> > > > > >>
> >> > > > > >> John
> >> > > > > >>
> >> > > > > >> On Thu, Jun 22, 2017 at 5:12 AM Arthur Berezin <
> >> > > art...@gigaspaces.com
> >> > > > >
> >> > > > > >> wrote:
> >> > > > > >>
> >> > > > > >> > Thanks, John, I've pushed an update to aria-tosca-website
> >> last
> >> > > week
> >> > > > > and
> >> > > > > >> I
> >> > > > > >> > have another major update coming in today.
> >> > > > > >> >
> >> > > > > >> > If I understand correctly, the example script builds a
> static
> >> > > > website
> >> > > > > >> and
> >> > > > > >> > then publishes it back to the git repo from which the
> static
> >> > HTML
> >> > > > > would
> >> > > > > >> get
> >> > > > > >> > served?
> >> > > > > >> >
> >> > > > > >> >
> >> > > > > >> >
> >> > > > > >> >
> >> > > > > >> > On Thu, Jun 22, 2017 at 5:39 AM John D. Ament <
> >> > > > johndam...@apache.org>
> >> > > > > >> > wrote:
> >> > > > > >> >
> >> > > > > >> > > All,
> >> > > > > >> > >
> >> > > > > >> > > Some feedback from today's board meeting.  Its noted that
> >> Aria
> >> > > > Tosca
> >> > > > > >> has
> >> > > > > >> > > been incubating for 10 months and still doesn't have a
> >> website
> >> > > > > hosted
> >> > > > > >> at
> >> > > > > >> > > Apache.  I know Arthur had been doing some work on the
> >> area,
> >> > but
> >> > > > > >> wanted
> >> > > > > >> > to
> >> > > > > >> > > see if the current code in the website repo was ready to
> >> go?
> >> > > > > >> > >
> >> > > > > >> > > If so, would I be able to get a script together similar
> to
> >> > > > > >> > >
> >> > > https://github.com/apache/incubator/blob/jbake-site/build_site.sh
> >> > > > > >> that
> >> > > > > >> > > does
> >> > > > > >> > > the actual site build?  Obviously replace the bake
> command
> >> > (from
> >> > > > > >> jbake)
> >> > > > > >> > > with the proper commands to get the website built.
> >> > > > > >> > >
> >> > > > > >> > > John
> >> > > > > >> > >
> >> > > > > >> >
> >> > > > > >>
> >> > > > > >
> >> > > > >
> 

Re: A few questions about creating a release

[Ran Ziv]

I haven't merged it yet, but I'll do that soon probably.

Since the package on pypi is going to be named differently than the old
package ('apache-ariatosca' vs 'aria'), removing the older version is not
as big a concern, but still preferable. Thanks Arthur.


Any clue about my first two questions? I asked this on `legal-discuss` a
couple days ago too, but so far no reply.

On Thu, Jun 22, 2017 at 5:34 PM, John D. Ament <johndam...@apache.org>
wrote:

> Keeping old versions at external repos is fine, no issue with us (but if
> they can be explained as non-ASF even better).
>
> Thanks for fixing the package name.
>
> On Thu, Jun 22, 2017 at 10:26 AM Arthur Berezin <art...@gigaspaces.com>
> wrote:
>
> > btw, as we already have outdated packages on Pypi, I've asked +Limor
> > Shemesh
> > <li...@gigaspaces.com> to remove old packages so that we only have new
> ASF
> > packages available on Pypi to avoid confusion.
> >
> >
> > On Thu, Jun 22, 2017 at 5:22 PM Arthur Berezin <art...@gigaspaces.com>
> > wrote:
> >
> > > On Tue, Jun 20, 2017 at 12:26 PM Ran Ziv <r...@gigaspaces.com> wrote:
> > >
> > >> Bumping this one more time, and also copying this to the legal mailing
> > >> list. I'm not 100% sure that's the place for it, but perhaps someone
> > there
> > >> might be able to help.
> > >>
> > >> Thanks
> > >>
> > >> On Wed, Jun 14, 2017 at 6:17 PM, Ran Ziv <r...@gigaspaces.com> wrote:
> > >>
> > >> > Bumping this as well.
> > >> >
> > >> > On Mon, Jun 5, 2017 at 5:08 PM, Ran Ziv <r...@gigaspaces.com> wrote:
> > >> >
> > >> >> Hi Suneel, John,
> > >> >>
> > >> >> I have a few quick questions about creating a release for an
> > incubator
> > >> >> project:
> > >> >>
> > >> >>
> > >> >> 1) According to these links: 1
> > >> >> <
> > >>
> > http://incubator.apache.org/guides/releasemanagement.html#
> podling-constraints
> > >> >
> > >> >>  2
> > >> >> <
> > >> http://incubator.apache.org/incubation/Incubation_Policy.
> html#Releases>
> > >> >> Incubating projects must have "Incubating" in the "final file
> name".
> > I
> > >> >> might be missing something, but I assume the meaning is the final
> > >> tarball
> > >> >> (source distribution) or wheel (binary distribution) file.
> > >> >> This is unconventional and not compatible with PyPI - and indeed it
> > >> seems
> > >> >> like other Apache Incubator projects don't adhere to it (see
> Airflow
> > >> >> <https://pypi.python.org/pypi/apache-airflow>).
> > >> >> Am I missing something, or perhaps this is simply not relevant for
> > >> Python
> > >> >> projects?
> > >> >>
> > >> >>
> > >> >> 2) According to this
> > >> >> <
> > >> http://www.apache.org/legal/release-policy.html#licensing-
> documentation
> > >,
> > >> >> LICENSE and NOTICE must be located in all release packages,
> including
> > >> >> binary distributions. I've looked much into this and I couldn't
> find
> > a
> > >> good
> > >> >> way of bundling these files inside the wheel format - except for
> > >> manually
> > >> >> pushing them inside after creating the wheel perhaps.
> > >> >> The section speaks of a "customary location for licensing
> materials"
> > -
> > >> >> However, for the wheel format there's no such "customary location".
> > >> >> I tried looking into what other Apache projects do about this, and
> > >> indeed
> > >> >> the libcloud project doesn't have these files in their wheel
> package
> > >> (also,
> > >> >> relating to my other mail with licensing questions - they also seem
> > to
> > >> be
> > >> >> using PyLint).
> > >> >> Is this acceptable for  ARIA as well, or should we manually place
> > these
> > >> >> files inside the wheel package - Or perhaps there's a different way
> > to
> > >> do
> > >> >> this I have not found?
> > >> >>
> > >> >>
> > >> >> 3) What should be the project name on PyPI (when it goes up there)?
> > >> Does
> > >> >> it have to be named "apache-ariatosca"? Can it be simply named
> > "aria"?
> > >> >> It can often get confusing when projects are named one thing on
> PyPI
> > >> and
> > >> >> yet the main package is named otherwise; Plus, it's simply more
> > >> >> straightforward to do "pip install aria" :)
> > >> >> I haven't seen any explicit rules about this, but I assumed it's
> > better
> > >> >> to ask.
> > >>
> > >
> > > My understanding is that "Apahce" should be included as part of the
> > > package name, and since the name of the project is AriaTosca we should
> > > stick to the project name so "apache-ariatosca" should work.
> > > wrt to cli "aria" would be much better ux, but we can also add an alias
> > > from "aria" to "ariatosca" for consistency.
> > >
> > >
> > >
> > >> >>
> > >> >>
> > >> >> Thanks
> > >> >>
> > >> >>
> > >> >
> > >>
> > >
> >
>

Re: aria install from source error

[Ran Ziv]

I've updated the instructions on the readme. It now also separates ARIA
installation from ARIA[ssh] installation, so the basic ARIA package
shouldn't actually require any system dependencies anymore, only an updated
`pip` and `setuptools`.


DeWayne, did you run into issues when not manually installing `six`,
`packaging`, `appdirs`? I've tried it on Centos 7 and it worked fine
without installing these manually.
I assume that you simply meant you installed these and things worked, but
not necessarily that things wouldn't have worked otherwise. If I'm wrong
please let me know so we could update the instructions again.


Thanks,
Ran

On Tue, Jun 20, 2017 at 7:35 PM, DeWayne Filppi <dewa...@gigaspaces.com>
wrote:

> This worked for me.  Assume repo already cloned:
>
> OS: CentOS Linux release 7.3.1611 (Core)
>
> wget http://bootstrap.pypa.io/get-pip.py
> sudo python get-pip.py
> sudo yum install -y python-virtualenv
> virtualenv venv
> . venv/bin/activate
> sudo yum install -y libffi-devel
> sudo yum install -y openssl-devel
> sudo yum install -y gcc
>
> pip install setuptools -U
> pip install six
> pip install packaging
> pip install appdirs
>
> cd incubator-ariatosca
> pip install .
>
>
> On Sat, Jun 17, 2017 at 10:59 AM, Tal Liron <t...@gigaspaces.com> wrote:
>
> > DeWayne, can you detail all the steps you needed from scratch and on
> which
> > OS?
> >
> > On Fri, Jun 16, 2017 at 7:21 PM, DeWayne Filppi <dewa...@gigaspaces.com>
> > wrote:
> >
> > > Ran,
> > >
> > > FYI, that worked, in addition to a ton of other modules I had to add.
> > The
> > > other modules were easy to identity, unlike setuptools.  Thanks.
> > >
> > > DeWayne
> > >
> > > On Fri, Jun 16, 2017 at 2:34 PM, Ran Ziv <r...@gigaspaces.com> wrote:
> > >
> > > > Hi DeWayne,
> > > >
> > > > The readme doesn't specify anything about a centos installation by
> the
> > > way
> > > > - there should definitely be some system dependencies that might be
> > > > required, so if you run into those please let us know so we'll update
> > the
> > > > readme accordingly.
> > > >
> > > > Your specific error, however, is caused by an old version of
> > setuptools.
> > > > please run this:
> > > >
> > > > pip install -U setuptools
> > > >
> > > > (possibly upgrading pip itself beforehand)
> > > > and then try again.
> > > >
> > > >
> > > > Re attempting to install aria from pypi, it's not on there yet, so
> that
> > > > wouldn't work right now. The readme is ahead of its time in that
> > regard.
> > > >
> > > >
> > > > Ran
> > > >
> > > >
> > > > On Fri, Jun 16, 2017 at 11:08 PM, DeWayne Filppi <
> > dewa...@gigaspaces.com
> > > >
> > > > wrote:
> > > >
> > > > > When installing Aria per instructions on centos 7 from source (e.g.
> > pip
> > > > > install .), I get :
> > > > >
> > > > > Unpacking /home/vagrant/incubator-ariatosca
> > > > >   Running setup.py egg_info for package from file:///home/vagrant/
> > > > > incubator-ariatosca
> > > > > Traceback (most recent call last):
> > > > >   File "", line 16, in 
> > > > >   File "/tmp/pip-bnCofl-build/setup.py", line 134, in 
> > > > > packages=find_packages(include=['aria*']) +
> > > > > TypeError: find_packages() got an unexpected keyword argument
> > > > 'include'
> > > > > Complete output from command python setup.py egg_info:
> > > > > Traceback (most recent call last):
> > > > >
> > > > >   File "", line 16, in 
> > > > >
> > > > >   File "/tmp/pip-bnCofl-build/setup.py", line 134, in 
> > > > >
> > > > > packages=find_packages(include=['aria*']) +
> > > > >
> > > > > TypeError: find_packages() got an unexpected keyword argument
> > 'include'
> > > > >
> > > > > Is this familiar?
> > > > >
> > > > > Also note that I installed pip via bootstrap.pypa and running "pip
> > > > install
> > > > > aria" yields a "not found" error.
> > > > >
> > > > > DeWayne
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > DeWayne Filppi, Director, Solutions Architect <http://cloudify.co>
> > > --
> > > M: +17145121706 http://cloudify.co @dfilppi
> > > <https://twitter.com/CloudifySource>
> > > <https://www.linkedin.com/company-beta/17918192/>
> > > <https://github.com/cloudify-cosmo>
> > > <https://www.youtube.com/cloudifysource>
> > >
> >
> >
> >
> > --
> > Tal Liron, Senior Solutions Architect <http://cloudify.co>
> > --
> > M: +1-312-375-8299 http://cloudify.co @cloudifysource
> > <https://twitter.com/CloudifySource>
> > <https://www.linkedin.com/company-beta/17918192/>
> > <https://github.com/cloudify-cosmo>
> > <https://www.youtube.com/cloudifysource>
> >
>
>
>
> --
> DeWayne Filppi, Director, Solutions Architect <http://cloudify.co>
> --
> M: +17145121706 http://cloudify.co @dfilppi
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/company-beta/17918192/>
> <https://github.com/cloudify-cosmo>
> <https://www.youtube.com/cloudifysource>
>

Re: aria install from source error

[Ran Ziv]

Thanks DeWayne, glad it worked.

I've played around with installing ARIA on various distros (linux only
though) today, and I'll be updating the README with more complete/specific
instructions to make sure we avoid such issues in the future.

Ran

On Sat, Jun 17, 2017 at 8:59 PM, Tal Liron <t...@gigaspaces.com> wrote:

> DeWayne, can you detail all the steps you needed from scratch and on which
> OS?
>
> On Fri, Jun 16, 2017 at 7:21 PM, DeWayne Filppi <dewa...@gigaspaces.com>
> wrote:
>
> > Ran,
> >
> > FYI, that worked, in addition to a ton of other modules I had to add.
> The
> > other modules were easy to identity, unlike setuptools.  Thanks.
> >
> > DeWayne
> >
> > On Fri, Jun 16, 2017 at 2:34 PM, Ran Ziv <r...@gigaspaces.com> wrote:
> >
> > > Hi DeWayne,
> > >
> > > The readme doesn't specify anything about a centos installation by the
> > way
> > > - there should definitely be some system dependencies that might be
> > > required, so if you run into those please let us know so we'll update
> the
> > > readme accordingly.
> > >
> > > Your specific error, however, is caused by an old version of
> setuptools.
> > > please run this:
> > >
> > > pip install -U setuptools
> > >
> > > (possibly upgrading pip itself beforehand)
> > > and then try again.
> > >
> > >
> > > Re attempting to install aria from pypi, it's not on there yet, so that
> > > wouldn't work right now. The readme is ahead of its time in that
> regard.
> > >
> > >
> > > Ran
> > >
> > >
> > > On Fri, Jun 16, 2017 at 11:08 PM, DeWayne Filppi <
> dewa...@gigaspaces.com
> > >
> > > wrote:
> > >
> > > > When installing Aria per instructions on centos 7 from source (e.g.
> pip
> > > > install .), I get :
> > > >
> > > > Unpacking /home/vagrant/incubator-ariatosca
> > > >   Running setup.py egg_info for package from file:///home/vagrant/
> > > > incubator-ariatosca
> > > > Traceback (most recent call last):
> > > >   File "", line 16, in 
> > > >   File "/tmp/pip-bnCofl-build/setup.py", line 134, in 
> > > > packages=find_packages(include=['aria*']) +
> > > > TypeError: find_packages() got an unexpected keyword argument
> > > 'include'
> > > > Complete output from command python setup.py egg_info:
> > > > Traceback (most recent call last):
> > > >
> > > >   File "", line 16, in 
> > > >
> > > >   File "/tmp/pip-bnCofl-build/setup.py", line 134, in 
> > > >
> > > > packages=find_packages(include=['aria*']) +
> > > >
> > > > TypeError: find_packages() got an unexpected keyword argument
> 'include'
> > > >
> > > > Is this familiar?
> > > >
> > > > Also note that I installed pip via bootstrap.pypa and running "pip
> > > install
> > > > aria" yields a "not found" error.
> > > >
> > > > DeWayne
> > > >
> > >
> >
> >
> >
> > --
> > DeWayne Filppi, Director, Solutions Architect <http://cloudify.co>
> > --
> > M: +17145121706 http://cloudify.co @dfilppi
> > <https://twitter.com/CloudifySource>
> > <https://www.linkedin.com/company-beta/17918192/>
> > <https://github.com/cloudify-cosmo>
> > <https://www.youtube.com/cloudifysource>
> >
>
>
>
> --
> Tal Liron, Senior Solutions Architect <http://cloudify.co>
> --
> M: +1-312-375-8299 http://cloudify.co @cloudifysource
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/company-beta/17918192/>
> <https://github.com/cloudify-cosmo>
> <https://www.youtube.com/cloudifysource>
>

Re: Creating a Source Release

[Ran Ziv]

Thanks John.
Before we can follow these steps though, we'll need to find answers for
some release-related questions I asked on a separate thread. I reposted
these questions on the legal mailing list today, so hopefully we'll be
getting answers soon.

Ran

On Tue, Jun 20, 2017 at 3:46 PM, John D. Ament 
wrote:

> I worked with one of my podlings that has a release very similar to yours
> to come up with steps needed for a source release.  That information can be
> found at [1].  AriaTosca may want to adapt something very similar for their
> source bundle.
>
> John
>
> [1]: http://ponymail.incubator.apache.org/building.html
>

Re: A few questions about creating a release

[Ran Ziv]

Bumping this one more time, and also copying this to the legal mailing
list. I'm not 100% sure that's the place for it, but perhaps someone there
might be able to help.

Thanks

On Wed, Jun 14, 2017 at 6:17 PM, Ran Ziv <r...@gigaspaces.com> wrote:

> Bumping this as well.
>
> On Mon, Jun 5, 2017 at 5:08 PM, Ran Ziv <r...@gigaspaces.com> wrote:
>
>> Hi Suneel, John,
>>
>> I have a few quick questions about creating a release for an incubator
>> project:
>>
>>
>> 1) According to these links: 1
>> <http://incubator.apache.org/guides/releasemanagement.html#podling-constraints>
>>  2
>> <http://incubator.apache.org/incubation/Incubation_Policy.html#Releases>
>> Incubating projects must have "Incubating" in the "final file name". I
>> might be missing something, but I assume the meaning is the final tarball
>> (source distribution) or wheel (binary distribution) file.
>> This is unconventional and not compatible with PyPI - and indeed it seems
>> like other Apache Incubator projects don't adhere to it (see Airflow
>> <https://pypi.python.org/pypi/apache-airflow>).
>> Am I missing something, or perhaps this is simply not relevant for Python
>> projects?
>>
>>
>> 2) According to this
>> <http://www.apache.org/legal/release-policy.html#licensing-documentation>,
>> LICENSE and NOTICE must be located in all release packages, including
>> binary distributions. I've looked much into this and I couldn't find a good
>> way of bundling these files inside the wheel format - except for manually
>> pushing them inside after creating the wheel perhaps.
>> The section speaks of a "customary location for licensing materials" -
>> However, for the wheel format there's no such "customary location".
>> I tried looking into what other Apache projects do about this, and indeed
>> the libcloud project doesn't have these files in their wheel package (also,
>> relating to my other mail with licensing questions - they also seem to be
>> using PyLint).
>> Is this acceptable for  ARIA as well, or should we manually place these
>> files inside the wheel package - Or perhaps there's a different way to do
>> this I have not found?
>>
>>
>> 3) What should be the project name on PyPI (when it goes up there)? Does
>> it have to be named "apache-ariatosca"? Can it be simply named "aria"?
>> It can often get confusing when projects are named one thing on PyPI and
>> yet the main package is named otherwise; Plus, it's simply more
>> straightforward to do "pip install aria" :)
>> I haven't seen any explicit rules about this, but I assumed it's better
>> to ask.
>>
>>
>> Thanks
>>
>>
>

Re: aria install from source error

[Ran Ziv]

Hi DeWayne,

The readme doesn't specify anything about a centos installation by the way
- there should definitely be some system dependencies that might be
required, so if you run into those please let us know so we'll update the
readme accordingly.

Your specific error, however, is caused by an old version of setuptools.
please run this:

pip install -U setuptools

(possibly upgrading pip itself beforehand)
and then try again.


Re attempting to install aria from pypi, it's not on there yet, so that
wouldn't work right now. The readme is ahead of its time in that regard.


Ran


On Fri, Jun 16, 2017 at 11:08 PM, DeWayne Filppi 
wrote:

> When installing Aria per instructions on centos 7 from source (e.g. pip
> install .), I get :
>
> Unpacking /home/vagrant/incubator-ariatosca
>   Running setup.py egg_info for package from file:///home/vagrant/
> incubator-ariatosca
> Traceback (most recent call last):
>   File "", line 16, in 
>   File "/tmp/pip-bnCofl-build/setup.py", line 134, in 
> packages=find_packages(include=['aria*']) +
> TypeError: find_packages() got an unexpected keyword argument 'include'
> Complete output from command python setup.py egg_info:
> Traceback (most recent call last):
>
>   File "", line 16, in 
>
>   File "/tmp/pip-bnCofl-build/setup.py", line 134, in 
>
> packages=find_packages(include=['aria*']) +
>
> TypeError: find_packages() got an unexpected keyword argument 'include'
>
> Is this familiar?
>
> Also note that I installed pip via bootstrap.pypa and running "pip install
> aria" yields a "not found" error.
>
> DeWayne
>

Re: ARIA dependencies License issues

[Ran Ziv]

Thanks John,
I wasn't familiar with the legal mailing list. I forwarded these questions
there.

I've started another thread about 2 weeks ago ("A few questions about
creating a release") which has a few other questions of similar nature but
somewhat less legal-y - Could you perhaps answer those, or should I forward
them to the legal mailing list as well?

Thanks,
Ran

On Thu, Jun 15, 2017 at 6:24 PM, John D. Ament <johndam...@apache.org>
wrote:

> Ran,
>
> I believe the reason you're not getting a response is that this isn't the
> right list to bring it up.  I can provide some insight, but ultimately you
> need to get some legal input (from legal-discuss)
>
> - Code formatting shouldn't be an issue, since its not required for the
> execution of the code.
> - Paramiko would be an issue.  I would not include it as a dependency.
>
> John
>
> On Wed, Jun 14, 2017 at 11:17 AM Ran Ziv <r...@gigaspaces.com> wrote:
>
> > Bumping this again, still waiting for answers on these issues.
> >
> > On Sun, Jun 4, 2017 at 3:02 PM, Ran Ziv <r...@gigaspaces.com> wrote:
> >
> > > Hi,
> > >
> > > I went over all of ARIA's dependencies (including recursive
> dependencies)
> > > and validated them against the Apache allowed licenses
> > > <https://www.apache.org/legal/resolved.html#category-x>.
> > > We've done this before and found no issues, but this time two libraries
> > > came up as a possible problem. I have a few theories about how this
> might
> > > have happened, but what's more important is to understand what we can
> do
> > > about it.
> > >
> > > John, Suneel - I was hoping you might be able to answer some of the
> legal
> > > questions / suggestions I've made below. If not, please advise where I
> > > might be able to get answers for those.
> > >
> > >
> > > The first package is PyLint (GPL2.0) - This is the tool we use for
> > > validating our Python code format. This is only relevant for
> development
> > > purposes, and would not be packaged with ARIA - not even in the source
> > > distribution format.
> > > It is installed from the tests/requirements.txt file, and is used by
> tox
> > > on CIs or manually by developers.
> > > I'm not sure if this is a problem from Apache's perspective - i'd
> assume
> > > it shouldn't be, but if it is we could supposedly simply work with a
> > > different tool for this.
> > >
> > >
> > > The more serious issue is with the Paramiko package (LGPL2.1) -
> Paramiko
> > > is the native python implementation for SSH, and is widely used in
> Python
> > > ecosystem - including in Fabric, which is the library ARIA uses for
> > remote
> > > execution in the execution-plugin.
> > > I believe the main reason we haven't noticed this so far is because in
> > the
> > > past we only checked for non-recursive dependencies - and Fabric is
> > > licensed under BSD-2-clause, which is allowed by Apache.
> > >
> > > Since ARIA doesn't use Paramiko directly (but only via Fabric), this
> > might
> > > be considered ok.
> > > Otherwise, we have few other options:
> > >
> > > I'm not completely clear about what constitutes as "included packages"
> -
> > > When we will make a release, we'll distribute a source and binary
> > packages
> > > of ARIA, but no packages which actually contain any dependencies code -
> > > those will be installed separately (e.g. from PyPI).
> > >
> > > Assuming this is not enough to claim that these packages are "not
> > > included" with ARIA, we could remove Fabric (and thereby Paramiko) from
> > > ARIA's dependencies, but leave the code using them inside - This way,
> > when
> > > a user installs ARIA, they won't automatically receive any
> > > non-ASF-sanctioned dependency code, and ARIA will work but without any
> > > remote execution capabilities - and all that would be required from the
> > > user to add these capabilities is to manually install the Fabric
> library.
> > > This way, Fabric is treated like an extension or a plugin, so I'd like
> to
> > > think this is something acceptable according to Apache's legal
> > constraints.
> > >
> > > If this too is not acceptable, because ARIA will still have references
> to
> > > Fabric in the code (despite Fabric not getting installed), then perhaps
> > we
> > > could extract the referencing code as well into a separate package
> which
> > > lives outside of ASF, and users would have to install this separate
> > package
> > > to be able to use the remote execution capabilities.
> > >
> > >
> > > Finally, if none of my suggestions above pans out, I'd suggest we
> > > temporarily remove the remote execution capabilities, aim for an ARIA
> > > release with local capabilities only, and try to figure a workaround
> for
> > > the remote execution at a later date.
> > >
> > >
> > > Thanks,
> > > Ran.
> > >
> > >
> >
>

Re: A few questions about creating a release

[Ran Ziv]

Bumping this as well.

On Mon, Jun 5, 2017 at 5:08 PM, Ran Ziv <r...@gigaspaces.com> wrote:

> Hi Suneel, John,
>
> I have a few quick questions about creating a release for an incubator
> project:
>
>
> 1) According to these links: 1
> <http://incubator.apache.org/guides/releasemanagement.html#podling-constraints>
>  2
> <http://incubator.apache.org/incubation/Incubation_Policy.html#Releases>
> Incubating projects must have "Incubating" in the "final file name". I
> might be missing something, but I assume the meaning is the final tarball
> (source distribution) or wheel (binary distribution) file.
> This is unconventional and not compatible with PyPI - and indeed it seems
> like other Apache Incubator projects don't adhere to it (see Airflow
> <https://pypi.python.org/pypi/apache-airflow>).
> Am I missing something, or perhaps this is simply not relevant for Python
> projects?
>
>
> 2) According to this
> <http://www.apache.org/legal/release-policy.html#licensing-documentation>,
> LICENSE and NOTICE must be located in all release packages, including
> binary distributions. I've looked much into this and I couldn't find a good
> way of bundling these files inside the wheel format - except for manually
> pushing them inside after creating the wheel perhaps.
> The section speaks of a "customary location for licensing materials" -
> However, for the wheel format there's no such "customary location".
> I tried looking into what other Apache projects do about this, and indeed
> the libcloud project doesn't have these files in their wheel package (also,
> relating to my other mail with licensing questions - they also seem to be
> using PyLint).
> Is this acceptable for  ARIA as well, or should we manually place these
> files inside the wheel package - Or perhaps there's a different way to do
> this I have not found?
>
>
> 3) What should be the project name on PyPI (when it goes up there)? Does
> it have to be named "apache-ariatosca"? Can it be simply named "aria"?
> It can often get confusing when projects are named one thing on PyPI and
> yet the main package is named otherwise; Plus, it's simply more
> straightforward to do "pip install aria" :)
> I haven't seen any explicit rules about this, but I assumed it's better to
> ask.
>
>
> Thanks
>
>

Re: ARIA dependencies License issues

[Ran Ziv]

Bumping this again, still waiting for answers on these issues.

On Sun, Jun 4, 2017 at 3:02 PM, Ran Ziv <r...@gigaspaces.com> wrote:

> Hi,
>
> I went over all of ARIA's dependencies (including recursive dependencies)
> and validated them against the Apache allowed licenses
> <https://www.apache.org/legal/resolved.html#category-x>.
> We've done this before and found no issues, but this time two libraries
> came up as a possible problem. I have a few theories about how this might
> have happened, but what's more important is to understand what we can do
> about it.
>
> John, Suneel - I was hoping you might be able to answer some of the legal
> questions / suggestions I've made below. If not, please advise where I
> might be able to get answers for those.
>
>
> The first package is PyLint (GPL2.0) - This is the tool we use for
> validating our Python code format. This is only relevant for development
> purposes, and would not be packaged with ARIA - not even in the source
> distribution format.
> It is installed from the tests/requirements.txt file, and is used by tox
> on CIs or manually by developers.
> I'm not sure if this is a problem from Apache's perspective - i'd assume
> it shouldn't be, but if it is we could supposedly simply work with a
> different tool for this.
>
>
> The more serious issue is with the Paramiko package (LGPL2.1) - Paramiko
> is the native python implementation for SSH, and is widely used in Python
> ecosystem - including in Fabric, which is the library ARIA uses for remote
> execution in the execution-plugin.
> I believe the main reason we haven't noticed this so far is because in the
> past we only checked for non-recursive dependencies - and Fabric is
> licensed under BSD-2-clause, which is allowed by Apache.
>
> Since ARIA doesn't use Paramiko directly (but only via Fabric), this might
> be considered ok.
> Otherwise, we have few other options:
>
> I'm not completely clear about what constitutes as "included packages" -
> When we will make a release, we'll distribute a source and binary packages
> of ARIA, but no packages which actually contain any dependencies code -
> those will be installed separately (e.g. from PyPI).
>
> Assuming this is not enough to claim that these packages are "not
> included" with ARIA, we could remove Fabric (and thereby Paramiko) from
> ARIA's dependencies, but leave the code using them inside - This way, when
> a user installs ARIA, they won't automatically receive any
> non-ASF-sanctioned dependency code, and ARIA will work but without any
> remote execution capabilities - and all that would be required from the
> user to add these capabilities is to manually install the Fabric library.
> This way, Fabric is treated like an extension or a plugin, so I'd like to
> think this is something acceptable according to Apache's legal constraints.
>
> If this too is not acceptable, because ARIA will still have references to
> Fabric in the code (despite Fabric not getting installed), then perhaps we
> could extract the referencing code as well into a separate package which
> lives outside of ASF, and users would have to install this separate package
> to be able to use the remote execution capabilities.
>
>
> Finally, if none of my suggestions above pans out, I'd suggest we
> temporarily remove the remote execution capabilities, aim for an ARIA
> release with local capabilities only, and try to figure a workaround for
> the remote execution at a later date.
>
>
> Thanks,
> Ran.
>
>

Re: Let's talk about scaling (ARIA-254)

[Ran Ziv]

I think that's a very good solution. The semantics of capability being
first in precedence makes sense - basically if you'd like to scale a
compute node, do it the "TOSCA way" - Otherwise, use the policy.

I also agree that despite the quirkiness, the policy should have identical
properties/defaults as the capability does (despite the extra step required
in order to set >1 instances).
This should also mean that a user could also scale the number of instances
by setting "min_instances=X" and "max_instances>=X", yet without setting
"default_instances". The number of instances in this scenario should be X.


Have you seen the 5.4.10.3 note by the way? It talks about the number of
instances possibly being governed by a separate policy - Even though this
is still not properly defined in TOSCA, perhaps this means that the
policy's values should override the capability's if both exist? I'd rather
it didn't, as it could make things confusing, and because it's still an
ARIA-specific definition. Just thought I'd bring it up though.




On Tue, Jun 13, 2017 at 1:54 AM, Tal Liron  wrote:

> Let's talk about scaling some more. :)
>
> Earlier, I complete missed the definition of tosca.capabilities.Scalable:
>
> http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-
> YAML/v1.0/cos01/TOSCA-Simple-Profile-YAML-v1.0-cos01.html#
> DEFN_TYPE_CAPABILITIES_SCALABLE
>
> The reason I missed it is that it's actually *not* declared in
> tosca.nodes.Root, but specifically declared only for tosca.nodes.Compute
> and tosca.nodes.Container.Runtime. This seems a bit odd to me. From our
> experience, we know that it's not only VM nodes that need to be scaled, but
> in fact *any* node in the topology is a template that can have more than
> one instances (or possibly even zero in some situations). I'm honestly
> confused as to why TOSCA did it this way.
>
> So, I currently propose this: support *both* the capability and a policy.
> The mechanism works by first looking through the node templates
> capabilities to find whether it has a "scalable"-role capability. If it
> doesn't, it will see if there is a "scalable"-role policy that applies to
> it.
>
> I'll note that the "scalable"-role policy is part of the ARIA Profile, but
> even without that profile we will still support the more basic scalability
> defined in the Simple Profile. Supporting both is actually very easy in
> terms of the code, just a few lines for each once the mechanism is in
> place: the properties names and usages are the same in each.
>
> One quirk is how tosca.capabilities.Scalable defines its properties. We're
> used to thinking that max_instances defaults to infinity, and
> default_instances defaults to 1. The way the Simple Profile defines it,
> max_instances defaults to 1, and default_instances is an optional field.
> Meaning that in a sense it is up to the orchestrator to define the default
> number of instances for a node template. I recommend we switch to the way
> the Simple Profile works, for our policy as well.
>
> What this means is that if, for example, you want a node to have 5
> instances, then you need to set default_instances to 5, but *also* set
> max_instances to >=5, otherwise you will get a validation error. I
> personally think this is annoying, and prefer our way of thinking, but I
> think we should adhere to TOSCA here.
>

Re: How can I use aria CLI options correctly?

[Ran Ziv]

Yes, while the demo application doesn't download anything off the network,
the execution plugin does need "localhost" to be resolvable to "127.0.0.1",
so un-commenting that line in /etc/hosts did the trick.
Glad to hear it works :)

Please let me know if there's anything else you might need help with.
Ran

On Tue, Jun 13, 2017 at 5:55 AM, Chen, Wei D <wei.d.c...@intel.com> wrote:

> Hi Ran,
>
> It works, I just updated the '/etc/hosts' as below then it works, thanks a
> lot for all your great help!
>
> #127.0.1.1   openstack-dev.intel.com openstack-dev
> 127.0.0.1   localhost openstack-dev openstack-dev.sh.intel.com
> 127.0.1.1   openstack-dev.sh.intel.com  openstack-dev
> 10.239.159.68   openstack-dev openstack-dev.sh.intel.com
>
>
>
>
> > -Original Message-
> > From: Chen, Wei D
> > Sent: Tuesday, June 13, 2017 10:20 AM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: RE: How can I use aria CLI options correctly?
> >
> > Hi Ran,
> >
> > I am on ubuntu 14.04, 64bit, and the content of /etc/hosts is:
> > cat /etc/hosts
> > 127.0.1.1   openstack-dev.intel.com openstack-dev
> > # 127.0.0.1 localhost openstack-dev
> > # 127.0.1.1 openstack-dev.sh.intel.com  openstack-dev
> > 10.239.159.68   openstack-dev openstack-dev.sh.intel.com
> >
> > # The following lines are desirable for IPv6 capable hosts
> > ::1 localhost ip6-localhost ip6-loopback
> > ff02::1 ip6-allnodes
> > ff02::2 ip6-allrouters
> > #shldeOTCopen005 10.239.48.67
> > 10.239.48.159 ceph-dev.intel.com ceph-dev
> >
> > Will the demo application download any resource from external network?
> Since
> > I am behind the firewall so I am not sure is that matter.
> >
> >
> >
> > > -Original Message-
> > > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > > Sent: Monday, June 12, 2017 6:04 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: How can I use aria CLI options correctly?
> > >
> > > Which platform/OS/distro are you on?
> > >
> > > Could you please also post here the content of your /etc/hosts file? I
> > > think it might be related.
> > >
> > >
> > > CLI log is available under ~/.aria/cli.log the execution logs are
> > > stored in the model storage.
> > >
> > >
> > >
> > > On Mon, Jun 12, 2017 at 12:53 PM, Chen, Wei D <wei.d.c...@intel.com>
> > wrote:
> > >
> > > > Thanks for your quick reply, I saw the "connection refused" error
> > > > message after showing the logs for the execution id, Is there any
> > > > dependency from the "helloworld" that I missed?
> > > >
> > > > |  File
> > > > "/home/dave/gerrit/incubator-ariatosca/tests/resources/
> > > > service-templates/tosca-simple-1.0/env/local/lib/
> > > > python2.7/site-packages/aria/orchestrator/execution_plugin/ctx_proxy
> > > > /c
> > > > lient.py",
> > > > line 41, in _http_request
> > > > |response = opener.open(request, timeout=timeout)
> > > > |  File "/usr/lib/python2.7/urllib2.py", line 404, in open
> > > > |response = self._open(req, data)
> > > > |  File "/usr/lib/python2.7/urllib2.py", line 422, in _open
> > > > |'_open', req)
> > > > |  File "/usr/lib/python2.7/urllib2.py", line 382, in
> _call_chain
> > > > |result = func(*args)
> > > > |  File "/usr/lib/python2.7/urllib2.py", line 1214, in
> http_open
> > > > |return self.do_open(httplib.HTTPConnection, req)
> > > > |  File "/usr/lib/python2.7/urllib2.py", line 1184, in
> do_open
> > > > |raise URLError(err)
> > > > |urllib2.URLError:  > > > refused>
> > > >
> > > >
> > > > BTW, do you know where is log persisted?
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> > > > > Sent: Monday, June 12, 2017 2:08 PM
> > > > > To: dev@ariatosca.incubator.apache.org
> > > > > Subject: Re: How can I use aria CLI options correctly?
> > > > >
> > > > > In order to get a more detailed message, you could use the
> > > > > verbosity
&g

Re: How can I use aria CLI options correctly?

[Ran Ziv]

Which platform/OS/distro are you on?

Could you please also post here the content of your /etc/hosts file? I
think it might be related.


CLI log is available under ~/.aria/cli.log
the execution logs are stored in the model storage.



On Mon, Jun 12, 2017 at 12:53 PM, Chen, Wei D <wei.d.c...@intel.com> wrote:

> Thanks for your quick reply, I saw the "connection refused" error message
> after showing the logs for the execution id, Is there any dependency from
> the "helloworld" that I missed?
>
> |  File "/home/dave/gerrit/incubator-ariatosca/tests/resources/
> service-templates/tosca-simple-1.0/env/local/lib/
> python2.7/site-packages/aria/orchestrator/execution_plugin/ctx_proxy/client.py",
> line 41, in _http_request
> |response = opener.open(request, timeout=timeout)
> |  File "/usr/lib/python2.7/urllib2.py", line 404, in open
> |response = self._open(req, data)
> |  File "/usr/lib/python2.7/urllib2.py", line 422, in _open
> |'_open', req)
> |  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
> |result = func(*args)
> |  File "/usr/lib/python2.7/urllib2.py", line 1214, in http_open
> |return self.do_open(httplib.HTTPConnection, req)
> |  File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
> |raise URLError(err)
> |urllib2.URLError: 
>
>
> BTW, do you know where is log persisted?
>
>
> > -Original Message-
> > From: Maxim Orlov [mailto:ma...@gigaspaces.com]
> > Sent: Monday, June 12, 2017 2:08 PM
> > To: dev@ariatosca.incubator.apache.org
> > Subject: Re: How can I use aria CLI options correctly?
> >
> > In order to get a more detailed message, you could use the verbosity
> flag - "-v".
> > This flag is supported both for the execution start command and the logs
> list
> > command. What you would want to do at this stage is try and figure out
> what
> > happend with the execution you already ran. In order to do that, locate
> your
> > execution id via "aria executions list", and then use the list logs
> command "aria
> > logs list -e  -vvv".
> >
> > On Mon, Jun 12, 2017, 06:43 Chen, Wei D <wei.d.c...@intel.com> wrote:
> >
> > > Hi Ran,
> > >
> > > Thank you for your help! Here comes another issue when I run the
> > > "*aria services create hello-service -t hello* *aria executions start
> > > install -s hello-service*", the console shows me the below message:
> > > "
> > > Starting execution. Press Ctrl+C cancel
> > > 10:29:43 | I | Starting 'install' workflow execution
> > > 10:29:51 | I | web_app_1 Standard.configure started...
> > > 10:29:51 | I | Executing: /tmp/tmpeuRKHt-configure.sh
> > > 10:29:52 | I | Execution done (exit_code=1):
> > > /tmp/tmpeuRKHt-configure.sh
> > > 10:29:52 | E | web_app_1 Standard.configure failed
> > > 10:30:24 | I | web_app_1 Standard.configure started...
> > > 10:30:24 | I | Executing: /tmp/tmpvwDbY0-configure.sh
> > > 10:30:25 | I | Execution done (exit_code=1):
> > > /tmp/tmpvwDbY0-configure.sh
> > > 10:30:25 | E | web_app_1 Standard.configure failed"
> > >
> > > I have no idea why the configuration is failed, any way to trouble
> > > shooting the issue or where can I find more detailed error message?
> > >
> > > > -Original Message-
> > > > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > > > Sent: Friday, June 9, 2017 4:42 PM
> > > > To: dev@ariatosca.incubator.apache.org
> > > > Subject: Re: How can I use aria CLI options correctly?
> > > >
> > > > (I've replied on this same mail two days ago, so I guess there's
> > > > been
> > > some sort
> > > > of a mistake. In any case, I've copy-pasted my reply here as well.)
> > > >
> > > > Hi Dave,
> > > >
> > > > Unfortunately, the README is currently much outddated. That is why
> > > > the
> > > "aria
> > > > parse" command raises an invalid command error.
> > > >
> > > > We're working on updating the quick start guide, and hopefully it'll
> > > > be
> > > up to date
> > > > early next week, although that too isn't going to provide a full
> > > documentation at
> > > > this time to ARIA but rather only an introduction.
> > > > In the meanwhile howev

Re: How can I use aria CLI options correctly?

[Ran Ziv]

One correction to Maxim's post - there's no "-e" flag before the
 (There used to be one but it was removed since it was an
inconsistent format).

Also, it'd be helpful if you could provide us with some information about
your environment - specifically, what platform are you running on?

Ran

On Mon, Jun 12, 2017 at 9:07 AM, Maxim Orlov <ma...@gigaspaces.com> wrote:

> In order to get a more detailed message, you could use the verbosity flag -
> "-v". This flag is supported both for the execution start command and the
> logs list command. What you would want to do at this stage is try and
> figure out what happend with the execution you already ran. In order to do
> that, locate your execution id via "aria executions list", and then use the
> list logs command "aria logs list -e  -vvv".
>
> On Mon, Jun 12, 2017, 06:43 Chen, Wei D <wei.d.c...@intel.com> wrote:
>
> > Hi Ran,
> >
> > Thank you for your help! Here comes another issue when I run the "*aria
> > services create hello-service -t hello* *aria executions start install -s
> > hello-service*", the console shows me the below message:
> > "
> > Starting execution. Press Ctrl+C cancel
> > 10:29:43 | I | Starting 'install' workflow execution
> > 10:29:51 | I | web_app_1 Standard.configure started...
> > 10:29:51 | I | Executing: /tmp/tmpeuRKHt-configure.sh
> > 10:29:52 | I | Execution done (exit_code=1): /tmp/tmpeuRKHt-configure.sh
> > 10:29:52 | E | web_app_1 Standard.configure failed
> > 10:30:24 | I | web_app_1 Standard.configure started...
> > 10:30:24 | I | Executing: /tmp/tmpvwDbY0-configure.sh
> > 10:30:25 | I | Execution done (exit_code=1): /tmp/tmpvwDbY0-configure.sh
> > 10:30:25 | E | web_app_1 Standard.configure failed"
> >
> > I have no idea why the configuration is failed, any way to trouble
> > shooting the issue or where can I find more detailed error message?
> >
> > > -Original Message-
> > > From: Ran Ziv [mailto:r...@gigaspaces.com]
> > > Sent: Friday, June 9, 2017 4:42 PM
> > > To: dev@ariatosca.incubator.apache.org
> > > Subject: Re: How can I use aria CLI options correctly?
> > >
> > > (I've replied on this same mail two days ago, so I guess there's been
> > some sort
> > > of a mistake. In any case, I've copy-pasted my reply here as well.)
> > >
> > > Hi Dave,
> > >
> > > Unfortunately, the README is currently much outddated. That is why the
> > "aria
> > > parse" command raises an invalid command error.
> > >
> > > We're working on updating the quick start guide, and hopefully it'll be
> > up to date
> > > early next week, although that too isn't going to provide a full
> > documentation at
> > > this time to ARIA but rather only an introduction.
> > > In the meanwhile however, we'll be glad to help over on this mailing
> > list.
> > >
> > >
> > > The "parse" command indeed no longer exists; Similar functionality can
> > be found
> > > under "aria service-templates show", but first one has to use "aria
> > service-
> > > templates store", like so:
> > > *aria service-templates store node-cellar.yaml nodecellar* *aria
> service-
> > > templates show nodecellar -f*
> > >
> > >
> > > To actually run workflows etc., you'd have to first create a service
> for
> > a given
> > > service-template, e.g.:
> > > *aria service-templates store examples/hello-world/helloworld.yaml
> hello*
> > > *aria services create hello-service -t hello* *aria executions start
> > install -s hello-
> > > service*
> > >
> > >
> > >
> > > hope this helps.
> > >
> > > On Fri, Jun 9, 2017 at 10:34 AM, Chen, Wei D <wei.d.c...@intel.com>
> > wrote:
> > >
> > > > Dear developers,
> > > >
> > > > I am currently on ARIA, and is trying to follow the quickstack guide
> > > > from this post (https://github.com/apache/incubator-ariatosca), but
> I
> > > > am lost there since the CLI option mentioned in the guide is
> supported
> > yet.
> > > >
> > > > It said the below command can create a service instance, but seems
> > > > like "parse" is not a valid option.
> > > > - aria parse blueprints/tosca/node-cellar/node-cellar.yaml
> > > >
> > > > This is help manual I can see:
> > > > $ aria -h
> > > > Usage: aria [

Re: Missing support for type qualified name

[Ran Ziv]

Thanks DJ.

Note that in order for the project to be able to accept your pull request,
you'd first have to sign up Apache's ICLA agreement.
See more here <https://www.apache.org/dev/new-committers-guide.html>.

Ran

On Fri, Jun 9, 2017 at 2:04 PM, D Jayachandran <d.jayachand...@ericsson.com>
wrote:

> Hi Ran/Tal,
>
> Thanks for the confirmation. I have created a JIRA issue
> https://issues.apache.org/jira/browse/ARIA-277
> We will let you know when we fork and make a pull request for this.
>
> Regards,
> DJ
> -Original Message-
> From: Tal Liron [mailto:t...@gigaspaces.com]
> Sent: Thursday, June 08, 2017 11:47 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Missing support for type qualified name
>
> Thanks, DJ. This was on the list of things to do but we indeed forgot to
> create a JIRA for it...
>
> On Thu, Jun 8, 2017 at 8:24 AM, Ran Ziv <r...@gigaspaces.com> wrote:
>
> > Hi DJ,
> >
> > Sounds good. Feel free to create a new JIRA yourself!  And thanks for
> > posting on the dev list before creating this issue.
> > One small note, I'd personally think of this as a "story" rather than
> > a "bug" - We don't yet claim to be 100% TOSCA complaint, and we're
> > familiar with several other missing spec sections implementations at the
> moment.
> >
> > Let me know if you need any help.
> > Tal might have more to add on this (Type qualified name) as well.
> >
> > Thank you
> > Ran
> >
> >
> > On Wed, Jun 7, 2017 at 3:35 PM, D Jayachandran <
> > d.jayachand...@ericsson.com>
> > wrote:
> >
> > > Hi,
> > >
> > > TOSCA Simple Yaml 1.0 profile specification supports usage of  the
> > > following Namespace Alias
> > >
> > >   1.  Shorthand Name
> > >   2.  Type Qualified Name
> > >   3.  Type URI
> > >
> > > ARIA currently supports only "Shorthand Name" and "Type URI". The
> > > support for "Type Qualified Name" is missing which is required to
> > > adhere with the TOSCA Simple yaml 1.0 specifications. Could this be
> > > considered as bug
> > and a
> > > JIRA issue opened for this ?
> > > We would like to start our contribution with this.
> > >
> > >
> > > Regards,
> > > DJ
> > >
> > >
> >
>
>
>
> --
> Tal Liron
> Senior Engineer
> t...@gigaspaces.com | +1 (773) 828-9339
> Cloudify | http://getcloudify.org
> <http://getcloudify.org?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>
> <https://twitter.com/CloudifySource>
> <https://www.linkedin.com/groups/8467478>
> <https://github.com/cloudify-cosmo>   <https://github.com/cloudify-cosmo>
> [image: Azure Webinar]
> <http://getcloudify.org/webinars/Azure-plugin-for-
> cloudify-webinar.html?utm_source=signaturesatori_
> medium=email_campaign=general_signature>
>

Re: How can I use aria CLI options correctly?

[Ran Ziv]

(I've replied on this same mail two days ago, so I guess there's been some
sort of a mistake. In any case, I've copy-pasted my reply here as well.)

Hi Dave,

Unfortunately, the README is currently much outddated. That is why the
"aria parse" command raises an invalid command error.

We're working on updating the quick start guide, and hopefully it'll be up
to date early next week, although that too isn't going to provide a full
documentation at this time to ARIA but rather only an introduction.
In the meanwhile however, we'll be glad to help over on this mailing list.


The "parse" command indeed no longer exists; Similar functionality can be
found under "aria service-templates show", but first one has to use "aria
service-templates store", like so:
*aria service-templates store node-cellar.yaml nodecellar*
*aria service-templates show nodecellar -f*


To actually run workflows etc., you'd have to first create a service for a
given service-template, e.g.:
*aria service-templates store examples/hello-world/helloworld.yaml hello*
*aria services create hello-service -t hello*
*aria executions start install -s hello-service*



hope this helps.

On Fri, Jun 9, 2017 at 10:34 AM, Chen, Wei D  wrote:

> Dear developers,
>
> I am currently on ARIA, and is trying to follow the quickstack guide from
> this post (https://github.com/apache/incubator-ariatosca), but I am lost
> there since the CLI option mentioned in the guide is supported yet.
>
> It said the below command can create a service instance, but seems like
> "parse" is not a valid option.
> - aria parse blueprints/tosca/node-cellar/node-cellar.yaml
>
> This is help manual I can see:
> $ aria -h
> Usage: aria [OPTIONS] COMMAND [ARGS]...
>
> ARIA's Command Line Interface
>
> To activate bash-completion. Run: eval "$(_ARIA_COMPLETE=source aria)"
>
> ARIA's working directory resides by default in ~/.aria. To change it, set
> the environment variable ARIA_WORKDIR to something else (e.g. /tmp/).
>
> Options:
> -v, --verbose Show verbose output. You can supply this up to three times
> (i.e. -vvv)
> --version Display the version and exit
> -h, --help Show this message and exit.
>
> Commands:
> executions Handle workflow executions
> logs Show logs from workflow executions
> node-templates Handle a service template's node templates
> nodes Handle a service's nodes
> plugins Handle plugins
> reset Reset ARIA's working directory
> service-templates Handle service templates on the manager
> services Handle services
> workflows Handle service workflows
>
> There is no "parse" option list there. I have also tried the installation
> via 'pip' with version 0.1,  and this is what I can see:
> $ aria node-cellar.yaml
> Validation issues:
>   0: location: aria-1.0
>  ReaderNotFoundError: location: aria-1.0
>
>
> So, what the error here means? How can I fix it?
>
> This is how the imports defined in the "node-cellar.yaml" from the code
> base.
> imports:
>   - types/openstack.yaml
>   - types/nodejs.yaml
>   - types/mongodb.yaml
>   - types/nginx.yaml
>   - aria-1.0
>
> Thank you very much!
>
> Best Regards,
> Dave Chen
>
>
>
>
>
>
>