[REF] Enhanced Pluggable Bottom Instances

[Shinobu KINJO]

Since we should realize better end users experiences, we should not bother any system administrator for top instance(s).

And one of our goals is to build completely, fully distributed OpenStack cloud system described in "Tricicle in a nutshell" [1].

Once we achieve a goal, it would be expected for end users to have tens of thousands of bottom OpenStack instances or compute nodes.

In this situation, they could not anticipate specifically what's going on on all bottom instances or compute nodes, even they would have better monitoring, and measurements systems.

Some functionalities *must* be automated completely.

Considering automations, there would be a bunch of ideas (even I've not come up with every thing so far).

One thing I've come up with:

 Pluggable bottom OpenStack instances feature.

What this feature aims to is that:

 1. Deploy bottom instance.
 2. Send *some* request to top instance from a new bottom instance.
 3. Update database on top instance to register a new bottom instance.
 4. Scan all available resources which top instance can handle.
 5. Update database on top instance to register those resources for a new bottom instance.
 6. Calculate usage of entire resources of all bottom instances.
 7. Complete registration of a new bottom instance.
 8. Display latest usage of entire OpenStack system.

What we have to consider here is:

 1.Trust relationship between top and a new bottom instances.

One of the purposes of this feature is to reduce manual operations (which are going to be pretty dangerous regarding to such a big system).

No manual operation is expected. Request from a new bottom should be sent to securely and trusted by top instance before a new bottom is registered in database by top instance.

And this traffic should not impact on other traffic as much as possible even it's not so much traffic expected.

There should be a situation where some bottom instances are broken.
For this situation, top instance should have capabilities:

 1. Notice bottom instances failure.
 2. Handle resources rebalances.
 3. Disable failed bottom instances logically.
  (maybe set flag: disable => y or 1).

Those features are not quite urgent. Because we must complete basic functionalities.

But it's worth thinking, noticing or keeping it in mind.
Any suggestion, discussion would be great!

[1] https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/edit#slide=id.p