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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
