Attributes

[Steve Baillargeon <st...@ericsson.com>]

Hi
The YAML spec is confusing about when the service or node instance actually exposes the value of an attribute.
Does ARIA always implement and expose the values of all attribute definitions (optional and mandatory) defined in normative types?

Related observation: it is very strange that the YAML spec does not support a REQUIRED keyname for the attribute definition. Then how do we go about declaring an optional vs mandatory attribute definition in custom type definitions? For now, I am almost ready to conclude that all attributes SHOULD be exposed by the TOSCA orchestrator regardless if it is required or not.

-Steve

Re: Attributes

[Tal Liron <ta...@cloudify.co>]

Why are you calling this attribute "optional"?

ARIA always exposes it, and also *should* fill in its value. This might
depend on the actual plugin doing the provisioning work... we would need to
verify this on a case by case basis. As to which value, again it depends on
the plugin.

Which IP address should it use? TOSCA doesn't say. I think everyone agrees
that networking in TOSCA is very poorly designed.

On Tue, Nov 14, 2017 at 4:41 PM, Steve Baillargeon <
steve.baillargeon@ericsson.com> wrote:

> As an example, does ARIA always expose the "optional" private_address for
> a Compute node instance?
> If so, what method is used by ARIA to select the primary OAM IP address
> when multiple IPs are associated with the Compute node instance?
>
> -Steve
>
> -----Original Message-----
> From: Tal Liron [mailto:tal@cloudify.co]
> Sent: Tuesday, November 14, 2017 5:27 PM
> To: dev@ariatosca.incubator.apache.org
> Subject: Re: Attributes
>
> ARIA exposes all defined attributes, even if they have no default value
> (in which case they will be null).
>
> Note that three attributes (tosca_id, tosca_name, state) are automatically
> filled by ARIA, if they are available. Any node type inheriting from
> tosca.nodes.Root will have them.
>
> I'm not sure what you mean by "optional" or "mandatory": there is no way
> to define attributes that way. See section 3.5.10.2 in the spec.
>
> On Tue, Nov 14, 2017 at 4:05 PM, Steve Baillargeon <
> steve.baillargeon@ericsson.com> wrote:
>
> > Hi
> > The YAML spec is confusing about when the service or node instance
> > actually exposes the value of an attribute.
> > Does ARIA always implement and expose the values of all attribute
> > definitions (optional and mandatory) defined in normative types?
> >
> > Related observation: it is very strange that the YAML spec does not
> > support a REQUIRED keyname for the attribute definition. Then how do
> > we go about declaring an optional vs mandatory attribute definition in
> > custom type definitions? For now, I am almost ready to conclude that
> > all attributes SHOULD be exposed by the TOSCA orchestrator regardless
> > if it is required or not.
> >
> > -Steve
> >
>

RE: Attributes

[Steve Baillargeon <st...@ericsson.com>]

As an example, does ARIA always expose the "optional" private_address for a Compute node instance?
If so, what method is used by ARIA to select the primary OAM IP address when multiple IPs are associated with the Compute node instance?

-Steve

-----Original Message-----
From: Tal Liron [mailto:tal@cloudify.co] 
Sent: Tuesday, November 14, 2017 5:27 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Attributes

ARIA exposes all defined attributes, even if they have no default value (in which case they will be null).

Note that three attributes (tosca_id, tosca_name, state) are automatically filled by ARIA, if they are available. Any node type inheriting from tosca.nodes.Root will have them.

I'm not sure what you mean by "optional" or "mandatory": there is no way to define attributes that way. See section 3.5.10.2 in the spec.

On Tue, Nov 14, 2017 at 4:05 PM, Steve Baillargeon < steve.baillargeon@ericsson.com> wrote:

> Hi
> The YAML spec is confusing about when the service or node instance 
> actually exposes the value of an attribute.
> Does ARIA always implement and expose the values of all attribute 
> definitions (optional and mandatory) defined in normative types?
>
> Related observation: it is very strange that the YAML spec does not 
> support a REQUIRED keyname for the attribute definition. Then how do 
> we go about declaring an optional vs mandatory attribute definition in 
> custom type definitions? For now, I am almost ready to conclude that 
> all attributes SHOULD be exposed by the TOSCA orchestrator regardless 
> if it is required or not.
>
> -Steve
>

Re: Attributes

[Tal Liron <ta...@cloudify.co>]

ARIA exposes all defined attributes, even if they have no default value (in
which case they will be null).

Note that three attributes (tosca_id, tosca_name, state) are automatically
filled by ARIA, if they are available. Any node type inheriting from
tosca.nodes.Root will have them.

I'm not sure what you mean by "optional" or "mandatory": there is no way to
define attributes that way. See section 3.5.10.2 in the spec.

On Tue, Nov 14, 2017 at 4:05 PM, Steve Baillargeon <
steve.baillargeon@ericsson.com> wrote:

> Hi
> The YAML spec is confusing about when the service or node instance
> actually exposes the value of an attribute.
> Does ARIA always implement and expose the values of all attribute
> definitions (optional and mandatory) defined in normative types?
>
> Related observation: it is very strange that the YAML spec does not
> support a REQUIRED keyname for the attribute definition. Then how do we go
> about declaring an optional vs mandatory attribute definition in custom
> type definitions? For now, I am almost ready to conclude that all
> attributes SHOULD be exposed by the TOSCA orchestrator regardless if it is
> required or not.
>
> -Steve
>