Open Stack

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