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 <emil...@redhat.com> wrote: > On Mon, Nov 6, 2017 at 12:57 PM, Wesley Hayutin <whayu...@redhat.com> wrote: >> >> >> On Mon, Nov 6, 2017 at 7:35 AM, Bogdan Dobrelya <bdobr...@redhat.com> wrote: >>> >>> On 11/6/17 1:01 AM, Emilien Macchi wrote: >>>> >>>> On Mon, Oct 2, 2017 at 5:02 AM, Dan Prince <dpri...@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-requ...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev