Open Stack

 ---- On Fri, 30 Apr 2021 03:53:32 -0500 Luigi Toscano <ltoscano at redhat.com> wrote ----
 > On Friday, 30 April 2021 00:25:12 CEST Ghanshyam Mann wrote:
 > > Hello Everyone,
 > > 
 > > As per the testing runtime since Victoria [1], we need to move our CI/CD to
 > > Ubuntu Focal 20.04 but it seems there are few jobs still running on Bionic.
 > > As devstack team is planning to drop the Bionic support you need to move
 > > those to Focal otherwise they will start failing. We are planning to merge
 > > the devstack patch by 2nd week of May.
 > > 
 > > - https://review.opendev.org/c/openstack/devstack/+/788754
 > > 
 > > I have not listed all the job but few of them which were failing with '
 > > rtslib-fb-targetctl error' are below:
 > > 
 > > Cinder- cinder-plugin-ceph-tempest-mn-aa
 > > -
 > > https://opendev.org/openstack/cinder/src/commit/7441694cd42111d8f24912f03f6
 > > 69eec72fee7ce/.zuul.yaml#L166
 > 
 > Looking at this job, I suspect the idea was just to use the proper nodeset 
 > with an exiting job, and at the time the default nodeset was the bionic one. I 
 > suspect we may avoid future bumps for this job (and probably others) by 
 > defining a set of nodeset to track the default nodeset used by devstack.
 > 
 > We would just need openstack-single-node-devstackdefault, openstack-two-nodes-
 > devstackdefault.
 > 
 > Unfortunately the nodeset definitions don't support inheritance or aliases, so 
 > that would mean duplicating some definition in the devstack repository, but 
 > - it would be just one additional place to maintain
 > - aliasing could be added to zuul in the future maybe.
 > 
 > What do you think?

Currently, we have nodeset defined in devstack with distro suffix which makes it clear
in term of checking the nodeset definition or so for example: "openstack-single-node-focal"

and then base jobs like 'devstack-minimal' [1] or 'devstack-multinode'[2] keep moving their nodeset
to the latest one as per testing runtime. 

Any derived job from these base jobs does not need to explicitly set the nodeset (unless there are a different
sets of configurations you want) and can rely on the base job's nodeset.  When we modify the base job's ndoeset
we do this as part of a large effort like community-wide goal with proper testing and when all jobs are good
to migrate to new nodeset. So specific jobs using devstack base jobs do not need to add safer guards as such.

For this 'cinder-plugin-ceph-tempest-mn-aa' job which is multinode job but derived from a single node
devstack-plugin-ceph-tempest-py3 can be modified to derived from 'devstack-plugin-ceph-multinode-tempest-py3'
and remove the nodeset from its definition.


[1] https://opendev.org/openstack/devstack/src/commit/166c88b610d2007535367ebe2cf464df9273e6c5/.zuul.yaml#L395
[2] https://opendev.org/openstack/devstack/src/commit/166c88b610d2007535367ebe2cf464df9273e6c5/.zuul.yaml#L570

-gmann

 > 
 > > 
 > > python-cinderclient - python-cinderclient-functional-py36
 > > - https://review.opendev.org/c/openstack/python-cinderclient/+/788834
 > > 
 > > Octavia-
 > > https://opendev.org/openstack/octavia-tempest-plugin/src/branch/master/zuul
 > > .d/jobs.yaml#L182
 > > 
 > > Murani- murano-dashboard-sanity-check
 > > -https://opendev.org/openstack/murano-dashboard/src/commit/b88b32abdffc171e6
 > > 650450273004a41575d2d68/.zuul.yaml#L15
 > 
 > For the record, this is the last legacy job left voting in the gates, but it 
 > is a bit tricky to port, as it tries to run horizon integration tests with a 
 > custom setup. It may be ported by just wrapping the old scripts in the 
 > meantime, but I suspect it's broken anyway now.
 > 
 > 
 > -- 
 > Luigi
 > 
 > 
 > 
 >