Open Stack

Hi,

Sorry to be joining this thread so late. In my opinion I think we should
change this so that nova-api queries quantum for the ipam information
rather than have each nova-compute node periodically querying quantum for a
host every 60 seconds as Doug mentioned.

I think this is slightly more favorable than having nova listen for RPC
notification messages about updates because nova does not need to do
anything with this information (if using quantum) except to return the info
when queried for instance information.

One thing I wanted to point out is that if using security_group_api =
quantum; when nova list is performed nova-api queries quantum for the
security groups associated with the instance. This is done in a bulk
fashion so that if one has 20 instances only a single call to quantum is
done to retrieve this information.

https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/contrib/security_groups.py#L525
https://github.com/openstack/nova/blob/master/nova/network/security_group/quantum_driver.py#L267

Since this information already includes the IP information we could
refactor the code so that this information would be returned from there.
What do you guy think?

Aaron




On Wed, Jun 5, 2013 at 9:09 AM, Doug Hellmann
<doug.hellmann at dreamhost.com>wrote:

> I agree with the idea that if quantum owns the data, it should be dropped
> from the nova v3 API.
>
> Forcing an update on get() improves things in the v2 API, but it feels
> inadequate.
>
> What about having nova listen for notifications about floating ip changes
> as a trigger to update its cache? We have some notification subscription
> code in ceilometer and in the oslo RPC library that could be reused.
>
> Doug
>
>
>
> On Tue, Jun 4, 2013 at 5:35 PM, Mike Wilson <geekinutah at gmail.com> wrote:
>
>> That does seem like a nice middle ground for the cache staleness. Since
>> this behavior is needed for quantum, does it make sense to just have the
>> API a bit more latent only for the quantum case? That is essentially what
>> you would be doing, you just get to avoid doing the work of plumbing a new
>> API call on the quantum side.
>>
>> -Mike
>>
>>
>> On Tue, Jun 4, 2013 at 1:29 PM, Vishvananda Ishaya <vishvananda at gmail.com
>> > wrote:
>>
>>>
>>> On Jun 4, 2013, at 11:48 AM, Chris Behrens <cbehrens at codestud.com>
>>> wrote:
>>>
>>>
>>> On Jun 4, 2013, at 11:11 AM, Vishvananda Ishaya <vishvananda at gmail.com>
>>> wrote:
>>>
>>>
>>> On Jun 4, 2013, at 8:38 AM, Mike Wilson <geekinutah at gmail.com> wrote:
>>>
>>> Doug,
>>>
>>> I'm glad you've brought this up. We had a similar issue to your own
>>> initially. I'm not sure our solution is the best one, but it is at least a
>>> springboard for discussion. As far as we could tell instance_nw_info is
>>> populated and cached because it is costly to generate the nw_info
>>> structure. We were seeing 5 separate calls to the quantum API to generate
>>> that structure whenever get_instance_nw_info was called. We are on Folsom,
>>> but I don't think the behavior has changed. What we ended up doing was
>>> implementing a instance_nw_info API in quantum that basically does all 5
>>> calls in a single mysql query and returns the structure that nova wants to
>>> put together. We also patched nova to always call the quantum API instead
>>> of fetching a cache from the db. This solved two problems:
>>>
>>> 1. No stale caches
>>> 2. Reduced the number of calls going to the quantum API by 80%
>>>
>>> This may not be the prettiest solution, but without it there is no way
>>> we would be able to scale quantum across a large number of nodes. Also the
>>> stale cache problem really affects usability. Maybe there is a better
>>> reason for having that sitting in the database. I'm sure people more
>>> knowledgeable than myself can chime in on this.
>>>
>>>
>>> So that would be a call to quantum on every single 'nova show'?   I find
>>> that unacceptable.  Anything that increases API latency is probably not the
>>> right answer.
>>>
>>>
>>> This seems like a reasonable approach to me, but I worry about nova list
>>> when there are a large number of instances. Perhaps a bulk get_nw_info
>>> request with a list of instance_uuids would work?
>>>
>>>
>>> I tried this before we got the info_cache in place (the single call for
>>> multiple uuids).  It was horrid… but the calls were going across RPC, not
>>> HTTP, at the time.  I still don't expect it to be much better with HTTP.
>>>
>>> What is the real problem here?  Isn't it that nova is returning data via
>>> nova-api that it probably shouldn't?  nova doesn't need to know floating
>>> IPs in order to configure an instance, right?  (obviously this must be the
>>> case, since this thread is talking about updating them via talking to
>>> quantum directly.)  If this is the case, then it doesn't seem like nova-api
>>> should expose them at all.  They are completely an implementation in
>>> quantum.  (Or maybe that's true when nova-network goes away? :)  Nova did
>>> need to configure *some* IP addresses on the instances, however, so those
>>> would be fine to expose.  Nova obviously knows about them because it
>>> potentially had to inject the config.
>>>
>>> So, my general opinion on all of this is:
>>>
>>> 1) nova-api should only return network information that it needed to
>>> know in order to configure the instance.  nova *has* to have correct data
>>> in order to configure an instance properly.
>>> 2) nova should not have to query quantum to return real time status of
>>> an instance.  If it has to do this, we're exposing the data in the wrong
>>> place.  I heard that 'images' is being removed from nova-api in v3.  Not
>>> sure if this is true or not.  But perhaps there's certain network
>>> information that should be removed from v3 if it doesn't belong there.
>>>
>>>
>>> I think this is all fine for v3, but the fact that v2 is returning stale
>>> floating ip data is bad. So we need some solution for v2 that improves
>>> this. We could provide the potentially stale data in list/detail and force
>>> an update on get. It might be a good middle ground.
>>>
>>> Vish
>>>
>>>
>>> - Chris
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> 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/20130614/d2dcae09/attachment.html>