tl;dr: You're right, it would be useful. Points on what is blocking it below:
Excerpts from James Slagle's message of 2014-01-17 05:18:01 -0800: > On Thu, Jan 16, 2014 at 7:29 PM, Clint Byrum <[email protected]> wrote: > > Note that tripleo-incubator is special and should not be released. It > > is intentionally kept unfrozen and unreleased to make sure there is no > > illusion of stability. > > I think it would be nice if we could point people at a devtest that > they could use with our other released stuff. Without that, we might > make a change to devtest, such as showing the use of a new heat > parameter in our templates, and if they're trying to follow along with > a released tripleo-heat-templates then they would have a problem. > > Without a branch of incubator, there's no story or documentation > around using any of our released stuff. You could follow along with > devtest to get an idea of how it's supposed to work and indeed it > might even work, but I don't think that's good enough. There is > tooling in incubator that has proved it's usefulness. Take an example > like setup-endpoints, what we're effectively saying without allowing > people to use that is that there is a useful tool that will setup > endpoints for you, but don't use it with our released stuff because > it's not gauranteed to work and instead make these 10'ish calls to > keystone via some other method. Then you'd also end up with a > different but parallel set of instructions for using our released > stuff vs. not. > I'll address the bigger points here below, but for the record, I think setup-endpoints and register-endpoint are stable enough now that they should just be included with keystoneclient or keystone. Perhaps rewritten as subcommands to the keystone cli, but even as-is they would be useful in keystoneclient's bin dir IMO. > This is prohibitive to someone who may want to setup a tripleo CI/CD > cloud deploying stable icehouse or from milestone branches. I think > people would just create their own fork of tripleo-incubator and use > that. > > > If there are components in it that need releasing, they should be moved > > into relevant projects or forked into their own projects. > > I'd be fine with that approach, except that's pretty much everything > in incubator, the scripts, templates, generated docs, etc. Instead of > creating a new forked repo, why don't we just rename tripleo-incubator > to tripleo-deployment and have some stable branches that people could > use with our releases? > > I don't feel like that precludes tripleo from having no stability on > the master branch at all. If we are prepared to make basic release-to-release stability guarantees for everything in incubator (or kick the few things we aren't prepared to do that for out to a new incubator) then huzzah! Lets do what you suggest above. :) I just don't think we're there yet, and I'd rather see us fork off the things that are ready as they get to that point rather than try to make a giant push to freeze the whole thing. I'm afraid we'd have users in a bad position by expecting the icehouse version of assert-user to still be there and keep working in Juno. To put some analysis where my rhetoric is, I've taken a look at all of the scripts. By my count there are 43 scripts, 10 of which are not really part of "TripleO". By lines of code, there are about 1954 lines of actual code and 600 lines in the "not TripleO" parts. So between 20 and 30 percent of the code shouldn't be part of TripleO and should be pushed into their own releasable places. I've included the classifications below. Also before any of it gets released we need: * Gating * Commitment to real documentation * Thierry's blessing. :) ==Script classifications== CD cloud related - never freezes assert-users assert-admin-users assert-user -- Perhaps merge with os-adduser --Belongs in keystoneclient setup-endpoints register-endpoint os-adduser -- Might need a rename? --Belongs in glanceclient: load-image --Could be forked into a tripleo-devtest project: boot-seed-vm setup-network configure-vm create-nodes set-os-type devtest_setup.sh devtest_seed.sh devtest_variables.sh devtest.sh refresh-env cleanup-env devtest_ramdisk.sh extract-docs.awk devtest_undercloud.sh devtest_overcloud.sh write-tripleorc install-dependencies devtest_end.sh register-nodes extract-docs devtest_testenv.sh takeovernode --Not devtest only, releasable, but specific to TripleO: init-keystone setup-overcloud-passwords pull-tools setup-seed-vm stack-ready user-config get-vm-mac setup-clienttools setup-neutron setup-undercloud-passwords setup-baremetal --Useful, but too tiny for their own repo: os-make-password -- arguably we should just use pwgen wait_for send-irc _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
