Open Stack

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 <clint at fewbar.com> 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