[openstack-dev] [TripleO] milestone-proposed branches
clint at fewbar.com
Fri Jan 17 20:09:10 UTC 2014
tl;dr: You're right, it would be useful. Points on what is blocking it
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
> > 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
Also before any of it gets released we need:
* Commitment to real documentation
* Thierry's blessing. :)
CD cloud related - never freezes
assert-user -- Perhaps merge with os-adduser
--Belongs in keystoneclient
os-adduser -- Might need a rename?
--Belongs in glanceclient:
--Could be forked into a tripleo-devtest project:
--Not devtest only, releasable, but specific to TripleO:
--Useful, but too tiny for their own repo:
os-make-password -- arguably we should just use pwgen
More information about the OpenStack-dev