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
>