Open Stack

On Thu, Jan 30, 2014 at 2:39 PM, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from James Slagle's message of 2014-01-30 07:28:01 -0800:
>> 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.

That would certainly help. Though, it could be hard to tell if a
failure is due to the devtest process *itself* (e.g., someone forgot
to document a step), or a change in one of the upstream OpenStack
projects.  Whereas if the process itself is less complex, I think it's
less likely to break.

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

I'm sure it's achievable, but I'm not sure it's worth the cost. It's
difficult to anticipate how hard it's going to be in the future to
continue to bend devtest to do all of "the things" really well (CI,
CD, dev manual/scripted setup, doc generation).

That being said, there's also cost associated with maintaining a
separate dev setup. I hope that whatever we came up with though would
keep that cost fairly minimal.

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

Agreed, I think this an easy short term win. I'll probably look at
getting that update submitted soon.

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

Thanks for the feedback.

-- 
-- James Slagle
--