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

[Luca Gioppo <luca.gioppo@csi.it>]

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

 >