[openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

Alfredo Moralejo Alonso amoralej at redhat.com
Thu Mar 9 09:41:15 UTC 2017


On Wed, Mar 8, 2017 at 12:44 PM, Steven Hardy <shardy at redhat.com> wrote:
> Hi all,
>
> I wanted to raise visibility of a problem we're experiencing in TripleO CI,
> which I think will potentially affect other projects that consume trunk
> builds from the RDO repositories (and potentially other distros too I
> guess)
>
> The problem is that we tag our final ocata releases after branching
> stable/ocata, but there is then a period prior to cutting pike-1 milestone
> releases (or some other intermediate release for projects not following the
> milestone model) where trunk package builds n-v-r is older than the stable
> branches.
>
> This presents a big problem if you want to test package-derived updates
> from stable/$foo to master, as the pacakges don't get updated where the
> installed stable one is newer than the one built from master.
>
> I raised this bug initially thinking it was specific to the puppet-*
> projects, but it seems from subsequent discussion that it's a broader issue
> that may impact many OpenStack projects.
>
> https://bugs.launchpad.net/tripleo/+bug/1669462
>
> I'm not clear on the best path forward at this point, but the simplest one
> suggested so far is to simply tag a new pre-milestone/alpha release for all
> master branches, which will enable testing upgrades to master.
>

As reference, puppet team proposed a solution for this issue in
openstack puppet modules in
http://lists.openstack.org/pipermail/openstack-dev/2017-March/113494.html

However, as mentioned before this is affecting all projects, not only
puppet ones.

> I know we don't expect to fully support upgrades to pre-milestone releases,
> but the requirement here is to simply enable testing them.
>
> A side-benefit of this regular testing e.g via CI is we'll find upgrade issues
> much faster than waiting for one or more milestone releases to happen then
> doing an upgrade-debug firedrill later in the cycle (which has been bad for
> project and deployment teams IMO, so it'd be good to figure out this first
> step to enable earlier testing of upgrades to the development release).
>
> Any thoughts on how we can resolve this would be much appreciated, thanks!
>
> Steve
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list