[openstack-dev] [TripleO] containerized undercloud in Queens
emilien at redhat.com
Mon Nov 6 20:45:35 UTC 2017
On Mon, Nov 6, 2017 at 4:35 AM, Bogdan Dobrelya <bdobreli at redhat.com> wrote:
> On 11/6/17 1:01 AM, Emilien Macchi 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.
> And we should start using the quickstart-extras undercloud-reploy role for
YES! and reflect what our users would do in real life. No workaround.
>> - deploy 1 node instead of 2 nodes, so we save nodepool resources
>> - faster (no overcloud)
>> - reduce gate queue time, faster development process, faster CI
>> - keep overcloud testing, with OVB
>> - 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.
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev