Open Stack

Excerpts from Attila Fazekas's message of 2015-04-10 06:20:02 -0700:
> I think the Nova API (list) needs to be extended by custom attribute 
> filtering and with multiple `server` get by uuid (up to 128+).
>  
> The basic list usually does not shows what I need.
> nova processing more data than it is really needs just for a basic list.
> 
> The detailed list is very slow.
> 
> Maybe the attribute filtering or the multi item get(/POST) is not too RESTish thing,
> but it can be very efficient! 
> 

Multi-get is a good idea anyway, as it will help with workloads that
need it. However, it won't really be much better than the detail list for
things like Horizon. It will just break the problem up into a less-slow
list, and a less-slow fetch, instead of one slow list.

This is related to the discussion about how OpenStack should talk
to users. It would make a lot more sense for Horizon to poll a high
speed but not 100% consistent Atom feed that is updated by a daemon
listening to notifications, than always asking for the details from the
realtime-accurate API. I believe rackspace has something in place called
'yagi'[1] that does this for them, but I don't know what UI's they have
that use it.

Another option is for the listing API to just cache aggressively on its
backend, with users being given the option to add a request option that
means "go slow and get me up to date information." However, one must be
careful to avoid thundering herds and other problems that backend caches
tend to mask until the worst moment. For instance, if the cache starts
getting invalidated faster than users are querying it because there are
too many users asking for the slow version, then you are suddenly back
in the sinking boat without a bucket to bail water anymore.

[1] https://github.com/rackerlabs/yagi