Open Stack

That is, we're now deploying a trunk KVM based OpenStack using heat +
nova baremetal on a continuous basis into the test rack we have, it's
been running stably for 12 hours or so. Yay!

I think we should do a retrospective
(http://finding-marbles.com/retr-o-mat/what-is-a-retrospective/) at
the next TripleO meeting
https://wiki.openstack.org/wiki/TripleO/TripleOCloud/MVP1Retrospective
is where we'll capture the info from it.

We now have a choice - we can spend a bit of time on consolidation -
polish such as better instrumentation (e.g. logstash, deploy timing
data etc)   or we can get stuck into MVP2 : stateful upgrades where we
are updating a cloud rather than completely rebuilding. Also MVP2 may
be overly aggressive (in that there may be be dragons hidden there
that lead us to get stuck in a quagmire).

I think that we should get stateful upgrades going, and then
consolidate: a cloud that resets every 50m is a bit too interrupted to
expect users to use it, so we really have three key things to do to
get folk using the cloud [at all]:
 - externally accessible networking
 - preserve the users and vm's etc in the cloud during a deploy
 - live migrate or otherwise avoid breaking active VMs that are
running during a deploy

And after that we can get into serious incremental value delivery.

So, my proposal is that we do external networking (I think I can knock
that off today); then we reframe MVP2 as preserving users and vm's
etc, and add another overcloud MVP for keeping VM's running.

Thoughts?

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud