settingsLogin | Registersettings

[openstack-dev] [tripleo][releases] Remove diskimage-builder from releases

0 votes

Hi,

diskimage-builder has fallen under the "centralised release tagging"
mechanism [1], presumably because it is under tripleo. I'd like to
propose that we don't do that.

Firstly, dib doesn't have any branches to manage.

dib's other main function is as part of the daily CI image builds.
This means to get a fix into the CI images in a somewhat timely
fashion, we approve the changes and make sure our releases happen
before 14:00 UTC, and monitor the build results closely in nodepool.

I don't expect the stable release team to be involved with all this;
but if we miss windows then we're left either going to efforts getting
one of a handful of people with permissions to do manual rebuilds or
waiting yet another day to get something fixed. Add some timezones
into this, and simple fixes are taking many days to get into builds.
Thus adding points where we can extend this by another 24 hours
really, well, sucks.

I have previously suggested running dib from git directly to avoid the
release shuffle, but it was felt this was not the way to go [2]. I've
proposed putting the release group back with [3] and cleaning up with
[4].

Thanks,

-i

[1] https://review.openstack.org/298866
[2] https://review.openstack.org/283877
[3] https://review.openstack.org/307531
[4] https://review.openstack.org/307534


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Apr 19, 2016 in openstack-dev by Ian_Wienand (3,620 points)   4 5

12 Responses

0 votes

Excerpts from Ian Wienand's message of 2016-04-20 06:25:17 +1000:

On 04/20/2016 03:25 AM, Doug Hellmann wrote:

It's not just about control, it's also about communication. One of
the most frequent refrains we hear is "what is OpenStack", and one
way we're trying to answer that is to publicize all of the things
we release through releases.openstack.org.

So for dib, this is mostly about documentation?

This isn't about DIB in particular. The change wasn't made because
you were doing anything wrong, or not doing something. It's about
not having a bunch of special case exceptions so that all projects
work the same way and everyone understands what it means to be part
of the official project list. DIB, as an official project, was
included in the list of repositories for which I adjusted the ACLs.

After discussing it with the release team, we're proposing that we
revert the ACL changes for projects using the release:independent
model. Those projects are already declaring, through that model,
that they are not part of the openstack release cycle, and hence
not part of what is being managed by the release team. To that end,
I've proposed https://review.openstack.org/308044.

I've also proposed updates to the governance tag definitions to
document the expectations related to this issue for the release
tags: https://review.openstack.org/308045

So, consider what model you want to use. If release:independent
works for you, then you can keep tagging when you want, and if you
care to advertise those releases you can propose changes to
openstack/releases after the fact. If you want a release:cycle-*
tag, we'll have to figure out how to incorporate the review step
in your release process because project tagged as part of the cycle
are very definitely things we're managing as part of the product.

That said, another goal of the automation work was to provide a way
to have tags reviewed before they were applied, though, so I do
expect that some time in the future we will have all deliverables
for all projects going through the tag review process. That will
wait until the automation is completed and we have a larger team
of reviewers (it will be easier to add members to the team when it
isn't necessary to set up a bunch of tools to run locally). At that
point I would expect to have enough folks on the team doing those
reviews that there would be no schedule-based reason for a project
to be unable to manage its tags that way.

Doug


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Doug_Hellmann (87,520 points)   3 4 12
0 votes

On 2016-04-19 15:34:16 -0400 (-0400), James Slagle wrote:
A fork would be unfortunate. What about a new repo that's just for
the elements used heavily by infra, e.g.,
openstack-infra-elements.
[...]

We do already have a bunch of elements in
openstack-infra/project-config, so most of the velocity concerns
have been around "upstream" elements (lately a number of the
-minimal distro variants as we've been migrating our nodepool
deployment to rely heavily on dib). Decoupling the elements in
diskimage-builder from the framework and maintaining them in
separately-versioned repositories might help, but regardless Infra
team consensus has been primarily to just keep collaborating on
those common elements and find downstream workarounds while we wait
for bug fixing iteration to take place and releases to be tagged.

I definitely think dib is part of "OpenStack the Product" given it
has to be used by users and operators of TripleO.

Makes sense! It's also possible some of the elements bundled in
diskimage-builder aren't actually used in "OpenStack the Product"
and are just along for the ride, but I don't really know enough
about the other consuming projects to be able to say either way.
--
Jeremy Stanley


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Apr 19, 2016 by Jeremy_Stanley (56,700 points)   3 5 7
...