Open Stack

Excerpts from James Slagle's message of 2014-01-30 07:28:01 -0800:
> devtest, our TripleO setup, has been rapidly evolving. We've added a
> fair amount of configuration options for stuff like using actual
> baremetal, and (soon) HA deployments by default. Also, the scripts
> (which the docs are generated from) are being used for both CD and CI.
> 
> This is all great progress.
> 
> However, due to these changes,  I think that devtest no longer works
> great as a tripleo developer setup. You haven't been able to complete
> a setup following our docs for >1 week now. The patches are in review
> to fix that, and they need to be properly reviewed and I'm not saying
> they should be rushed. Just that it's another aspect of the problem of
> trying to use devtest for CI/CD and a dev setup.
> 

I wonder, if we have a gate which runs through devtest entirely, would
that reduce the instances where we've broken everybody? Seems like it
would, but the gate isn't going to read the docs, it is going to run the
script, so maybe it will still break sometimes.

BTW I do think those patches should be first priority.

> I think it might be time to have a developer setup vs. devtest, which
> is more of a documented tripleo setup at this point.
>

What if we just focus on breaking devtest less often? Seems like that is
achievable and then we don't diverge from CI.

> In irc earlier this week (sorry if i misquoting the intent here), I
> saw mention of getting setup easier by just using a seed to deploy an
> overcloud.  I think that's a great idea.  We are all already probably
> doing it :). Why not document that in some sort of fashion?
>

+1. I think a note at the end of devtest_seed which basically says "If
you are not interested in testing HA baremetal, set these variables like
so and skip to devtest_overcloud. Great idea actually, as thats what I
do often when I know I'll be tearing down my setup later.

> There would be some initial trade offs, around folks not necessarily
> understanding the full devtest process. But, you don't necessarily
> need to understand all of that to hack on the upgrade story, or
> tuskar, or ironic.
> 

Agreed totally. The processes are similar enough that when the time
comes that a user needs to think about working on things which impact
the undercloud they can back up to seed and then do that.