On Fri, Apr 17, 2009 at 10:32 AM, Richard Davies <richard.davies@elastichosts.com> wrote:

You may be overestimating how much is in the database (in our case at
least!). To avoid any risk of inconsistency, we typically don't cache any
server attributes on the central management servers where these are best
mastered on the virtualization hosts themselves. That includes things like
server titles, memory sizes, etc, etc. Pretty much just the UUIDs and which
hosts they're on is permanently remembered centrally.

This is an interesting point even if it's already starting to get down to implementation details. There's little interest in a client retrieving a list of bare UUIDs, except as a precursor to iterating through them individually and requesting more information (which sounds like a source of more significant performance problems to me, expecially for remote infrastructure). Nonetheless we should try to avoid such expensive calls (e.g. querying every server)... or at least allow them to be completed in an inexpensive way.

If I were to write a client today I would probably start by asking for categories with which to build a top level tree view. Clicking on that would result in a category search (e.g. http://example.com/-/category) and I'd ask for relevant details such as running state (e.g. starting, started, stopped, etc.) which I would use to select icons etc. Bringing up a property page would result in a retrieval of all the relevant details for a single UUID.

Overall I think that giving the ability to specify which non-core extensions are queried solves most of the problem. Another optimisation might be to have extensions return "cheap" information (such as the rate, currency, etc.) while saving really expensive operations (such as totalling billing logs) for single-resource calls.

Thanks for drawing attention to this need Richard - great feedback!

Sam