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