You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ariatosca.apache.org by DeWayne Filppi <de...@cloudify.co> on 2017/09/02 16:02:21 UTC
openstack plugin
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: openstack plugin
Posted by DeWayne Filppi <de...@cloudify.co>.
Attached. Note that I include a modified version of the plugin.yaml for
openstack that Aria uses by default (in the imports dir). The change of
interest is in the aria.openstack.datatypes.Server data type.
On Wed, Sep 6, 2017 at 4:03 PM, Tal Liron <ta...@cloudify.co> wrote:
> You are allowed to add extra inputs at the node type, beyond what is
> defined in the interface type. You just can't do it at the node template.
>
> The error you get is odd. If you could share your complete work, perhaps we
> can run it and assist you. For me, at least, it's impossible to asses the
> situation without much more information.
>
> On Wed, Sep 6, 2017 at 5:54 PM, DeWayne Filppi <de...@cloudify.co>
> wrote:
>
> > I was afraid you were going to say that. I added a generic map as the
> > "server" property. This passes the parse on template load. When I
> > actually then try to use userdata, the install workflow dies in the aria
> > extension registration process, claiming : RuntimeError: Re-definition of
> > yaml-1.1 in specification_url. If I don't actually set the userdata
> input
> > parameter, everything runs fine. What's going on in extension
> registration
> > during the install workflow, that might cause this to happen?
> >
> > On Wed, Sep 6, 2017 at 3:43 PM, Ran Ziv <ra...@cloudify.co> wrote:
> >
> > > 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 <de...@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 <ra...@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 <
> dewayne@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 <ra...@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 <
> > > dewayne@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: openstack plugin
Posted by Tal Liron <ta...@cloudify.co>.
You are allowed to add extra inputs at the node type, beyond what is
defined in the interface type. You just can't do it at the node template.
The error you get is odd. If you could share your complete work, perhaps we
can run it and assist you. For me, at least, it's impossible to asses the
situation without much more information.
On Wed, Sep 6, 2017 at 5:54 PM, DeWayne Filppi <de...@cloudify.co> wrote:
> I was afraid you were going to say that. I added a generic map as the
> "server" property. This passes the parse on template load. When I
> actually then try to use userdata, the install workflow dies in the aria
> extension registration process, claiming : RuntimeError: Re-definition of
> yaml-1.1 in specification_url. If I don't actually set the userdata input
> parameter, everything runs fine. What's going on in extension registration
> during the install workflow, that might cause this to happen?
>
> On Wed, Sep 6, 2017 at 3:43 PM, Ran Ziv <ra...@cloudify.co> wrote:
>
> > 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 <de...@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 <ra...@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 <de...@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 <ra...@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 <
> > dewayne@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: openstack plugin
Posted by DeWayne Filppi <de...@cloudify.co>.
I was afraid you were going to say that. I added a generic map as the
"server" property. This passes the parse on template load. When I
actually then try to use userdata, the install workflow dies in the aria
extension registration process, claiming : RuntimeError: Re-definition of
yaml-1.1 in specification_url. If I don't actually set the userdata input
parameter, everything runs fine. What's going on in extension registration
during the install workflow, that might cause this to happen?
On Wed, Sep 6, 2017 at 3:43 PM, Ran Ziv <ra...@cloudify.co> wrote:
> 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 <de...@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 <ra...@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 <de...@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 <ra...@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 <
> dewayne@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: openstack plugin
Posted by Ran Ziv <ra...@cloudify.co>.
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 <de...@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 <ra...@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 <de...@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 <ra...@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 <de...@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: openstack plugin
Posted by DeWayne Filppi <de...@cloudify.co>.
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 <ra...@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 <de...@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 <ra...@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 <de...@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: openstack plugin
Posted by Ran Ziv <ra...@cloudify.co>.
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 <de...@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 <ra...@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 <de...@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: openstack plugin
Posted by DeWayne Filppi <de...@cloudify.co>.
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 <ra...@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 <de...@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: openstack plugin
Posted by Ran Ziv <ra...@cloudify.co>.
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 <de...@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?
>