Currently the TLS-everywhere job (fakeha-caserver) runs as a periodic job. If there's gonna be a move. I would really appreciate that this is done once we move that job to run over oooq. So don't loose that job.
On Tue, Jun 13, 2017 at 12:01 AM, Wesley Hayutin <whayu...@redhat.com> wrote: > Greetings, > > I wanted to send out a summary email regarding some work that is still > developing and being planned to give interested parties time to comment and > prepare for change. > > Project: > Move tripleo periodic promotion jobs > > Goal: > Increase the cadence of tripleo-ci periodic promotion jobs in a way > that does not impact upstream OpenStack zuul queues and infrastructure. > > Next Steps: > The dependencies in RDO's instance of software factory are now > complete and we should be able to create a new a net new zuul queue in RDO > infra for tripleo-periodic jobs. These jobs will have to run both > multinode nodepool and ovb style jobs and utilize RDO-Cloud as the host > cloud provider. The TripleO CI team is looking into moving the TripleO > periodic jobs running upstream to run from RDO's software factory instance. > This move will allow the CI team more flexibility in managing the periodic > jobs and resources to run the jobs more frequently. > > TLDR: > There is no set date as to when the periodic jobs will move. The move > will depend on tenant resource allocation and how easily the periodic jobs > can be modified. This email is to inform the group that changes are being > planned to the tripleo periodic workflow and allow time for comment and > preparation. > > Completed Background Work: > After long discussion with Paul Belanger about increasing the cadence > of the promotion jobs [1]. Paul explained infa's position and if he doesn't > -1/-2 a new pipeline that has the same priority as check jobs someone else > will. To summarize the point, the new pipeline would compete and slow down > non-tripleo projects in the gate even when the hardware resources are our > own. > To avoid slowing down non-tripleo projects Paul has volunteered to help > setup the infrastructure in rdoproject to manage the queue ( zuul etc). We > would still use rh-openstack-1 / rdocloud for ovb, and could also trigger > multinode nodepool jobs. > There is one hitch though, currently, rdo-project does not have all the > pieces of the puzzle in place to move off of openstack zuul and onto > rdoproject zuul. Paul mentioned that nodepool-builder [2] is a hard > requirement to be setup in rdoproject before we can proceed here. He > mentioned working with the software factory guys to get this setup and > running. > At this time, I think this issue is blocked until further discussion. > [1] https://review.openstack.org/#/c/443964/ > [2] https://github.com/openstack-infra/nodepool/blob/master/ > nodepool/builder.py > > Thanks > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Juan Antonio Osorio R. e-mail: jaosor...@gmail.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev