[openstack-dev] [tripleo] upstream OVB jobs - roadmap

Emilien Macchi emilien at redhat.com
Thu Nov 23 18:59:45 UTC 2017


Queens's main theme is stabilization.
That's what we're currently working on in our CI, see which areas we
can consolidate and stabilize so we can continue to scale TripleO
development.

One of the challenges that we had in the last years was the high
demand of OVB jobs versus the capacity.
To address that, we recently decided to remove ovb-nonha. It was a good start.

Now we have:
- ovb-ha which test introspection, Pacemaker, TLS, net-iso (multi-nics)
- ovb-containers which tested a containerized overcloud
- ovb-1ctlr_1comp_1ceph-featureset024: which was renamed from
ovb-updates and is supposed to test ipv6 overcloud, stack updates &
ceph. It doesn't test stack updates (since the switch to
tripleo-quickstart), and Ceph is already extensively tested in
multinode scenario001/004 jobs.

That said, I think we can consolidate the OVB jobs in 2:

- keep ovb-ha and containerize it in Queens and beyond: it was already
approved and change is being applied now:
https://review.openstack.org/#/c/522293/
  indeed, we decided as a community that we would stop supporting
non-containerized overclouds in Queens and beyond.
- remove ovb-containers in Queens and beyond: useless now, since we
have ovb-ha containerized: https://review.openstack.org/#/c/522579/
- Remove ovb-1ctlr_1comp_1ceph-featureset024 and create ovb-ha-ipv6:
https://review.openstack.org/#/c/522618/
  indeed, ceph is already well tested in scenarios, ipv6 would be
tested in ovb-ha-ipv6.
  for overcloud updates, I haven't seen the feature in quickstart but
I might have missed something (any help here is welcome).

At the end, we should end up with 2 OVB jobs:
- ovb-ha (could be renamed in ovb-ha-ipv4 if that helps)
- ovb-ha-ipv6

Both would test the things that can't be tested by multinode:
- Nova / Ironic / Mistral workflow
- Introspection
- TLS
- Network Isolation
- IPv6 for the ovb-ha-ipv6
- Containerized overcloud

As a result, we have more coverage (except for stack updates but it
needs to be addressed in quickstart first) and less jobs, so less
resources consumed.

Any feedback on this plan is more than welcome,
-- 
Emilien Macchi



More information about the OpenStack-dev mailing list