OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

  • 1.  notes in NFV profile

    Posted 08-03-2017 15:28
    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 -- /chet  ---------------- Chet Ensign Director of Standards Development and TC Administration  OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-996-2298 Mobile: +1 201-341-1393 


  • 2.  RE: [tosca] notes in NFV profile

    Posted 08-03-2017 16:57




    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
    Sent: Thursday, August 03, 2017 8:28 AM
    To: tosca@lists.oasis-open.org
    Cc: Michael Brenner <michael@cloudify.co>
    Subject: [tosca] notes in NFV profile
     


    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



     

    --





    /chet 
    ----------------
    Chet Ensign
    Director of Standards Development and TC Administration 
    OASIS: Advancing open standards for the information society
    http://www.oasis-open.org

    Primary: +1 973-996-2298
    Mobile: +1 201-341-1393 











  • 3.  ??: [tosca] notes in NFV profile

    Posted 08-04-2017 01:21




    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
    ???? : 2017 ? 8 ? 4 ? 0:57
    ??? : Michael Brenner <michael@cloudify.co>
    ?? : tosca@lists.oasis-open.org
    ?? : RE: [tosca] notes in NFV profile


     
    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
    Sent: Thursday, August 03, 2017 8:28 AM
    To: tosca@lists.oasis-open.org
    Cc: Michael Brenner < michael@cloudify.co >
    Subject: [tosca] notes in NFV profile
     


    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



     

    --





    /chet 
    ----------------
    Chet Ensign
    Director of Standards Development and TC Administration 
    OASIS: Advancing open standards for the information society
    http://www.oasis-open.org

    Primary: +1 973-996-2298
    Mobile: +1 201-341-1393 











  • 4.  RE: [tosca] notes in NFV profile

    Posted 08-11-2017 03:18




    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]
    Sent: Thursday, August 03, 2017 6:20 PM
    To: Chris Lauwers <lauwers@ubicity.com>; Michael Brenner <michael@cloudify.co>
    Cc: tosca@lists.oasis-open.org
    Subject: ?? : [tosca] notes in NFV profile


     
    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
    ???? : 2017 ? 8 ? 4 ? 0:57
    ??? : Michael Brenner < michael@cloudify.co >
    ?? :
    tosca@lists.oasis-open.org
    ?? : RE: [tosca] notes in NFV profile


     
    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
    Sent: Thursday, August 03, 2017 8:28 AM
    To: tosca@lists.oasis-open.org
    Cc: Michael Brenner < michael@cloudify.co >
    Subject: [tosca] notes in NFV profile
     


    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



     

    --





    /chet 
    ----------------
    Chet Ensign
    Director of Standards Development and TC Administration 
    OASIS: Advancing open standards for the information society
    http://www.oasis-open.org

    Primary: +1 973-996-2298
    Mobile: +1 201-341-1393 











  • 5.  ??: [tosca] notes in NFV profile

    Posted 08-11-2017 06:33




    Hi Chirs
     
    There is no tosca.nodes.nfv.VDU defined in the NFV profile.

     
    Regards
    shitao


    ??? : Chris Lauwers [mailto:lauwers@ubicity.com]

    ???? : 2017 ? 8 ? 11 ? 11:18
    ??? : Lishitao <lishitao@huawei.com>; Michael Brenner <michael@cloudify.co>
    ?? : tosca@lists.oasis-open.org
    ?? : RE: [tosca] notes in NFV profile


     
    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 ]

    Sent: Thursday, August 03, 2017 6:20 PM
    To: Chris Lauwers < lauwers@ubicity.com >; Michael Brenner < michael@cloudify.co >
    Cc: tosca@lists.oasis-open.org
    Subject: ?? : [tosca] notes in NFV profile


     
    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
    ???? : 2017 ? 8 ? 4 ? 0:57
    ??? : Michael Brenner < michael@cloudify.co >
    ?? :
    tosca@lists.oasis-open.org
    ?? : RE: [tosca] notes in NFV profile


     
    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
    Sent: Thursday, August 03, 2017 8:28 AM
    To: tosca@lists.oasis-open.org
    Cc: Michael Brenner < michael@cloudify.co >
    Subject: [tosca] notes in NFV profile
     


    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



     

    --





    /chet 
    ----------------
    Chet Ensign
    Director of Standards Development and TC Administration 
    OASIS: Advancing open standards for the information society
    http://www.oasis-open.org

    Primary: +1 973-996-2298
    Mobile: +1 201-341-1393 











  • 6.  RE: [tosca] notes in NFV profile

    Posted 08-11-2017 06:41




    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]
    Sent: Thursday, August 10, 2017 11:32 PM
    To: Chris Lauwers <lauwers@ubicity.com>; Michael Brenner <michael@cloudify.co>
    Cc: tosca@lists.oasis-open.org
    Subject: ?? : [tosca] notes in NFV profile


     
    Hi Chirs
     
    There is no tosca.nodes.nfv.VDU defined in the NFV profile.

     
    Regards
    shitao


    ??? : Chris
    Lauwers [ mailto:lauwers@ubicity.com ]
    ???? : 2017 ? 8 ? 11 ? 11:18
    ??? : Lishitao < lishitao@huawei.com >; Michael Brenner < michael@cloudify.co >
    ?? :
    tosca@lists.oasis-open.org
    ?? : RE: [tosca] notes in NFV profile


     
    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 ]

    Sent: Thursday, August 03, 2017 6:20 PM
    To: Chris Lauwers < lauwers@ubicity.com >; Michael Brenner < michael@cloudify.co >
    Cc: tosca@lists.oasis-open.org
    Subject: ?? : [tosca] notes in NFV profile


     
    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
    ???? : 2017 ? 8 ? 4 ? 0:57
    ??? : Michael Brenner < michael@cloudify.co >
    ?? :
    tosca@lists.oasis-open.org
    ?? : RE: [tosca] notes in NFV profile


     
    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
    Sent: Thursday, August 03, 2017 8:28 AM
    To: tosca@lists.oasis-open.org
    Cc: Michael Brenner < michael@cloudify.co >
    Subject: [tosca] notes in NFV profile
     


    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



     

    --





    /chet 
    ----------------
    Chet Ensign
    Director of Standards Development and TC Administration 
    OASIS: Advancing open standards for the information society
    http://www.oasis-open.org

    Primary: +1 973-996-2298
    Mobile: +1 201-341-1393