OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (TOSCA-277) How to map Acquired IP form the cloud?


    [ https://issues.oasis-open.org/browse/TOSCA-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60655#comment-60655 ] 

Luca Gioppo commented on TOSCA-277:
-----------------------------------

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"

> How to map Acquired IP form the cloud?
> --------------------------------------
>
>                 Key: TOSCA-277
>                 URL: https://issues.oasis-open.org/browse/TOSCA-277
>             Project: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
>          Issue Type: Improvement
>          Components: Profile-YAML
>            Reporter: Luca Gioppo
>
> I use CloudStack Cloud environment and to expose a VM that is running in the cloud on internet I need to "acquire" a public IP address from an aviable network.
> This Address is not a new NIC of the machine but is used to port forward, on specific ports, the traffic.
> How do I map the acquired IP? is not a Port since is not a NIC.
> My idea is to use a relation between the Compute node and the Network Node.
> Obviously I need to declare the network node as "external" (see my previous issues) since the orchestrator does not have to "create" that network but just use it in the process of getting the IP.
> Another option, probably more easy to implement is to create an IP node since that will be easier to implement and than relate it to network and Compute.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]