> Q1 > I see normative node types in the YAML spec. Here it makes sense to call > them normative node types :) > I see non-normative node types in the YAML spec. Here it makes sense to > call them normative node types :) > I also know the template author can create its own node types. Should I > call them custom node types (which are also classified as non-normative)? >
My understanding is that "normative" means anything that is part of the Simple Profile. The spec has some example service templates with special types, but they are not normative in this sense. I haven't seen the term "custom types" used very much, perhaps it would make more sense in context. For example, you might be importing various 3rd party types into your service template that are not part of the Simple Profile, but they're still not "custom" types exactly because you consider them as a standard (just not part of the Simple Profile standard). > Q2 > Can you confirm ARIA will ensure all node types including non-normative > and custom will support the Standard lifecycle interface since I see the > Standard interface defined as part of tosca.nodes.Root? > Anything inheriting from toca.nodes.Root gets the standard lifecycle interface, but even if you have a node type that doesn't inherit from Root you can still explicitly give it the standard lifecycle interface. ARIA just checks if it's there. > Q3 > Do you have any guidelines about when it is best to create a new custom > node type that is derived from root vs derived from an existing normative > node type? > Does ARIA care? > ARIA does not care, but it's important to think of future compatibility with other TOSCA systems. For example, you might feel that tosca.nodes.Compute isn't designed properly and would rather create your own mynodes.Compute that you think is much better. ARIA would be fine with that. However, if you want your service template to work with other systems, they might not know what to do with that type. The Simple Profile is intended as a standard baseline. Whether it's a good enough baseline or not ... well, that will continue to evolve. Currently in the NFV world there are arguments exactly about this topic. > Q4 > I see the normative (generic) SoftwareComponent node type that must be > hosted on a Compute node. > If a "specific SW component" must be hosted on a VDU.Compute node > instead, then I assume it is not possible to derive the specific SW > component node type from the normative SoftwareComponent node type (?) > You're right on the mark here. This is exactly why this argument is so crucial: the Simple Profile is not just a collection of arbitrary node types, but is a system of node types, capability types, and data types that were designed to work together. It's not easy at all to replace one without replacing the whole thing. My hope is that a future Simple Profile (perhaps version 2.0?) would completely overhaul the existing node types and possibly even remove them. It's far more important in my view to have a collection of standard capability types: these could then be attached to any node type and represent an exposed "socket" for a requirement "plug". It shouldn't really matter what node type you inherit from. The NFV use case is definitely exposing the limitations of Simple Profile 1.0's strict object-oriented architecture.
