On Tue, Jun 13, 2017 at 3:11 PM, Ben Nemec <[email protected]> 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.
+1, I do agree with Ben here. Go for it! > > __________________________________________________________________________ > 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
