Open Stack

I took an action to remove scenarios/baremetal jobs on pike/master:
https://review.openstack.org/518210

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.
>>>
>>>
>>> +1
>>> And we should start using the quickstart-extras undercloud-reploy role for
>>> that.
>>>
>>>>
>>>> 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
>>>> - 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
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> OK,
>> 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
>> containerized
>> 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
>> remove
>> 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
>> undercloud.
>> Thanks
>
> I did this patch:
> https://review.openstack.org/518197
>
> 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



-- 
Emilien Macchi