Please note: I am submitting this email on behalf of Michael Brenner, Cloudify, while we sort out some email problems that have blocked him from sending to the list. - /chet
Hi Steve,
Certainly we need to align (your comments 2/3). I fully agree with your comment 1. The reason for the note is to clarify that this is an issue worth being emphasized ("buyers beware"), not to support this direction. If we can address the issue (which we should try) then we would obviously remove that note.
On your comment 4) I cannot say that I agree or disagree. While I agree it is would be better to have a single consistent way to model for NFV, that is true only when such way is optimal. If a community arrives to the conclusion that a spec is sub-optimal, I think it is incumbent on the community to replace it with something better. In that sense - it is hard to cast a definitive judgment on whether it is good or bad to allow different "versions" of an NFV profile. It all depends on the context/circumstances.
- 1) The note says “other new node types that are derived from TOSCA normative types have deprecated a number of attributes”. I think it is a bad idea to deprecate inherited attributes since it goes against the TOSCA inheritance definition. When we cannot inherit the same attributes, then I believe it is best to define a new node type derived from root.
- 2) In Table 1, it currently shows tosca.nodes.Root.Compute on the second row, last column. I think it should be tosca.nodes.
Root.Compute. On the other hand, I still think deriving from root is more appropriate like the original VDU node type defined in csd03. - 3) The table 1 uses the term “Similar” while the text following the table uses the term “overlapping”. It will be great to align.
- 4) Last paragraph. I am not sure it is a good idea to allow different “versions” of a NFV profile by allowing the replacement of NFV types with YAML types. It looks like it will add complexity.
Regards,
Michael