On Tue, Jun 13, 2017 at 02:11:53PM -0500, Ben Nemec wrote: > > > On 06/13/2017 12:28 PM, Paul Belanger wrote: > > On Tue, Jun 13, 2017 at 11:12:08AM -0500, Ben Nemec wrote: > > > > > > > > > On 06/12/2017 06:19 PM, Ronelle Landy wrote: > > > > Greetings, > > > > > > > > TripleO OVB check gates are managed by upstream Zuul and executed on > > > > nodes provided by test cloud RH1. RDO Cloud is now available as a test > > > > cloud to be used when running CI jobs. To utilize to RDO Cloud, we could > > > > either: > > > > > > > > - continue to run from upstream Zuul (and spin up nodes to deploy > > > > the overcloud from RDO Cloud) > > > > - switch the TripleO OVB check gates to run as third party and > > > > manage these jobs from the Zuul instance used by Software Factory > > > > > > > > The openstack infra team advocates moving to third party. > > > > The CI team is meeting with Frederic Lepied, Alan Pevec, and other > > > > members of the Software Factory/RDO project infra tream to discuss how > > > > this move could be managed. > > > > > > > > Note: multinode jobs are not impacted - and will continue to run from > > > > upstream Zuul on nodes provided by nodepool. > > > > > > > > Since a move to third party could have significant impact, we are > > > > posting this out to gather feedback and/or concerns that TripleO > > > > developers may have. > > > > > > I'm +1 on moving to third-party...eventually. I don't think it should be > > > done at the same time as we move to a new cloud, which is a major change > > > in > > > and of itself. I suppose we could do the third-party transition in > > > parallel > > > with the existing rh1 jobs, but as one of the people who will probably > > > have > > > to debug problems in RDO cloud I'd rather keep the number of variables to > > > a > > > minimum. Once we're reasonably confident that RDO cloud is stable and > > > handling our workload well we can transition to third-party and deal with > > > the problems that will no doubt cause on their own. > > > > > This was a goal for tripleo-test-cloud-rh2, to move that to thirdparty CI, > > ensure jobs work, then migrated. As you can see, we never actually did that. > > > > My preference would be to make the move the thirdparty now, with > > tripleo-test-cloud-rh1. We now have all the pieces in place for RDO > > project to > > support this and in parallel set up RDO cloud to run jobs from RDO. > > > > If RDO stablility is a concern, the move to thirdparty first seems to make > > the > > most sense. This avoid the need to bring RDO cloud online, ensure it works, > > then > > move it again, and re-insure it works. > > > > Again, the move can be made seemless by turning down some of the capacity in > > nodepool.o.o and increase capacity in nodepool.rdoproject.org. And I am > > happy to > > help work with RDO on making this happen. > > I'm good with doing the third-party migration first too. I'm only looking > to avoid two concurrent major changes. > Great, I am happy to hear that :D
> __________________________________________________________________________ > 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
