You absolutely do not need _extensions. They simply provide some optional metadata used internally by ARIA. I'm certain that this new NFV profile could be provided by a simple YAML file, included in any CSAR file that relies on it.
There are only a few specific normative data types where it is necessary: version, list, map, scalars, etc. But NFV introduces nothing like that (if it did, it would also need Python code to handle the custom data types). Perhaps one more case: if your NFV profile introduces a new kind of VDU type that *does not* inherit from tosca.nodes.Compute, then you will need to mark it with _extensions as a host role. This is so that the HOST keyword (used by get_property etc.) can correctly follow relationships and consider your custom type as a host. But, again, if you inherit from Compute it will already have this role and no _extensions are necessary. On Tue, Oct 24, 2017 at 8:04 PM, Steve Baillargeon < [email protected]> wrote: > Hi Tal > I have discussed the NFV Profile with YAML WG today and such profile will > likely be replaced to become NFV Types 1.0 to import. > I notice those custom types also have the _extensions section. > > If I need to define my own custom types, is it best if I also add the > _extensions section to them? > Maybe it is best to have all types loaded in ARIA with such _extensions > section. > Please advise > > Thanks again > > -Steve > > > -----Original Message----- > From: Tal Liron [mailto:[email protected]] > Sent: Tuesday, October 24, 2017 7:20 PM > To: [email protected] > Subject: Re: Version for Type Definitions Documents > > We are definitely going with "option A". ARIA aims to support all versions > TOSCA, not just the latest. > > The _extension section is not about version managements, but about > providing a bridge between YAML and Python code, as well as various > debugging information. Is is entirely internal to ARIA, as are all these > YAML files. > > On Tue, Oct 24, 2017 at 5:12 PM, Steve Baillargeon < > [email protected]> wrote: > > > Hi > > I currently see a YAML document called tosca-simple-1.0.yaml that > > imports the following files: > > > > > > * artifactcs.yaml > > * capabilities.yaml > > * data.yaml > > * groups.yaml > > * interfaces.yaml > > * nodes.yaml > > * policies.yaml > > * relationships.yaml > > > > Each imported file has a set of normative types and each type provides > > a reference to a YAML profile specification version. > > > > YAML Profile 1.2 introduces new types. > > YAML Profile 1.2 also makes changes to normative types while keeping > > the same type name. > > > > Option A. Is the plan to create a tosca-simple-1.2.yaml (eventually) > > that imports a completely different set of type definitions documents? > > > > Option B. Or is the plan to continue expanding on the existing > > normative type documents by mixing multiple YAML Profile versions in > > the same type definitions doc? > > > > I think I prefer option A. In addition, I think we should indicate the > > YAML specific version in the filename for each definitions document, > > say capabilities-1.0.yaml. > > I also think the all type definitions documents including the main > > document (e.g. tosca-simple-1.0.yaml) should include the > > tosca_definitions_version in the first line. > > This way we can remove the specification keyname in the _extension > > section for each type definition. > > What do you think? > > > > Regards > > Steve Baillargeon > > > > >
