Open Stack

On 01/20/2017 08:06 AM, Alfredo Moralejo Alonso wrote:
> On Fri, Jan 20, 2017 at 1:50 PM, Emilien Macchi <emilien at redhat.com> wrote:
>> On Fri, Jan 20, 2017 at 7:30 AM, Alfredo Moralejo Alonso
>> <amoralej at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Emilien Macchi
>>
>> __________________________________________________________________________
>> 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
>
> __________________________________________________________________________
> 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
>