February 2021 - openstack-discuss

[barbican][oslo][nova][glance][cinder] cursive library status
by Brian Rosmaita 03 May '21

03 May '21

Hello Barbican team, Apologies for not including barbican in the previous thread on this topic: http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019430… The situation is that cursive is used by Nova, Glance, and Cinder and we'd like to move it out of the 'x' namespace into openstack governance. The question is then what team would oversee it. It seems like a good fit for Oslo, and the Oslo team seems OK with that, but since barbican-core is currently included in cursive-core, it make sense to give the Barbican team first dibs. From the consuming teams' side, I don't think we have a preference as long as it's clear who we need to bother about approvals if a bugfix is posted for review. Thus my ask is that the Barbican team indicate whether they'd like to move cursive to the 'openstack' namespace under their governance, or whether they'd prefer Oslo to oversee the library. Thank you! brian

5 5

[Murano] Please help with murano image creation
by Bujack, Stefan 19 Apr '21

19 Apr '21

Hello, we want to create the murano image for an openstack victoria deployment. We tried to follow this documentation: https://docs.openstack.org/murano/victoria/reference/appendix/articles/imag… But we were not able to successfully create an image. At first we got the following error: murano-agent requires Python '>=3.6' but the running Python is 2.7.17 Then I changed the release to focal and got another error: Unable to locate package python-pip Is anybody so kind to help me with this problem? Many thanks in advance Greets Stefan Bujack root@kolla-2:~# cat /etc/issue Ubuntu 20.04.2 LTS \n \l root@kolla-2:~# export GITDIR=~/git root@kolla-2:~# mkdir -p $GITDIR root@kolla-2:~# cd $GITDIR root@kolla-2:~/git# git clone https://opendev.org/openstack/murano Cloning into 'murano'... remote: Enumerating objects: 34335, done. remote: Counting objects: 100% (34335/34335), done. remote: Compressing objects: 100% (14856/14856), done. remote: Total 34335 (delta 22813), reused 29217 (delta 18268) Receiving objects: 100% (34335/34335), 16.73 MiB | 7.42 MiB/s, done. Resolving deltas: 100% (22813/22813), done. root@kolla-2:~/git# git clone https://opendev.org/openstack/murano-agent Cloning into 'murano-agent'... remote: Enumerating objects: 6696, done. remote: Counting objects: 100% (6696/6696), done. remote: Compressing objects: 100% (2792/2792), done. remote: Total 6696 (delta 3766), reused 6475 (delta 3586) Receiving objects: 100% (6696/6696), 4.98 MiB | 5.46 MiB/s, done. Resolving deltas: 100% (3766/3766), done. root@kolla-2:~/git# pip3 install diskimage-builder Collecting diskimage-builder Downloading diskimage_builder-3.7.0-py3-none-any.whl (608 kB) |████████████████████████████████| 608 kB 4.8 MB/s Requirement already satisfied: stevedore>=1.20.0 in /usr/lib/python3/dist-packages (from diskimage-builder) (1.32.0) Collecting flake8<4.0.0,>=3.6.0 Downloading flake8-3.8.4-py2.py3-none-any.whl (72 kB) |████████████████████████████████| 72 kB 1.6 MB/s Requirement already satisfied: pbr!=2.1.0,>=2.0.0 in /usr/lib/python3/dist-packages (from diskimage-builder) (5.4.5) Collecting networkx>=1.10 Downloading networkx-2.5-py3-none-any.whl (1.6 MB) |████████████████████████████████| 1.6 MB 7.6 MB/s Requirement already satisfied: PyYAML>=3.12 in /usr/lib/python3/dist-packages (from diskimage-builder) (5.3.1) Collecting pycodestyle<2.7.0,>=2.6.0a1 Downloading pycodestyle-2.6.0-py2.py3-none-any.whl (41 kB) |████████████████████████████████| 41 kB 331 kB/s Collecting pyflakes<2.3.0,>=2.2.0 Downloading pyflakes-2.2.0-py2.py3-none-any.whl (66 kB) |████████████████████████████████| 66 kB 5.8 MB/s Collecting mccabe<0.7.0,>=0.6.0 Downloading mccabe-0.6.1-py2.py3-none-any.whl (8.6 kB) Requirement already satisfied: decorator>=4.3.0 in /usr/lib/python3/dist-packages (from networkx>=1.10->diskimage-builder) (4.4.2) Installing collected packages: pycodestyle, pyflakes, mccabe, flake8, networkx, diskimage-builder Successfully installed diskimage-builder-3.7.0 flake8-3.8.4 mccabe-0.6.1 networkx-2.5 pycodestyle-2.6.0 pyflakes-2.2.0 root@kolla-2:~/git# apt install qemu-utils curl tox Reading package lists... Done Building dependency tree Reading state information... Done curl is already the newest version (7.68.0-1ubuntu2.4). curl set to manually installed. The following additional packages will be installed: ibverbs-providers javascript-common libboost-iostreams1.71.0 libboost-thread1.71.0 libibverbs1 libiscsi7 libjs-jquery libjs-sphinxdoc libjs-underscore libnl-route-3-200 librados2 librbd1 librdmacm1 python3-distlib python3-filelock python3-pluggy python3-py python3-toml python3-virtualenv qemu-block-extra sharutils virtualenv Suggested packages: apache2 | lighttpd | httpd subversion python3-pytest debootstrap sharutils-doc bsd-mailx | mailx The following NEW packages will be installed: ibverbs-providers javascript-common libboost-iostreams1.71.0 libboost-thread1.71.0 libibverbs1 libiscsi7 libjs-jquery libjs-sphinxdoc libjs-underscore libnl-route-3-200 librados2 librbd1 librdmacm1 python3-distlib python3-filelock python3-pluggy python3-py python3-toml python3-virtualenv qemu-block-extra qemu-utils sharutils tox virtualenv 0 upgraded, 24 newly installed, 0 to remove and 14 not upgraded. Need to get 8108 kB of archives. After this operation, 37.8 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://de.archive.ubuntu.com/ubuntu focal/main amd64 libnl-route-3-200 amd64 3.4.0-1 [149 kB] Get:2 http://de.archive.ubuntu.com/ubuntu focal/main amd64 libibverbs1 amd64 28.0-1ubuntu1 [53.6 kB] Get:3 http://de.archive.ubuntu.com/ubuntu focal/main amd64 ibverbs-providers amd64 28.0-1ubuntu1 [232 kB] Get:4 http://de.archive.ubuntu.com/ubuntu focal/main amd64 javascript-common all 11 [6066 B] Get:5 http://de.archive.ubuntu.com/ubuntu focal/main amd64 libboost-iostreams1.71.0 amd64 1.71.0-6ubuntu6 [237 kB] Get:6 http://de.archive.ubuntu.com/ubuntu focal/main amd64 libboost-thread1.71.0 amd64 1.71.0-6ubuntu6 [249 kB] Get:7 http://de.archive.ubuntu.com/ubuntu focal/main amd64 librdmacm1 amd64 28.0-1ubuntu1 [64.9 kB] Get:8 http://de.archive.ubuntu.com/ubuntu focal/main amd64 libiscsi7 amd64 1.18.0-2 [63.9 kB] Get:9 http://de.archive.ubuntu.com/ubuntu focal/main amd64 libjs-jquery all 3.3.1~dfsg-3 [329 kB] Get:10 http://de.archive.ubuntu.com/ubuntu focal/main amd64 libjs-underscore all 1.9.1~dfsg-1 [98.6 kB] Get:11 http://de.archive.ubuntu.com/ubuntu focal/main amd64 libjs-sphinxdoc all 1.8.5-7ubuntu3 [97.1 kB] Get:12 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 librados2 amd64 15.2.7-0ubuntu0.20.04.2 [3204 kB] Get:13 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 librbd1 amd64 15.2.7-0ubuntu0.20.04.2 [1609 kB] Get:14 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 python3-distlib all 0.3.0-1 [116 kB] Get:15 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 python3-filelock all 3.0.12-2 [7948 B] Get:16 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 python3-pluggy all 0.13.0-2 [18.4 kB] Get:17 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 python3-py all 1.8.1-1 [65.4 kB] Get:18 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 python3-toml all 0.10.0-3 [14.6 kB] Get:19 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 python3-virtualenv all 20.0.17-1 [63.4 kB] Get:20 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 qemu-block-extra amd64 1:4.2-3ubuntu6.12 [53.8 kB] Get:21 http://de.archive.ubuntu.com/ubuntu focal-updates/main amd64 qemu-utils amd64 1:4.2-3ubuntu6.12 [974 kB] Get:22 http://de.archive.ubuntu.com/ubuntu focal/main amd64 sharutils amd64 1:4.15.2-4build1 [155 kB] Get:23 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 virtualenv all 20.0.17-1 [2132 B] Get:24 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 tox all 3.13.2-2 [244 kB] Fetched 8108 kB in 0s (31.9 MB/s) Selecting previously unselected package libnl-route-3-200:amd64. (Reading database ... 118797 files and directories currently installed.) Preparing to unpack .../00-libnl-route-3-200_3.4.0-1_amd64.deb ... Unpacking libnl-route-3-200:amd64 (3.4.0-1) ... Selecting previously unselected package libibverbs1:amd64. Preparing to unpack .../01-libibverbs1_28.0-1ubuntu1_amd64.deb ... Unpacking libibverbs1:amd64 (28.0-1ubuntu1) ... Selecting previously unselected package ibverbs-providers:amd64. Preparing to unpack .../02-ibverbs-providers_28.0-1ubuntu1_amd64.deb ... Unpacking ibverbs-providers:amd64 (28.0-1ubuntu1) ... Selecting previously unselected package javascript-common. Preparing to unpack .../03-javascript-common_11_all.deb ... Unpacking javascript-common (11) ... Selecting previously unselected package libboost-iostreams1.71.0:amd64. Preparing to unpack .../04-libboost-iostreams1.71.0_1.71.0-6ubuntu6_amd64.deb ... Unpacking libboost-iostreams1.71.0:amd64 (1.71.0-6ubuntu6) ... Selecting previously unselected package libboost-thread1.71.0:amd64. Preparing to unpack .../05-libboost-thread1.71.0_1.71.0-6ubuntu6_amd64.deb ... Unpacking libboost-thread1.71.0:amd64 (1.71.0-6ubuntu6) ... Selecting previously unselected package librdmacm1:amd64. Preparing to unpack .../06-librdmacm1_28.0-1ubuntu1_amd64.deb ... Unpacking librdmacm1:amd64 (28.0-1ubuntu1) ... Selecting previously unselected package libiscsi7:amd64. Preparing to unpack .../07-libiscsi7_1.18.0-2_amd64.deb ... Unpacking libiscsi7:amd64 (1.18.0-2) ... Selecting previously unselected package libjs-jquery. Preparing to unpack .../08-libjs-jquery_3.3.1~dfsg-3_all.deb ... Unpacking libjs-jquery (3.3.1~dfsg-3) ... Selecting previously unselected package libjs-underscore. Preparing to unpack .../09-libjs-underscore_1.9.1~dfsg-1_all.deb ... Unpacking libjs-underscore (1.9.1~dfsg-1) ... Selecting previously unselected package libjs-sphinxdoc. Preparing to unpack .../10-libjs-sphinxdoc_1.8.5-7ubuntu3_all.deb ... Unpacking libjs-sphinxdoc (1.8.5-7ubuntu3) ... Selecting previously unselected package librados2. Preparing to unpack .../11-librados2_15.2.7-0ubuntu0.20.04.2_amd64.deb ... Unpacking librados2 (15.2.7-0ubuntu0.20.04.2) ... Selecting previously unselected package librbd1. Preparing to unpack .../12-librbd1_15.2.7-0ubuntu0.20.04.2_amd64.deb ... Unpacking librbd1 (15.2.7-0ubuntu0.20.04.2) ... Selecting previously unselected package python3-distlib. Preparing to unpack .../13-python3-distlib_0.3.0-1_all.deb ... Unpacking python3-distlib (0.3.0-1) ... Selecting previously unselected package python3-filelock. Preparing to unpack .../14-python3-filelock_3.0.12-2_all.deb ... Unpacking python3-filelock (3.0.12-2) ... Selecting previously unselected package python3-pluggy. Preparing to unpack .../15-python3-pluggy_0.13.0-2_all.deb ... Unpacking python3-pluggy (0.13.0-2) ... Selecting previously unselected package python3-py. Preparing to unpack .../16-python3-py_1.8.1-1_all.deb ... Unpacking python3-py (1.8.1-1) ... Selecting previously unselected package python3-toml. Preparing to unpack .../17-python3-toml_0.10.0-3_all.deb ... Unpacking python3-toml (0.10.0-3) ... Selecting previously unselected package python3-virtualenv. Preparing to unpack .../18-python3-virtualenv_20.0.17-1_all.deb ... Unpacking python3-virtualenv (20.0.17-1) ... Selecting previously unselected package qemu-block-extra:amd64. Preparing to unpack .../19-qemu-block-extra_1%3a4.2-3ubuntu6.12_amd64.deb ... Unpacking qemu-block-extra:amd64 (1:4.2-3ubuntu6.12) ... Selecting previously unselected package qemu-utils. Preparing to unpack .../20-qemu-utils_1%3a4.2-3ubuntu6.12_amd64.deb ... Unpacking qemu-utils (1:4.2-3ubuntu6.12) ... Selecting previously unselected package sharutils. Preparing to unpack .../21-sharutils_1%3a4.15.2-4build1_amd64.deb ... Unpacking sharutils (1:4.15.2-4build1) ... Selecting previously unselected package virtualenv. Preparing to unpack .../22-virtualenv_20.0.17-1_all.deb ... Unpacking virtualenv (20.0.17-1) ... Selecting previously unselected package tox. Preparing to unpack .../23-tox_3.13.2-2_all.deb ... Unpacking tox (3.13.2-2) ... Setting up javascript-common (11) ... Setting up python3-filelock (3.0.12-2) ... Setting up python3-py (1.8.1-1) ... Setting up python3-distlib (0.3.0-1) ... Setting up libboost-iostreams1.71.0:amd64 (1.71.0-6ubuntu6) ... Setting up libnl-route-3-200:amd64 (3.4.0-1) ... Setting up python3-toml (0.10.0-3) ... Setting up python3-pluggy (0.13.0-2) ... Setting up libboost-thread1.71.0:amd64 (1.71.0-6ubuntu6) ... Setting up libjs-jquery (3.3.1~dfsg-3) ... Setting up sharutils (1:4.15.2-4build1) ... Setting up libjs-underscore (1.9.1~dfsg-1) ... Setting up libibverbs1:amd64 (28.0-1ubuntu1) ... Setting up ibverbs-providers:amd64 (28.0-1ubuntu1) ... Setting up python3-virtualenv (20.0.17-1) ... Setting up virtualenv (20.0.17-1) ... Setting up libjs-sphinxdoc (1.8.5-7ubuntu3) ... Setting up librdmacm1:amd64 (28.0-1ubuntu1) ... Setting up librados2 (15.2.7-0ubuntu0.20.04.2) ... Setting up tox (3.13.2-2) ... Setting up librbd1 (15.2.7-0ubuntu0.20.04.2) ... Setting up libiscsi7:amd64 (1.18.0-2) ... Setting up qemu-block-extra:amd64 (1:4.2-3ubuntu6.12) ... Setting up qemu-utils (1:4.2-3ubuntu6.12) ... Processing triggers for libc-bin (2.31-0ubuntu9.2) ... Processing triggers for man-db (2.9.1-1) ... Processing triggers for install-info (6.7.0.dfsg.2-5) ... root@kolla-2:~/git# export ELEMENTS_PATH=$GITDIR/murano/contrib/elements:$GITDIR/murano-agent/contrib/elements root@kolla-2:~/git# disk-image-create vm ubuntu murano-agent -o murano-agent.qcow2 2021-02-18 12:52:34.387 | murano-agent requires Python '>=3.6' but the running Python is 2.7.17 root@kolla-2:~/git# export DIB_RELEASE=focal root@kolla-2:~/git# disk-image-create vm ubuntu murano-agent -o murano-agent.qcow2 2021-02-18 12:55:41.222 | E: Unable to locate package python-pip

2 1

[oslo][security-sig] Please revisit your open vulnerability report
by Jeremy Stanley 12 Apr '21

12 Apr '21

Please help the OpenStack Vulnerability Management Team by taking a look at the following report: keystonemiddleware connections to memcached from neutron-server grow beyond configured values https://launchpad.net/bugs/1883659 Can it be exploited by a nefarious actor, and if so, how? Is it likely to be fixable in all our supported stable branches, respecting stable backport policy? What deployment configurations and options might determine whether a particular installation is susceptible? This is the sort of feedback we depend on to make determinations regarding whether and how to keep the public notified, so they can make informed decisions. Thanks for doing your part to keep our users safe! -- Jeremy Stanley

2 6

[dev][cinder][keystone] Properly consuming system-scope in cinder
by Lance Bragstad 09 Apr '21

09 Apr '21

Hey folks, As I'm sure some of the cinder folks are aware, I'm updating cinder policies to include support for some default personas keystone ships with. Some of those personas use system-scope (e.g., system-reader and system-admin) and I've already proposed a series of patches that describe what those changes look like from a policy perspective [0]. The question now is how we test those changes. To help guide that decision, I worked on three different testing approaches. The first was to continue testing policy using unit tests in cinder with mocked context objects. The second was to use DDT with keystonemiddleware mocked to remove a dependency on keystone. The third also used DDT, but included changes to update NoAuthMiddleware so that it wasn't as opinionated about authentication or authorization. I brought each approach in the cinder meeting this week where we discussed a fourth approach, doing everything in tempest. I summarized all of this in an etherpad [1] Up to yesterday morning, the only approach I hadn't tinkered with manually was tempest. I spent some time today figuring that out, resulting in a patch to cinderlib [2] to enable a protection test job, and cinder_tempest_plugin [3] that adds the plumbing and some example tests. In the process of implementing support for tempest testing, I noticed that service catalogs for system-scoped tokens don't contain cinder endpoints [4]. This is because the cinder endpoint contains endpoint templating in the URL [5], which keystone will substitute with the project ID of the token, if and only if the catalog is built for a project-scoped token. System and domain-scoped tokens do not have a reasonable project ID to use in this case, so the templating is skipped, resulting in a cinder service in the catalog without endpoints [6]. This cascades in the client, specifically tempest's volume client, because it can't find a suitable endpoint for request to the volume service [7]. Initially, my testing approaches were to provide examples for cinder developers to assess the viability of each approach before committing to a protection testing strategy. But, the tempest approach highlighted a larger issue for how we integrate system-scope support into cinder because of the assumption there will always be a project ID in the path (for the majority of the cinder API). I can think of two ways to approach the problem, but I'm hoping others have more. First, we remove project IDs from cinder's API path. This would be similar to how nova (and I assume other services) moved away from project-specific URLs (e.g., /v3/%{project_id}s/volumes would become /v3/volumes). This would obviously require refactoring to remove any assumptions cinder has about project IDs being supplied on the request path. But, this would force all authorization information to come from the context object. Once a deployer removes the endpoint URL templating, the endpoints will populate in the cinder entry of the service catalog. Brian's been helping me understand this and we're unsure if this is something we could even do with a microversion. I think nova did it moving from /v2/ to /v2.0/, which was technically classified as a major bump? This feels like a moon shot. Second, we update cinder's clients, including tempest, to put the project ID on the URL. After we update the clients to append the project ID for cinder endpoints, we should be able to remove the URL templating in keystone, allowing cinder endpoints to appear in system-scoped service catalogs (just like the first approach). Clients can use the base URL from the catalog and append the admin project ID before putting the request on the wire. Even though the request has a project ID in the path, cinder would ignore it for system-specific APIs. This is already true for users with an admin role on a project because cinder will allow you to get volumes in one project if you have a token scoped to another with the admin role [8]. One potential side-effect is that cinder clients would need *a* project ID to build a request, potentially requiring another roundtrip to keystone. Thoughts? [0] https://review.opendev.org/q/project:openstack/cinder+topic:secure-rbac [1] https://etherpad.opendev.org/p/cinder-secure-rbac-protection-testing [2] https://review.opendev.org/c/openstack/cinderlib/+/772770 [3] https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/772915 [4] http://paste.openstack.org/show/802117/ [5] http://paste.openstack.org/show/802097/ [6] https://opendev.org/openstack/keystone/src/commit/c239cc66615b41a0c09e031b3… [7] http://paste.openstack.org/show/802092/ [8] http://paste.openstack.org/show/802118/

