Open Stack

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?

Thanks,

Aaron





On Mon, May 20, 2013 at 10:55 AM, Chris Behrens <cbehrens at codestud.com>wrote:

>
> On May 20, 2013, at 10:48 AM, Vishvananda Ishaya <vishvananda at gmail.com>
> wrote:
>
>
> On May 17, 2013, at 4:55 PM, Chris Behrens <cbehrens at codestud.com> wrote:
>
> In the BP you wrote: "The only downside I see of moving this logic into
> nova-api is that we would slow down the response time from nova-api to
> provision instances."
>
>
> I object to any change that's going to slow down API responses for create
> (or really for '*').  We want the API to return as quickly as possible.
>  There are things that happen in the background for this reason where
> otherwise it may be nice to receive an error via the API.  I believe that
> this is one of those cases.
>
>
> Ultimately the problem here is a user not having enough insight into
> errors that occur during the build process.  Users are supposed to be able
> to look at instance faults to figure out why something failed.  Perhaps
> faults need to be re-thought or perhaps we're just not using them enough.
>  But I completely disagree with adding queries to quantum in nova-api
> during the build request.
>
>
> Just because we do it on the 'api' side, it doesn't mean that nova has to
> wait to return to the user. This could be put into a greenthread or sent
> off to conductor/orchestrator/scheduler to handle before calling down to
> the compute node.
>
>
> Yes, this is true and I'd be fine with that as well.  It seemed like the
> original intent was to be able to provide a failure message via the API,
> however.  And that's the part I disagree with, because any implementation
> (without some sort of caching of ports, etc) will impact API response times.
>
> - Chris
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/51835f6d/attachment.html>