Comment 3 for bug 1160487

Get servers slowness...

Part #1: Form big 'single' query to get all instances Y

Part #2:

If detailed:
    - Iterate for each instance in Y:
      - Check policy to get fault
    - Make big 'single' query to get all instances faults (called this Z)
      - Iterate over result set Z, attach to appropriate instance in Y
    - Form detail view:
      - Call view function show() on each instance in Y to get the basic
        information about an instance (note it appears no extra calls are made
        here) and results in list X

*Now here is the iffy part*

Extensions cause iterations & alterations on/to the resultant 'view' X.

- ExtendedServerAttributesController
  - for server in servers:
- ExtendedIpsController
  - for server in servers:
- ServerDiskConfigController
  - for server in servers:
- config_drive.Controller
  - for server in servers:
- ExtendedStatusController
  - for server in servers:
- ... others?

Now if that server list is in the 1000+ the process of doing those iterations
and adjusting the views via this extension chain (and reiteration) actually takes
more time than the initial DB call to begin with. Hopefully there are ways this
can be improved (as a cloud will just get bigger and not smaller). Especially in
the 'admin' case where it is useful to view all instances these operations can
be especially slow (don't piss off the admins, haha).

Some ideas:

It would be interesting to alter the extension mechanism to provide
a central controller that can iterate over the server list once, and let
each extension locally accumulate its additions, and then at the end of
each the overall iteration the locally accumulated results can then be
attached to the response by this central controller (instead of having each
extension do this itself).

Another idea and possible future work is that extensions are limited by the initial DB query
and its cached entries via req.get_db_instance, it might instead be useful to have this central controller
form the initial 'detail/show' calls SQL query with 'input' from the extensions
that will be activated. This way extensions can guarantee that there needed
backing source query is added to the larger query and said DB query will be
exact for the extensions and root 'view' instead of being very generic (as it is
right now, since it is impossible to predict what field an extension will need from
the underlying instance).