Open Stack

On 3 March 2014 23:12, Thierry Carrez <thierry at openstack.org> wrote:
> James Slagle wrote:
>> I'd like to ask that the following repositories for TripleO be included
>> in next week's cutting of icehouse-3:
>>
>> http://git.openstack.org/openstack/tripleo-incubator
>> http://git.openstack.org/openstack/tripleo-image-elements
>> http://git.openstack.org/openstack/tripleo-heat-templates
>> http://git.openstack.org/openstack/diskimage-builder
>> http://git.openstack.org/openstack/os-collect-config
>> http://git.openstack.org/openstack/os-refresh-config
>> http://git.openstack.org/openstack/os-apply-config
>>
>> Are you willing to run through the steps on the How_To_Release wiki for
>> these repos, or should I do it next week? Just let me know how or what
>> to coordinate. Thanks.
>
> I looked into more details and there are a number of issues as TripleO
> projects were not really originally configured to be "released".
>
> First, some basic jobs are missing, like a tarball job for
> tripleo-incubator.

Do we need one? tripleo-incubator has no infrastructure to make
tarballs. So that has to be created de novo, and its not really
structured to be sdistable - its a proving ground. This needs more
examination. Slagle could however use a git branch effectively.

> Then the release scripts are made for integrated projects, which follow
> a number of rules that TripleO doesn't follow:
>
> - One Launchpad project per code repository, under the same name (here
> you have tripleo-* under tripleo + diskimage-builder separately)

Huh? diskimage-builder is a separate project, with a separate repo. No
conflation. Same for os-*-config, though I haven't made a LP project
for os-cloud-config yet (but its not a dependency yet either).

> - The person doing the release should be a "driver" (or "release
> manager") for the project (here, Robert is the sole driver for
> diskimage-builder)

Will fix.

> - Projects should have an icehouse series and a icehouse-3 milestone

James should be able to do this once we have drivers fixed up.

> Finally the person doing the release needs to have "push annotated tags"
> / "create reference" permissions over refs/tags/* in Gerrit. This seems
> to be missing for a number of projects.

We have this for all the projects we release; probably not incubator
because *we don't release it*- and we had no intent of doing releases
for tripleo-incubator - just having a stable branch so that there is a
thing RH can build rpms from is the key goal.

> In all cases I'd rather limit myself to incubated/integrated projects,
> rather than extend to other projects, especially on a busy week like
> feature freeze week. So I'd advise that for icehouse-3 you follow the
> following simplified procedure:
>
> - Add missing tarball-creation jobs
> - Add missing permissions for yourself in Gerrit
> - Skip milestone-proposed branch creation
> - Push tag on master when ready (this will result in tarballs getting
> built at tarballs.openstack.org)
>
> Optionally:
> - Create icehouse series / icehouse-3 milestone for projects in LP
> - Manually create release and upload resulting tarballs to Launchpad
> milestone page, under the projects that make the most sense (tripleo-*
> under tripleo, etc)
>
> I'm still a bit confused with the goals here. My original understanding
> was that TripleO was explicitly NOT following the release cycle. How
> much of the integrated projects release process do you want to reuse ?
> We do a feature freeze on icehouse-3, then bugfix on master until -rc1,
> then we cut an icehouse release branch (milestone-proposed), unfreeze
> master and let it continue as Juno. Is that what you want to do too ? Do
> you want releases ? Or do you actually just want stable branches ?

This is the etherpad:
https://etherpad.openstack.org/p/icehouse-updates-stablebranches -
that captures our notes from the summit.

TripleO has a whole is not committing to stable maintenance nor API
service integrated releases as yet: tuskar is our API service which
will follow that process next cycle, but right now it has its guts
open undergoing open heart surgery. Everything else we do semver on -
like the openstack clients (novaclient etc) - and our overall process
is aimed at moving things from incubator into stable trees as they
mature. We'll be stabilising the interfaces in tripleo-heat-templates
and tripleo-image-elements somehow in future too - but we don't have
good answers to some aspects there yet.

BUT

We want to support members of the TripleO community that are
interested in shipping stable editions of TripleO even while it still
building up to being a product, which James is leading the effort on -
so we need to find reasonable compromises on areas of friction in the
interim.

Cheers,
Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud