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

 View Only
  • 1.  tosca.nodes.Compute offering questions

    Posted 06-04-2015 10:12
    Some questions on the Compute node definition. From a model point of view the definition is logical, from the Cloud API available is less usefull.   On CloudStack for example I create a new virtual machine by sending the templateId the offeringId and the zoneId. To get those information my orchestrator has to match the generic request of CPU, Memory, disk, operating system etc with the existing offerings. Is this the way that the standard has to be used? So to create a compute resource the orchestrator must "guess" the correct combination? Is there a good practice to adopt for giving back results or is a free decision of the orchestrator implementor? I could find a combination of offering that match the node description or not in case not I should return error to end user or try to go to the nearest good offering? Maybe this problem could araise the need of some new attribute in the standard for forcing a proper behaviour?   Thanks Luca


  • 2.  RE: [tosca] tosca.nodes.Compute offering questions

    Posted 06-04-2015 22:51




    Hi Luca,
     
    You’re asking good questions. Tosca provides a mechanism to specify the CPU, memory, disk, OS, etc. requirements for various components. It does not specify how
    the orchestrator is supposed to fulfill these requirements. You can decide to pick any compute node that has at least the memory, CPU, and disk requested. If you decide to return excess resources, that decision is entirely up to you.
     
    There have been discussions about addition additional semantics to “requirements” specification (e.g. best effort semantics where you try to get as close as you
    can to the desired CPU, memory, and disk requirements) but these have not yet been added to the spec.
     
    Chris Lauwers
    Ubicity Corp.
     


    From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
    On Behalf Of Luca Gioppo
    Sent: Thursday, June 04, 2015 3:12 AM
    To: TOSCA
    Subject: [tosca] tosca.nodes.Compute offering questions


     

    Some questions on the Compute node definition.


    From a model point of view the definition is logical, from the Cloud API available is less usefull.



     


    On CloudStack for example I create a new virtual machine by sending the templateId the offeringId and the zoneId.



    To get those information my orchestrator has to match the generic request of CPU, Memory, disk, operating system etc with the existing offerings.



    Is this the way that the standard has to be used?


    So to create a compute resource the orchestrator must "guess" the correct combination?



    Is there a good practice to adopt for giving back results or is a free decision of the orchestrator implementor?



    I could find a combination of offering that match the node description or not in case not I should return error to end user or try to go to the nearest good offering?



    Maybe this problem could araise the need of some new attribute in the standard for forcing a proper behaviour?



     


    Thanks


    Luca







  • 3.  RE: [tosca] tosca.nodes.Compute offering questions

    Posted 06-08-2015 08:33
    There is also another problem I see with the attribute in the Compute element: public_address A generic VM could not have a public address or could have more. Is the attribute valid with null or array?  For the machine there are no primary and the orchestrator has no means of deciding if there is a primary IP Also I could have more than one network in the Vm so also private_address should be 1 or more how do we map this?   On ports I believe we do not need to have in the compute the port (a VM has all its ports there) but we need to understands what we are mapping here since we could want to map: 1) ports used and opened in the IPTABLES of the machine (I use linux, but win can have similar stuff here) - OR 2) ports mapped from the internal network to the public IP as port mapping   Which of the two entityes are we mapping in the ports attribute? Is not clear? I would also prefer to have a place where to keep the mapping rules (that is on CloudStack I get the firewall and also the NIC that should be the entity that stands between the networkInfo and the port)     Thanks Luca   >   _________________________________________________________________________   >      >    Il 5 giugno 2015 alle 0.51 Chris Lauwers <lauwers@ubicity.com> ha scritto:   >      >    Hi Luca,   You’re asking good questions. Tosca provides a mechanism to specify the CPU, memory, disk, OS, etc. requirements for various components. It does not specify how the orchestrator is supposed to fulfill these requirements. You can decide to pick any compute node that has at least the memory, CPU, and disk requested. If you decide to return excess resources, that decision is entirely up to you.   There have been discussions about addition additional semantics to “requirements” specification (e.g. best effort semantics where you try to get as close as you can to the desired CPU, memory, and disk requirements) but these have not yet been added to the spec.   Chris Lauwers Ubicity Corp.   From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of Luca Gioppo   >    Sent: Thursday, June 04, 2015 3:12 AM   >    To: TOSCA   >    Subject: [tosca] tosca.nodes.Compute offering questions   Some questions on the Compute node definition. From a model point of view the definition is logical, from the Cloud API available is less usefull.   On CloudStack for example I create a new virtual machine by sending the templateId the offeringId and the zoneId. To get those information my orchestrator has to match the generic request of CPU, Memory, disk, operating system etc with the existing offerings. Is this the way that the standard has to be used? So to create a compute resource the orchestrator must "guess" the correct combination? Is there a good practice to adopt for giving back results or is a free decision of the orchestrator implementor? I could find a combination of offering that match the node description or not in case not I should return error to end user or try to go to the nearest good offering? Maybe this problem could araise the need of some new attribute in the standard for forcing a proper behaviour?   Thanks Luca   >    


  • 4.  RE: [tosca] tosca.nodes.Compute offering questions

    Posted 06-09-2015 20:34




    Hi Luca,
     
    the “public_address” attribute is only there for convenience:
     

    -          
    it is an optional attribute, so Compute nodes are not required to have it

    -          
    is is defined for the common case where a Compute node is connected to only one network and exposes only one public IP address. You’re correct that
    for the more complicated cases (where Compute nodes are connected to multiple networks) the public_ip attribute may not be helpful.

     
    Chris
     


    From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
    On Behalf Of Luca Gioppo
    Sent: Monday, June 08, 2015 1:33 AM
    To: TOSCA
    Subject: RE: [tosca] tosca.nodes.Compute offering questions


     
    There is also another problem I see with the attribute in the Compute element:
    public_address
    A generic VM could not have a public address or could have more.
    Is the attribute valid with null or array?  For the machine there are no primary and the orchestrator has no means of deciding if there is a primary IP
    Also I could have more than one network in the Vm so also
    private_address should be 1 or more how do we map this?
     
    On ports I believe we do not need to have in the compute the port (a VM has all its ports there) but we need to understands what we are mapping here since we could want to map:
    1) ports used and opened in the IPTABLES of the machine (I use linux, but win can have similar stuff here) - OR
    2) ports mapped from the internal network to the public IP as port mapping
     
    Which of the two entityes are we mapping in the ports attribute? Is not clear?
    I would also prefer to have a place where to keep the mapping rules (that is on CloudStack I get the firewall and also the NIC that should be the entity that stands between the networkInfo and the port)
     
     
    Thanks
    Luca
     >  _________________________________________________________________________
     >  
     >  

    Il 5 giugno 2015 alle 0.51 Chris Lauwers < lauwers@ubicity.com > ha scritto:

     >  
     >  

    Hi Luca,
     
    You’re asking good questions. Tosca provides a mechanism to specify the CPU, memory, disk, OS, etc. requirements for various components. It does not specify how
    the orchestrator is supposed to fulfill these requirements. You can decide to pick any compute node that has at least the memory, CPU, and disk requested. If you decide to return excess resources, that decision is entirely up to you.
     
    There have been discussions about addition additional semantics to “requirements” specification (e.g. best effort semantics where you try to get as close as you
    can to the desired CPU, memory, and disk requirements) but these have not yet been added to the spec.
     
    Chris Lauwers
    Ubicity Corp.
     


    From:
    tosca@lists.oasis-open.org [ mailto:tosca@lists.oasis-open.org ]
    On Behalf Of Luca Gioppo
     >   Sent: Thursday, June 04, 2015 3:12 AM
     >   To: TOSCA
     >   Subject: [tosca] tosca.nodes.Compute offering questions


     

    Some questions on the Compute node definition.


    From a model point of view the definition is logical, from the Cloud API available is less usefull.


     


    On CloudStack for example I create a new virtual machine by sending the templateId the offeringId and the zoneId.


    To get those information my orchestrator has to match the generic request of CPU, Memory, disk, operating system etc with the existing offerings.


    Is this the way that the standard has to be used?


    So to create a compute resource the orchestrator must "guess" the correct combination?


    Is there a good practice to adopt for giving back results or is a free decision of the orchestrator implementor?


    I could find a combination of offering that match the node description or not in case not I should return error to end user or try to go to the nearest good offering?


    Maybe this problem could araise the need of some new attribute in the standard for forcing a proper behaviour?


     


    Thanks


    Luca



     >   






  • 5.  RE: [tosca] tosca.nodes.Compute offering questions

    Posted 06-10-2015 17:56
    Chris is again entirely accurate. I would
    only add that Compute allows, as attributes, a plurality of Ports and Networks
    to be associated (via PortInfo[] and NetworkInfo[]) although the mot common
    use case is for one (virtual) public one private with prehaps a mgmt. network
    as we show in the Network appendix (but the mgmt. network may not be visible
    to the application model itself).

    Kind regards,
    Matt

    STSM, Master Inventor, IBM Open Cloud
    Technologies and Standards
    Chair, Lead Editor OASIS TOSCA Simple
    Profile WG,
    Co-Chair OASIS TOSCA Interop. SC,
    Founder of DMTF Cloud Audit (CADF) Standard
    mrutkows@us.ibm.com,  mobile: 512-431-5002




    From:      
      Chris Lauwers <lauwers@ubicity.com>
    To:      
      Luca Gioppo <luca.gioppo@csi.it>,
    TOSCA <tosca@lists.oasis-open.org>
    Date:      
      06/09/2015 03:33 PM
    Subject:    
        RE: [tosca]
    tosca.nodes.Compute offering questions
    Sent by:    
        <tosca@lists.oasis-open.org>




    Hi Luca,
     
    the “public_address” attribute
    is only there for convenience:
     
    -        
     it is an optional attribute, so Compute nodes are not required to
    have it
    -        
     is is defined for the common case where a Compute node is connected
    to only one network and exposes only one public IP address. You’re correct
    that for the more complicated cases (where Compute nodes are connected
    to multiple networks) the public_ip attribute may not be helpful.
     
    Chris
     
    From: tosca@lists.oasis-open.org
    [ mailto:tosca@lists.oasis-open.org ]
    On Behalf Of Luca Gioppo
    Sent: Monday, June 08, 2015 1:33 AM
    To: TOSCA
    Subject: RE: [tosca] tosca.nodes.Compute offering questions
     
    There is also another problem I
    see with the attribute in the Compute element:
    public_address
    A generic VM could not have a public
    address or could have more.
    Is the attribute valid with null
    or array?  For the machine there are no primary and the orchestrator
    has no means of deciding if there is a primary IP
    Also I could have more than one
    network in the Vm so also
    private_address should be 1 or
    more how do we map this?
     
    On ports I believe we do not need
    to have in the compute the port (a VM has all its ports there) but we need
    to understands what we are mapping here since we could want to map:
    1) ports used and opened in the
    IPTABLES of the machine (I use linux, but win can have similar stuff here)
    - OR
    2) ports mapped from the internal
    network to the public IP as port mapping
     
    Which of the two entityes are we
    mapping in the ports attribute? Is not clear?
    I would also prefer to have a place
    where to keep the mapping rules (that is on CloudStack I get the firewall
    and also the NIC that should be the entity that stands between the networkInfo
    and the port)
     
     
    Thanks
    Luca
     >  _________________________________________________________________________
     >  
     >  
    Il 5 giugno 2015 alle 0.51 Chris
    Lauwers < lauwers@ubicity.com >
    ha scritto:
     >  
     >  
    Hi Luca,
     
    You’re asking good questions.
    Tosca provides a mechanism to specify the CPU, memory, disk, OS, etc. requirements
    for various components. It does not specify how the orchestrator is supposed
    to fulfill these requirements. You can decide to pick any compute node
    that has at least the memory, CPU, and disk requested. If you decide to
    return excess resources, that decision is entirely up to you.
     
    There have been discussions
    about addition additional semantics to “requirements” specification (e.g.
    best effort semantics where you try to get as close as you can to the desired
    CPU, memory, and disk requirements) but these have not yet been added to
    the spec.
     
    Chris Lauwers
    Ubicity Corp.
     
    From: tosca@lists.oasis-open.org
    [ mailto:tosca@lists.oasis-open.org ]
    On Behalf Of Luca Gioppo
     >   Sent:
    Thursday, June 04, 2015 3:12 AM
     >   To: TOSCA
     >   Subject:
    [tosca] tosca.nodes.Compute offering questions
     
    Some questions on the Compute node
    definition.
    From a model point of view the
    definition is logical, from the Cloud API available is less usefull.
     
    On CloudStack for example I create
    a new virtual machine by sending the templateId the offeringId and the
    zoneId.
    To get those information my orchestrator
    has to match the generic request of CPU, Memory, disk, operating system
    etc with the existing offerings.
    Is this the way that the standard
    has to be used?
    So to create a compute resource
    the orchestrator must "guess" the correct combination?
    Is there a good practice to adopt
    for giving back results or is a free decision of the orchestrator implementor?
    I could find a combination of offering
    that match the node description or not in case not I should return error
    to end user or try to go to the nearest good offering?
    Maybe this problem could araise
    the need of some new attribute in the standard for forcing a proper behaviour?
     
    Thanks
    Luca
     >