[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] notes in NFV profile
My apologies. I was looking at the table in Section 5.2. It shows a tosca.nodes.nfv.VDU node type, which confused me. Chris From: Lishitao [mailto:lishitao@huawei.com] Hi Chirs There is no tosca.nodes.nfv.VDU defined in the NFV profile.
Regards shitao 发件人: Chris
Lauwers [mailto:lauwers@ubicity.com] Does this mean the standard will include both tosca.nodes.nfv.VDUComposition and
tosca.nodes.nfv.VDU?
Thanks, Chris From: Lishitao [mailto:lishitao@huawei.com]
Hi Chris The latest draft of tosca-nfv-profile (csd04) do support the composition based design method, it that case, it calls tosca.nodes.nfv.VDUComposition, please check section
4.3 for detailed description. Regards shitao 发件人:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
代表 Chris Lauwers Hi Michael, I agree with your comment 2) regarding VDU. Compute is clearly a resource entity, whereas a VDU (in my opinion) is not. A VDU represents a higher-level construct that gets deployed on top of resources
such as Compute and Storage. The best way to model this, in my opinion, is to make VDU its own top-level type that decomposes (using substitution mappings) into a topology that includes Compute and Storage nodes. Chris From:
tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Chet Ensign 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.
Regards, Michael --
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]