[openstack-dev] [TripleO] containerized undercloud in Queens
emilien at redhat.com
Tue Nov 7 03:47:13 UTC 2017
I took an action to remove scenarios/baremetal jobs on pike/master:
I think it's a good step forward cleaning things up and saving CI resources.
I also think we should keep one multinode/baremetal job on pike (and
probably ovb), and kill all baremetal jobs in master. That would be
the next iteration I guess.
Any feedback is welcome,
On Mon, Nov 6, 2017 at 6:22 PM, Emilien Macchi <emilien at redhat.com> wrote:
> On Mon, Nov 6, 2017 at 12:57 PM, Wesley Hayutin <whayutin at redhat.com> wrote:
>> On Mon, Nov 6, 2017 at 7: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
>>>> - 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
>> Just got off the containers call. We discussed the CI requirements for the
>> containerized undercloud.
>> In the upstream, launched via quickstart not tripleo.sh we want to see
>> 1) undercloud-containers - a containerized install, should be voting by m1
> Hum. We're already in m2 now FYI.
>> 2) undercloud-containers-update - minor updates run on containerized
>> underclouds, should be voting by m2
>> 3) undercloud-containers-upgrade - major upgrade from
>> non-containerized to containerized undercloud, should be voting by m2.
>> The above three items will enable us to test the quality of just the
>> undercloud install.
>> Ian and I are also working together on testing full deployments with the
>> undercloud to test how stable full runs are generally. This will
>> help us assess the readiness of switching over in full in queens.
>> This will also then lead into discussions and planning around where we can
>> multinode testing in upstream and start to fully utilize the benefits of the
>> containerized undercloud.
>> Please contact myself or Sagi regarding changes in the CI for the
> I did this patch:
> So we can switch our non voting job to use the quickstart featureset.
> Once the switch is made, we need to make sure the job actually works
> fine, otherwise we'll have to make adjustments.
> Next iterations in my mind:
> - run undercloud sanity test on undercloud-container job
> - switch existing featureset for scenarios to only deploy a
> containerized undercloud & run Tempest. The only blocker I see for
> that is the fact scenarios are multinode, and we now want one node.
> 2 options:
> - switch scenarios iteratively and when one works, patch infra to
> switch the job to 1node.
> - (expensive) create experimental jobs for each scenarios (and
> featuresets...) and make the switch at some point.
> I have a preference for option 1 which sounds easier and faster.
> Do we have an etherpad where we can collaborate and list tasks &
> assign folks? I don't want to overlap with any ongoing effort. If not,
> let's create one.
> Thanks Wes for your help, it's really cool to see we're making progress here.
> Emilien Macchi
More information about the OpenStack-dev