Wesley Hayutin <whayutin at redhat.com> writes:
[snip]
The TripleO project has created a single node container based composable OpenStack deployment [2]. It is the projects intention to replace most of the TripleO upstream jobs with the Standalone deployment. We would like to reduce our multi-node usage to a total of two or three multinode jobs to handle a basic overcloud deployment, updates and upgrades[a]. Currently in master we are relying on multiple multi-node scenario jobs to test many of the OpenStack services in a single job. Our intention is to move these multinode scenario jobs to single node job(s) that tests a smaller subset of services. The goal of this would be target the specific areas of the TripleO code base that affect these services and only run those there. This would replace the existing 2-3 hour two node job(s) with single node job(s) for specific services that completes in about half the time. This unfortunately will reduce the overall coverage upstream but still allows us a basic smoke test of the supported OpenStack services and their deployment upstream. Ideally projects other than TripleO would make use of the Standalone deployment to test their particular service with containers, upgrades or for various other reasons. Additional projects using this deployment would help ensure bugs are found quickly and resolved providing additional resilience to the upstream gate jobs. The TripleO team will begin review to scope out and create estimates for the above work starting on October 18 2018. One should expect to see updates on our progress posted to the list. Below are some details on the proposed changes. Thank you all for your time and patience! Performance improvements: * Standalone jobs use half the nodes of multinode jobs * The standalone job has an average run time of 60-80 minutes, about half the run time of our multinode jobs Base TripleO Job Definitions (Stein onwards): Multi-node jobs * containers-multinode * containers-multinode-updates * containers-multinode-upgrades Single node jobs * undercloud * undercloud-upgrade * standalone Jobs to be removed (Stein onwards): Multi-node jobs[b] * scenario001-multinode * scenario002-multinode * scenario003-multinode * scenario004-multinode * scenario006-mulitinode * scenario007-multinode * scenario008-multinode * scenario009-multinode * scenario010-multinode * scenario011-multinode Jobs that may need to be created to cover additional services[4] (Stein onwards): Single node jobs[c] * standalone-barbican * standalone-ceph[d] * standalone-designate * standalone-manila * standalone-octavia * standalone-openshift * standalone-sahara * standalone-telemetry [1] https://gist.github.com/notmyname/8bf3dbcb7195250eb76f2a1a8996fb00 [2] https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/standalone.html [3] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134867.html [4] https://github.com/openstack/tripleo-heat-templates/blob/master/README.rst#service-testing-matrix
I wanted to follow-up that original thread [0] wrt running a default standalone tripleo deployment integration job for openstack-puppet modules to see if it breaks tripleo. There is a topic [1] to review please.
The issue (IMO) is that the default standalone setup deploys a fixed set of openstack services, some are disabled [2] and some go by default [3], which may be either an excessive or lacking coverage (like Ironic) for some of the puppet openstack modules.
My take is it only makes sense to deploy that standalone setup for the puppet-openstack-integration perhaps (and tripleo itself obviously, as that involves a majority of openstack-puppet modules), but not for each particular puppet-foo module.
Why wasting CI resources for that default job clonned for the modules and see, for example, puppet-keystone (and all other modules) standalone jobs failing because of an unrelated puppet-nova's libvirt issue [4]? That's pointless and inefficient. And to cover Ironic deployments, we'd have to keep the undercloud job as a separate.
Although that probably is acceptable as a first iteration... But ideally I'd like to see that standalone job composable and adapted to only test a deployment for the wanted components for puppet-foo modules under check/gate. And it also makes sense to disable tempest for the standalone job(s) perhaps as it is already covered by neighbour jobs.
[0] https://goo.gl/UFNtcC [1] https://goo.gl/dPkgCH [2] https://goo.gl/eZ1wuC [3] https://goo.gl/H8ZnAJ [4] https://review.openstack.org/609289 -- 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
