[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca] tosca.nodes.Compute offering questions
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 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 > _________________________________________________________________________ > >
> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]