Open Stack

On 03/07/2015 04:34 AM, Dan Prince wrote:
> On Tue, 2015-03-03 at 17:30 -0500, James Slagle wrote:
>> 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.
>
> +1 Using packages solves some problems very nicely. We haven't solved
> all the CI related issues around using packages with upstream but it is
> getting better. I mention this because it would be nice to have CI
> testing on the upgrade process automated at some point...
>
>>
>> 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?
>
> In general most of the puppet modules support the required HA bits. We
> are still working to integrate some of the final pieces here but in
> general I expect this to proceed quickly.

going back to CI, I think this would benefit from an additional CI job

given we have a non-voting HA job running on precise/elements, I'd like 
to add one running on fedora/puppet, maybe initially non-voting as well

this said, it would also be nice to have a job which deploys additional 
block storage (cinder) and object storage (swift) nodes ...

... and to save some resources, maybe we can switch 
'check-tripleo-ironic-overcloud-f20puppet-nonha' and 
'check-tripleo-ironic-overcloud-precise-nonha' to deploy a single 
compute node instead of two

>> 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.
>
> I think this is an interesting idea and perhaps has some merit. I'd like
> to see some specific examples showing how the unified CLI might make
> things easier for end users...

I am of the same feeling; AFAIK devtest was meant to setup a development 
environment, not a production environment, more on this later

>> 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?
>
> And also should we think about possibly renaming these? I find that many
> times when talking about TripleO to someone new they find the whole
> undercloud/overcloud thing confusing. Calling the undercloud the
> "baremetal cloud" makes it click.

I don't think we need more; what I would like to have instead is a tool, 
targeted at end users, capable of setting up an undercloud without going 
through the seed

this said, I am really not sure if that should be a wrapper around 
devtest --no-undercloud or a tool which turns the existing base os into 
an undercloud; both seem to have pros and cons

>> 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....

personally, while I tried to join this conversation in the past, I am 
still unsure whether for tripleo a stable/master approach would work 
better or not than a synchronized release cadence
-- 
Giulio Fidente
GPG KEY: 08D733BA