Open Stack

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.

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

> 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?

> - 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?

-- 
-- James Slagle
--