4 8

[cinder] Review of tiny patch to add Ceph RBD fast-diff to cinder-backup
by Christian Rohmann 07 Apr '21

07 Apr '21

Hey everyone, I wrote a tiny patch to add the Ceph RDB feature of fast-diff to backups created by cinder-backup: * https://review.opendev.org/c/openstack/cinder/+/766856/ Could someone please take a peek and let me know of this is sufficient to be merged? Thanks and with kind regards, Christian

3 12

[all] Gate resources and performance
by Dan Smith 06 Apr '21

06 Apr '21

Hi all, I have become increasingly concerned with CI performance lately, and have been raising those concerns with various people. Most specifically, I'm worried about our turnaround time or "time to get a result", which has been creeping up lately. Right after the beginning of the year, we had a really bad week where the turnaround time was well over 24 hours. That means if you submit a patch on Tuesday afternoon, you might not get a test result until Thursday. That is, IMHO, a real problem and massively hurts our ability to quickly merge priority fixes as well as just general velocity and morale. If people won't review my code until they see a +1 from Zuul, and that is two days after I submitted it, that's bad. Things have gotten a little better since that week, due in part to getting past a rush of new year submissions (we think) and also due to some job trimming in various places (thanks Neutron!). However, things are still not great. Being in almost the last timezone of the day, the queue is usually so full when I wake up that it's quite often I don't get to see a result before I stop working that day. I would like to ask that projects review their jobs for places where they can cut out redundancy, as well as turn their eyes towards optimizations that can be made. I've been looking at both Nova and Glance jobs and have found some things I think we can do less of. I also wanted to get an idea of who is "using too much" in the way of resources, so I've been working on trying to characterize the weight of the jobs we run for a project, based on the number of worker nodes required to run all the jobs, as well as the wall clock time of how long we tie those up. The results are interesting, I think, and may help us to identify where we see some gains. The idea here is to figure out[1] how many "node hours" it takes to run all the normal jobs on a Nova patch compared to, say, a Neutron one. If the jobs were totally serialized, this is the number of hours a single computer (of the size of a CI worker) would take to do all that work. If the number is 24 hours, that means a single computer could only check *one* patch in a day, running around the clock. I chose the top five projects in terms of usage[2] to report here, as they represent 70% of the total amount of resources consumed. The next five only add up to 13%, so the "top five" seems like a good target group. Here are the results, in order of total consumption: Project % of total Node Hours Nodes ------------------------------------------ 1. TripleO 38% 31 hours 20 2. Neutron 13% 38 hours 32 3. Nova 9% 21 hours 25 4. Kolla 5% 12 hours 18 5. OSA 5% 22 hours 17 What that means is that a single computer (of the size of a CI worker) couldn't even process the jobs required to run on a single patch for Neutron or TripleO in a 24-hour period. Now, we have lots of workers in the gate, of course, but there is also other potential overhead involved in that parallelism, like waiting for nodes to be available for dependent jobs. And of course, we'd like to be able to check more than patch per day. Most projects have smaller gate job sets than check, but assuming they are equivalent, a Neutron patch from submission to commit would undergo 76 hours of testing, not including revisions and not including rechecks. That's an enormous amount of time and resource for a single patch! Now, obviously nobody wants to run fewer tests on patches before they land, and I'm not really suggesting that we take that approach necessarily. However, I think there are probably a lot of places that we can cut down the amount of *work* we do. Some ways to do this are: 1. Evaluate whether or not you need to run all of tempest on two configurations of a devstack on each patch. Maybe having a stripped-down tempest (like just smoke) to run on unique configs, or even specific tests. 2. Revisit your "irrelevant_files" lists to see where you might be able to avoid running heavy jobs on patches that only touch something small. 3. Consider moving some jobs to the experimental queue and run them on-demand for patches that touch particular subsystems or affect particular configurations. 4. Consider some periodic testing for things that maybe don't need to run on every single patch. 5. Re-examine tests that take a long time to run to see if something can be done to make them more efficient. 6. Consider performance improvements in the actual server projects, which also benefits the users. If you're a project that is not in the top ten then your job configuration probably doesn't matter that much, since your usage is dwarfed by the heavy projects. If the heavy projects would consider making changes to decrease their workload, even small gains have the ability to multiply into noticeable improvement. The higher you are on the above list, the more impact a small change will have on the overall picture. Also, thanks to Neutron and TripleO, both of which have already addressed this in some respect, and have other changes on the horizon. Thanks for listening! --Dan 1: https://gist.github.com/kk7ds/5edbfacb2a341bb18df8f8f32d01b37c 2; http://paste.openstack.org/show/C4pwUpdgwUDrpW6V6vnC/

12 36

[ironic] Review Jams
by Julia Kreger 01 Apr '21

01 Apr '21

In the Ironic team's recent mid-cycle call, we discussed the need to return to occasionally having review jams in order to help streamline the review process. In other words, get eyes on a change in parallel and be able to discuss the change. The goal is to help get people on the same page in terms of what and why. Be on hand to answer questions or back-fill context. This is to hopefully avoid the more iterative back and forth nature of code review, which can draw out a long chain of patches. As always, the goal is not perfection, but forward movement especially for complex changes. We've established two time windows that will hopefully not to be too hard for some contributors to make it to. It doesn't need to be everyone, but it would help for at least some people whom actively review or want to actively participate in reviewing, or whom are even interested in a feature to join us for our meeting. I've added an entry on to our wiki page to cover this, with the current agenda and anticipated review jam topic schedule. The tl;dr is we will use meetpad[1] and meet on Mondays at 2 PM UTC and Tuesdays at 6 PM UTC. The hope is to to enable some overlap of reviewers. If people are interested in other times, please bring this up in the weekly meeting or on the mailing list. I'm not sending out calendar invites for this. Yet. :) See everyone next week! -Julia [0]: https://wiki.openstack.org/wiki/Meetings/Ironic#Review_Jams [1]: https://meetpad.opendev.org/ironic

