Open Stack

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