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