Open Stack

Hi,

Don't let the subject throw you off :)

I wasn't sure how to phrase what I wanted to capture in this mail, and
that seemed reasonable enough. I wanted to kick off a discussion about
what gaps people think are missing from TripleO before we can meet the
goal of realistically being able to use TripleO in production.

The things in my mind are:

Upgrades - I believe the community is trending away from the image
based upgrade rebuild process. The ongoing Puppet integration work is
integrated with Heat's SoftwareConfig/SoftwareDeployment features and
is package driven. There is still work to be done, especially around
supporting rollbacks, but I think this could be part of the answer to
how the upgrade problem gets solved.

HA - We have an implementation of HA in tripleo-image-elements today.
However, the Puppet codepath leaves that mostly unused. The Puppet
modules however do support HA. Is that the answer here as well?

CLI - We have devtest. I'm not sure if anyone would argue that should
be used in production. It could be...but I don't think that was it's
original goal and it shows. The downstreams of TripleO that I'm aware
of each ended up more of less having their own CLI tooling. Obviously
I'm only very familiar with one of the downstreams, but in some
instances I believe parts of devtest were reused, and other times not.
That begs the question, do we need a well represented unified CLI in
TripleO? We have a pretty good story about using Nova/Ironic/Heat[0]
to deploy OpenStack, and devtest is one such implementation of that
story. Perhaps we need something more production oriented.

Baremetal management - To what extent should TripleO venture into this
space? I'm thinking things like discovery/introspection, ready state,
and role assignment. Ironic is growing features to expose things like
RAID management via vendor passthrough API's. Should TripleO take a
role in exercising those API's? It's something that could be built
into the flow of the unified CLI if we were to end up going that
route.

Bootstrapping - The undercloud needs to be
bootstrapped/deployed/installed itself. We have the seed vm to do
that. I've also worked on an implementation to install an undercloud
via an installation script assuming the base OS is already installed.
Are these the only 2 options we should consider, or are there other
ideas that will integrate better into existing infrastructure?

Release Cadence with wider OpenStack - I'd love to be able to say on
the day that a new release of OpenStack goes live that you can use
TripleO to deploy that release in production...and here's how you'd do
it....

What other items should we include here? I almost added a point for
Stability, but let's just assume we want to make everything as stable
as we possibly can :).

I know I've mostly raised questions. I have some of my own answers in
mind. But, I was actually hoping to get others talking about what the
right answers might be.

[0] Plus the other supporting cast of characters: Keystone/Glance/Neutron/Swift.

Thanks.

-- 
-- James Slagle
--