hi
So, what is on the NIC of your VM, the private IP address?

Yes the VM in CloudStack is created on an "isolated guest" network (in this particular domain - it depends on the settings of CloudStack, but you can create new network offerings accordingly to the permissions on your account).
Than for public IP you can "acquire" any from a pool you have access to (also this based on thresholds for your account).
These IP come from a network you tipically have no control over and is the one managed by the cloud environment and is a shared network.
With these IP (that shoud come from a gateway virtual machine) you can activate firewall rules and do port forward (also NAT, but in my case this is a front end IP I use as an umbrella for multiple VMs).
For this reason I think that is appropriate to represent it as a node since it has its own lifecycle, properties etc..
The VM is create with an API specifiying the ID of the network so I'm writing in the TOSCA file the network node, but I need to specify in some way that I do not have to create it since is already there in the cloud (and tipically is done this way - you tipically find the network ready for you in the cloud is rare you have to create a new network for your service), CloudStack than commands KVM (in my case, but could be XEN or VCLOUD) to generate a VM with the NIC (eth0) linked to the internal private address.
The NIC is actually mapped to a "port" node (that for me is confusing, we could name it "foobar" since is just a convehention, there is no problem in calling it as the "port" property in the endpoint - my waring is that there will be people confused by it as I was).
Also the NIC is not created by the orschestrator since is CloudStack that does the magic.
But is there since I need to get the IP address and logically if I want the IP address I will have to issue a get_attribute on the "port" node (as specified in the port_name property of the endpoint capability - this is also a bit confusing in how I can generate the graph dependency from the endpoint to the port through a property in the capability .. but thius will go on another issue of mine).

For the network node we could add some property that enable the orchestrator to:

• create it anew
• lookup if exists conforming the properties written and reuse that one or create if missing
• not create and lookup and send error otherwise

This way we can solve the problem I explained in the last meeting with "phantom node issue"

Just to reboot this issue.
The proposed solution is based on these facts:

• in TOSCA I do not need to know the landing infrastructure just the orchestrator knows so I need to give him all the needed info
• need to specify that I need a compute node with a NIC on an internal network
• need to specify that I need a "IP node" (something new since there is nothing in the spec and is strange since this is a pretty common part but I could have missed and if so please point me in the right direction)
• need to be able to express the NAT mappings from the "IP node" and the NIC
• need to be able to express the firewall rules for the "IP node"
• need to be able to express the firewall rules for the NIC (and decide where is the proper place to place them in the NIC or in the operative system node)

@Luca - based on the description, I believe you are describing "Floating IP" (or Elastic IP as AWS calls it) in cloud environments. This is supported in OpenStack and AWS (possibly others). So this is a valid ask and we need this supported in the Simple YAML Profile. IMO, "tosca.nodes.network.Port" node_type is the appropriate place to define this as it already has the internal ip-address. See Sec 7.5.2 below,

http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd02/TOSCA-Simple-Profile-YAML-v1.0-csprd02.html#_Toc445238280

Suggest you ask Luc Boutier to put in on the queue for consideration for v1.2 of the YAML Simple Profile, then.