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.
__________________________________________________________________________
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