3 2

Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion
by Christian Rohmann 28 Mar '21

28 Mar '21

Hello Openstack-Discuss, I was wondering what the right approach to clean up all resources of a project was in order for it to be deleted? 1) There is ospurge (https://opendev.org/x/ospurge) which works, but seems kind of abandoned looking at the last commits and pending issues (https://bugs.launchpad.net/ospurge) Will there still be any further development of this tool? 2) Then there is the project purge command (https://docs.openstack.org/python-openstackclient/victoria/cli/command-obje…) introduced with the Pike release (https://docs.openstack.org/releasenotes/python-openstackclient/pike.html#re… // https://bugs.launchpad.net/python-openstackclient/+bug/1584596 // https://review.opendev.org/c/openstack/python-openstackclient/+/367673/) While it seems only natural to have the cleanup / purge functionality built into the openstack client, I was wondering .. . a) if all potentially existing resources types are covered and this can fully replace ospurge to allow any project to be cleaned up and deleted? What about i.e. Networks, Containers or objects? b) Also ospurge seems to still have some extended options to target or exclude certain resources by using the following options: > [--resource > {Backups,Snapshots,Volumes,Zones,Images,Stacks,FloatingIPs,RouterInterfaces,Routers,Ports,Networks,SecurityGroups,Servers,LoadBalancers,Receivers,Policies,Clusters,Profiles,Objects,Containers}] > [--exclude-resource > {Backups,Snapshots,Volumes,Zones,Images,Stacks,FloatingIPs,RouterInterfaces,Routers,Ports,Networks,SecurityGroups,Servers,LoadBalancers,Receivers,Policies,Clusters,Profiles,Objects,Containers}] those options are not (yet) available for the "project purge" command of the openstack client. With regards, Christian

5 13

Cannot specify host in availability zone
by Mauricio Tavares 26 Mar '21

26 Mar '21

Easy peasy question: According to https://docs.openstack.org/nova/rocky/admin/availability-zones.html, I can specify the host I want to use by following the format --availability-zone ZONE:HOST So, let's get the hostnames for the compute nodes. [raub@test-hn ~(keystone_admin)]$ openstack compute service list --service nova-compute +----+--------------+-----------------------+------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +----+--------------+-----------------------+------+---------+-------+----------------------------+ | 11 | nova-compute | compute02.example.com | nova | enabled | up | 2021-02-03T17:25:53.000000 | | 12 | nova-compute | compute03.example.com | nova | enabled | up | 2021-02-03T17:25:53.000000 | | 13 | nova-compute | compute01.example.com | nova | enabled | up | 2021-02-03T17:25:52.000000 | +----+--------------+-----------------------+------+---------+-------+----------------------------+ [raub@test-hn ~(keystone_admin)]$ I want to use compute01.example.com, which I can resolve to 10.1.1.11. But, when I try to create server with (running as admin): openstack server create \ --image default_centos_8 \ --flavor m1.small \ --key-name raubkey \ --availability-zone nova:compute01.example.com \ --nic net-id=LONG_BORING-ID \ raub-netest I get the error message (from openstack server show raub-netest|grep fault): 'message': 'No valid host was found. No such host - host: compute01.example.com node: None ' What am I doing wrong here?

3 4

[kolla] Plan to deprecate and finally drop the chrony container
by Radosław Piliszek 24 Mar '21

24 Mar '21

Hello Fellow OpenStackers interested in Kolla's way. The topic should be pretty self-explanatory but let me provide the details and background. We are currently working on the Wallaby release and, since we are cycle-trailing, it is the right moment for us to reflect upon the various cleanup plans we had (and have). One of those is the drop of the chrony container. Chrony serves the time synchronization purpose which is required for healthy operations (I hope I don't need to explain this point further, time sync is essential for most services nowadays). It is still deployed by default by Kolla Ansible. The point is, most default (even minimal ones) host OS installations come with some form of NTP client, be it chrony, ntpd, timesyncd or whatever else there is. :-) This applies also to provisioning solutions like MAAS or Foreman. And Kolla Ansible actually stands on its head to detect and disable those to avoid multiple time sync daemons hell as it may disrupt normal operations (mostly due to having different time sources but also due to different compensation algorithms [or rather just their actual configuration] and the fact that each tool assumes to be the only source of time changes). We seem to have placed a relatively sane precheck to detect this but effective disabling may prove tricky, especially since it is very easy to get it installed at any point. The NTP client is considered a very basic service these days. It also seems that several users known to us do not use the chrony container and instead orchestrate timesync elsewhere. Hence, our current plan is to: 1) Deprecate the chrony container in the Wallaby cycle. - in Kolla Ansible this would mean also warning users that they use it and defaulting to not using it (with docs and a reno); docs would suggest an Ansible way to coordinate timesync - in Kolla docs and a reno 2) Drop the chrony container from both the places I know Kayobe (the "highest-level" member of the Kolla project) is planning to incorporate timesync handling by external Ansible role means so their users should be covered. Please let us know if you have any comments on the plan above. Or generally any suggestions you would like us to hear. Cheers! -yoctozepto

1 1