Open Stack

On May 20, 2013, at 11:14 AM, Aaron Rosen <arosen at nicira.com> wrote:

> Hi, 
> 
> Just to align this thread again here is what i'm thinking. In the current nova api when launching an instance it takes the following params related to networks: 
> 
>  curl -i http://10.34.104.185:8774/v2/d4e4332d5f8c4a8eab9fcb1345406cb0/servers -X POST 
> {<snip/> "networks": [{"port": "44f789ec-612d-46c5-befc-2706df3ab0d2"}]}}
> {<snip/> "networks": [{"uuid": "e6a6b169-ce03-450b-9046-0f7b08528dde"}]}}'  <-- if this is passed in nova-compute calls into quantum to create the port. 
> 
> (I believe fixed_ip is also an option but quantum doesn't use that so i'm leaving it out)
> 
> I think moving forward we should change horizon to create a port in quantum and then pass the port-id to nova-api (thus not slowing down nova-api). In order to continue supporting the current api if a request is made passing in 'networks': [{'uuid': .. we should create the port from nova-api. Doing both of these will solve the quota issue.  (Changing horizon to create the ports ahead of time will allow nova-api to not be slowed down unless someone passes in a network). 
> 
> 
> Then, moving forward in the nova v3 api we should only accept port's and not networks to the nova-api therefore requiring someone to create a port in quantum and pass that to nova.  
> 
> What do you guys think?

My gut response without giving it a tremendous amount of thought is that I like this idea.

- Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/ae8a95d9/attachment.html>