[openstack-dev] [TripleO] containerized undercloud in Queens

Emilien Macchi emilien at redhat.com
Tue Nov 7 21:59:09 UTC 2017

On Wed, Nov 8, 2017 at 3:30 AM, James Slagle <james.slagle at gmail.com> wrote:
> On Sun, Nov 5, 2017 at 7:01 PM, Emilien Macchi <emilien at redhat.com> wrote:
>> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince <dprince at redhat.com> wrote:
>> [...]
>>>  -CI resources: better use of CI resources. At the PTG we received
>>> feedback from the OpenStack infrastructure team that our upstream CI
>>> resource usage is quite high at times (even as high as 50% of the
>>> total). Because of the shared framework and single node capabilities we
>>> can re-architecture much of our upstream CI matrix around single node.
>>> We no longer require multinode jobs to be able to test many of the
>>> services in tripleo-heat-templates... we can just use a single cloud VM
>>> instead. We'll still want multinode undercloud -> overcloud jobs for
>>> testing things like HA and baremetal provisioning. But we can cover a
>>> large set of the services (in particular many of the new scenario jobs
>>> we added in Pike) with single node CI test runs in much less time.
>> After the last (terrible) weeks in CI, it's pretty clear we need to
>> find a solution to reduce and optimize our testing.
>> I'm now really convinced by switching our current scenarios jobs to
>> NOT deploy the overcloud, and just an undercloud with composable
>> services & run tempest.
> +1 if you mean just the scenarios.

Yes, just scenarios.

> I think we need to keep at least 1 multinode job voting that deploys
> the overcloud, probably containers-multinode.

Yes, exactly, and also work on optimizing OVB jobs (maybe just keep
one or 2 jobs, instead 3).

>> Benefits:
>> - deploy 1 node instead of 2 nodes, so we save nodepool resources
>> - faster (no overcloud)
>> - reduce gate queue time, faster development process, faster CI
>> Challenges:
>> - keep overcloud testing, with OVB
> This is why I'm not sure what you're proposing. Do you mean switch all
> multinode jobs to be just an undercloud, or just the scenarios?

Keep 1 or 2 OVB jobs, to test ironic + mistral + HA (HA could be
tested with multinode though but well).

>> - reduce OVB to strict minimum: Ironic, Nova, Mistral and basic
>> containerized services on overcloud.
>> I really want to get consensus on these points, please raise your
>> voice now before we engage some work on that front.
> I'm fine to optimize the scenarios to be undercloud driven, but feel
> we still need a multinode job that deploys the overcloud in the gate.
> Otherwise, we'll have nothing that deploys an overcloud in the gate,
> which is a step in the wrong direction imo. Primarily, b/c of the loss
> of coverage around mistral and all of our workflows. Perhaps down the
> road we could find ways to optimize that by using an ephemeral Mistral
> (similar to the ephemeral Heat container), and then use a single node,
> but we're not there yet.
> On the other hand, if the goal is just to test less upstream so that
> we can more quickly merge code, then *not* deploying an overcloud in
> the gate at all seems to fit that goal. Is that what you're after?

Yes. Thanks for reformulate with better words.
Just to be clear, I want to transform the scenarios into single-node
jobs that deploy the SAME services (using composable services) from
the undercloud, using the new ansible installer. I also want to keep
running Tempest.
And of course, like we said, keep one multinode job to test overcloud
workflow, and OVB with some adjustments.

Is it good?

Emilien Macchi

More information about the OpenStack-dev mailing list