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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > > 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 <[email protected]> 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 < > [email protected]> > > > > > 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 <[email protected]> > 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 < > > > [email protected]> > > > > > > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
openstack-err.tgz
Description: GNU Zip compressed data
