Open Stack

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?

Thanks,
-- 
Emilien Macchi