Open Stack

On 2014-01-30 13:32, Clint Byrum wrote:
> Excerpts from Ben Nemec's message of 2014-01-30 11:08:44 -0800:
>> On 2014-01-30 09:28, James Slagle wrote:
>> > 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 think it might be time to have a developer setup vs. devtest, which
>> > is more of a documented tripleo setup at this point.
>> >
>> > 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?
>> >
>> > 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.
>> >
>> > These are just some additional thoughts around the process and mail I
>> > sent earlier this week:
>> > http://lists.openstack.org/pipermail/openstack-dev/2014-January/025726.html
>> > But, I thought this warranted a broader discussion.
>> 
>> Another aspect I've noticed lately is that there has been discussion
>> around making sure the defaults in devtest are production-ready, which
>> seems to contradict both parts of the name devtest. :-)
>> 
> 
> Hm, can you point to some of those discussions? We want the defaults in
> all of OpenStack to be production ready, and we want devtest to work in
> that way when it doesn't put undue burden on development or testing.
> 

I'm thinking of things like 
http://eavesdrop.openstack.org/irclogs/%23tripleo/%23tripleo.2014-01-20.log starting at 2014-01-20T19:17:56.

I realize that wasn't saying we wouldn't have dev/CI options available, 
but having devtest default to production settings causes cognitive 
dissonance for me.  Maybe it's simply a naming thing - if it were called 
tripleo-deploy.sh or something it would make more sense to me.  And even 
if that happened, I still think we need some developer-specific 
documentation to cover things like skipping the undercloud and deploying 
seed->overcloud.  I have enough issues if I skip a single step from 
devtest because I think it isn't necessary - half the time I'm wrong and 
something breaks later on.  I would never have even tried completely 
skipping the undercloud on my own.

There are also things like pypi-openstack and pip-cache (which are at 
least mentioned in devtest) and James's new local image support that can 
be huge timesavers for developers, but we can't/won't use by default.  
Having a developer best practice guide that could say "Set FOO=bar 
before starting devtest to take advantage of better squid caching" and 
"Skip the entire undercloud page if you're working only on the 
overcloud" would be very helpful IMHO.

On a related note, I would point out 
https://review.openstack.org/#/c/67557/ which is something that I would 
find useful as a developer and has two -1's for no reason other than it 
isn't useful outside of development, at least as I see it.  I'm not sure 
this one is directly production vs. development, but I think it's an 
example of how devtest isn't especially developer-oriented at this 
point.

-Ben