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