On 01/20/2017 08:06 AM, Alfredo Moralejo Alonso wrote:
On Fri, Jan 20, 2017 at 1:50 PM, Emilien Macchi <[email protected]> wrote:
On Fri, Jan 20, 2017 at 7:30 AM, Alfredo Moralejo Alonso
<[email protected]> wrote:
Hi,
In RDO we are preparing for the incoming Ocata release. This means
we'll create a new RDO Trunk builder "centos-ocata" in the next few
days (It will be ready for next week). This builder will get content
from stable/ocata branches of projects as they become available and
fallback to master for those not branched yet. The repos created by
this worker will be published under
https://trunk.rdoproject.org/centos7-ocata/ (which will not longer be
a link to https://trunk.rdoproject.org/centos7-master/).
According to the feedback received during the last release cycle, we
are changing the way we do the transition this time so that
repositories content will be more accurate to what is expected at any
point in the cycle. Repos under centos-master will allways follow
master branch and centos-ocata will get stable/ocata as soon as repos
get the branch created.
This has some implications from the upstream projects point of view:
- Projects using repositories under
https://trunk.rdoproject.org/centos7-ocata/ will start getting
packages for content delivered in stable/ocata branches instead of
master. Repos in https://trunk.rdoproject.org/centos7-master/ will
keep getting packages for content in master branch.
Excellent news.
- Anyone currently pinning to a specific hash repo under
https://trunk.rdoproject.org/centos7-ocata/ should move it to use
https://trunk.rdoproject.org/centos7-master/ as soon as possible. Note
that pinning to a specific hash is not recommended practice.
ack
- With current job definitions, link current-tripleo promoted by
upstream TripleoCI will promote repos with content from master
branches and not stable/ocata after creating the ocata builder. We
think this is not the desired situation during RC period and we must
keep promotion of current-tripleo link for stable/ocata until
cycle-trailing projects are tagged. This will require some changes in
both Tripleo-CI and RDO-CI, please let us know your thoughs so that we
can agree on the best way to implement this and start working on it.
I agree we need to move promotion job to stable/ocata until TripleO
release and then come back to master.
I'm wondering if it would be useful to create a new periodic job that
would run TripleO on master.
Tell me if I'm wrong, but the reason is during our trailing period,
things can (and probably will) break upstream and we might want to
keep aware of it. If we're not, I'm afraid we'll have to deal with a
huge list of blocker after our release when we'll come back on master.
I think the optimal situation would be to keep promotions in both
master an ocata during RC period. If we don't do that, I'm afraid it
will take us some time and effort to get a clean master again.
My understanding is that in the past we've played a bit fast and loose
with the end of the cycle. For example, at the end of the Newton cycle
after the other OpenStack projects cut their Newton branches, we
continued to run against their master for a period of time before we cut
our Newton branches. So essentially we were running our Newton against
their early Ocata. Since the overlap is short, we've gotten away with this.
Obviously that's not ideal, but there's another reason I think it would
be beneficial to start running promotion jobs against stable branches.
Right now, every stable job has to build images because without
promotion jobs there are no cached images. Since we keep making our
jobs longer and longer with each release, that's only going to get more
painful. If we had promotion jobs for stable branches we could cache
the images and speed things up considerably. There's also the benefit
that it would insulate us from broken backports, which has happened in
the past.
As far as what to do with master during that time, I think we'd at least
still keep running master jobs against tripleo-ci patches since that
already has multi-release jobs in project-config. Plus it will need to
have both master and stable/ocata jobs anyway. The other projects
should probably pin to ocata until their stable branches are cut.
However, I suspect this might involve some kind of ugly project-config
patches, so we may want to talk to infra about it as well. They might
have something in place for this situation already since all projects
don't cut their stable branches at the same time. Or maybe they can
tell us that it generally hasn't been a problem to run mixed releases
for a couple of weeks and it would be easier to fix any issues that
creep in after we cut our stable branches instead of trying to do this
dance. Although I still think stable promotion jobs would be beneficial
for the other reasons I noted above.
Thanks,
Best regards,
Alfredo
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Emilien Macchi
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
