[openstack-dev] [TripleO] devtest thoughts
openstack at nemebean.com
Thu Jan 30 20:44:39 UTC 2014
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
More information about the OpenStack-dev