Open Stack

Excerpts from Adam Lawson's message of 2014-10-20 18:47:36 -0500:
> I made a similar comment to the Triple-O design summmit etherpad in hopes
> others have a similar interest in Kilo but I wanted to share evangelize my
> thoughts with the community for discussion:
> 
> For better or for worse, one thing I've heard over and over is how
> Openstack community/TC approves/prefers the use of TripleO and Ironic to
> deploy Openstack on bare metal. Cool, but for the majority of users
> considering using Openstack in their organization, the question always goes
> back to: If I'm not savvy enough yet to install Openstack without these
> tools, how do I setup TripleO and Ironic? Seems like a chien and egg thing.
> 
> There has not been much discussion (that I've noticed) re making a
> deployment process easy to erect. That should be the easy part but it's as
> confusing as the second part for most who are starting out. Using Openstack
> to deploy Openstack means the installer method should be straight forward
> and itself should be easy to install for users with limited understanding
> of Openstack or the tooling methods used by OOO and Ironic. But the bar to
> use Openstack continues to be a relatively-high engineering hurdle. It
> always has been and I'd love to see that change in the next cycle.
> 
> Something that comes to mind:
> 
>    - Setup Process Definition
>    - Quickstart Wizards
>    - Tooling
> 
> The above may seem to be dumbing down the process but widespread Openstack
> adoption requires an easy on-boarding process and so far, it simply doesn't
> exist.

You're so right, we do need that.

And it is something we've talked about a lot amongst ourselves, but we
clearly haven't publicized it.

Basically what you described is what Tuskar is intended to be.

The basic idea for a TripleO install remains the same as when we first
defined it:

* Boot a seed VM on a machine physically attached to the provisioning
  network. Seed VM is an Ironic based single machine OpenStack.

* Inform the seed's Ironic about the first real machine you want it to
  deploy as a deployment cloud (aka "undercloud") machine.

* Deploy first deployment cloud machine.

* Shut down the seed. [1]

* Inform deployment cloud of inventory for all hardware.

* Deploy the user cloud (aka "overcloud")

So Tuskar would be a part of that deployment cloud, and would ask you
things about your hardware, your desired configuration, and help you
get the inventory loaded.

So, ideally our gate would leave the images we test as part of the
artifacts for build, and we could just distribute those as part of each
release. That probably wouldn't be too hard to do, but those images
aren't exactly small so I would want to have some kind of strategy for
distributing them and limiting the unique images users are exposed to so
we're not encouraging people to run CD by downloading each commit's image.

There's also, I think, an interesting shift coming that the Kolla project
is investigating, which is that perhaps what we should distribute is
docker images, not qcow2's. That idea is still pretty new, but we should
definitely think about how that might be better for everyone.

[1] We don't do this now because there is still some interdependency
between seed and undercloud. We're working on it.