June 2021 - openstack-discuss - lists.openstack.org

[kayobe][train] kolla_copy_ca_into_containers variable
by Tony Pearce 21 Jun '21

21 Jun '21

I have deployed Train with Kayobe. I'd like to enable SSL using a cert which is signed but NOT by a public CA. This means I need to add the CA cert to the containers. I came across this doc [1] and I wanted to ask / discover when this variable comes into play "kolla_copy_ca_into_containers"? Does this variable work only from Victoria onwards or will it work in Train? Do I require to have a "seed" to build containers, to enable this cert copy into containers? (kayobe overcloud container image build). OR if I do "kayobe overcloud container image pull" will the cert be copied at that point? [1] OpenStack Docs: TLS <https://docs.openstack.org/kolla-ansible/victoria/admin/tls.html> Thanks and regards, Tony Pearce

2 2

Nova shows incorrect VM status when compute is down.
by Ramesh Ramanathan B 21 Jun '21

21 Jun '21

Dear All, One observation we have while using Open Stack Rocky is, when a compute node goes down, the VM status still shows active (the servers running in the compute node that went down). Is this the expected behavior? Any configurations required to get the right status. In the attached image the compute is down, but the VM status still shows active. We are running a data center so it is not practical to run nova reset-state for all the servers. Is there an API to force update Nova to show the correct status? Or any configurations missing that is causing this? Thanks Regards, Ramesh ________________________________ Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version. ________________________________

3 3

[nova] SCS standardized flavor naming
by Kurt Garloff 19 Jun '21

19 Jun '21

Hi, we (SCS) are working on defining a fully open source cloud and container stack as part of the Gaia-X[1] project. The intention is to provide a common well-standardized way to deploy, manage, configure, and operate the needed software. The vision is to have a network of federated clouds that can be used as one, which requires IAM federation and a high level of compatibility and uniformity. Our project is called Sovereign Cloud Stack (SCS)[2]. Obviously, we are using existing open source projects from the OIF, the CNCF and others and are seeking alignment with these communities. Some experts well-known in the OpenStack universe are participating in our effort. On the OpenStack side, we are using OSISM[3] which leverages kolla-ansible. We would like to seek your input and feedback into our attempt of defining a standardized naming scheme for flavors and a list of standard flavors available in all clouds that deliver SCS-compliant IaaS. Find the draft proposal at https://github.com/SovereignCloudStack/Operational-Docs/blob/main/flavor-na… We prefer feedback as github issues and/or PRs. Knowing that the OpenStack community prefers gerrit, we'll of course also incorporate any comment we get via this mailing list into our thinking. We hope you can accept us pasting content from mails into github issues, so we create a track record of the taken decisions. (Please indicate if this is not OK for you and we'll refrain from doing so.) Before you ask why we believe the proposal is useful: We are perfectly aware that it is possible to discover flavor properties; however, in many automation recipes (playbooks, terraform vars etc) we find flavor names encoded and it is one pain point having to adapt them on every cloud that you use. So we want to have some uniformity on this across SCS clouds. (With similar reasoning, expect a image naming and image metadata proposal next.) We are looking for feedback in two directions: (1) If you are aware of similar efforts to standardize flavor naming, please point us to it, so we can seek contact and align. (2) Please look at the proposal itself. When looking into the details how we specify how to optionally(!) encode a number of details into flavor names, please keep in mind that this is indeed optional. We expect most flavor names to be as simple as SCS-4V:8:20 or even SCS-4V:8, even though complicated SCS-8C:32:2x200S-bms-i2-GNa:64-ib [4] is possible for clouds that provide that level of differentiation and want/need to expose this via the flavor name. Of course, input from existing providers of OpenStack infrastructure is particularly valuable. Feedback welcome! [1] https://gaia-x.eu/ [2] https://scs.community/ [3] https://osism.de/ [4] In case you wonder: 8 dedicated cores, 32GiB RAM, 2x200GB SSD disks on bare metal sys, intel Cascade Lake, nVidia GPU with 64 Ampere SMs and InfiniBand. PS: Cc'ing some folks who have contributed to this. -- Kurt Garloff CTO Sovereign Cloud Stack OSB Alliance e.V.

2 3

[all][tc] What's happening in Technical Committee: summary 18th June, 21: Reading: 5 min
by Ghanshyam Mann 19 Jun '21

19 Jun '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Deprecated devstack-gate project[1] * Updated project-team-guide for the meeting channel preference[2] * TC voted the Y release proposed names and forwarded it for the next step of trademark checks. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-06-17-15.00.log.html * We will have next week's meeting on June 24th, Thursday 15:00 UTC[3]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[4] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * One open review for ongoing activities[5]. Migration from Freenode to OFTC ----------------------------------------- * We are in 'Communicate with community' work where all projects need to update all contributor doc etc. Please finish this in your project and mark the progress in etherpad[6]. * I wrote a small blog in OpenStack blog[7]. * All the required work for this migration is tracked in this etherpad[6] 'Y' release naming process ------------------------------- * Y release naming election is closed now. As a last step, the foundation is doing trademark checks on elected ranking. Retiring panko ----------------- * panko project is in process of retirement[8] Test support for TLS default: ---------------------------------- Rico has started a separate email thread over testing with tls-proxy enabled[9], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. Retiring governance's in-active repos ------------------------------------------- The Technical Committee retiring the governance's in-active repos which are not required in current structure[10]. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[11]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [12] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [13] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/795385 [2] https://docs.openstack.org/project-team-guide/open-community.html#public-me… [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4] https://etherpad.opendev.org/p/tc-xena-tracker [5] https://review.opendev.org/q/project:openstack/governance+status:open [6] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc [7] https://www.openstack.org/blog/the-openstack-community-irc-network-moved-to… [8] https://review.opendev.org/c/openstack/governance/+/796408 [9] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [10] https://etherpad.opendev.org/p/governance-repos-cleanup [11] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [12] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [13] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

Allowing custom role to add users
by Derek O keeffe 18 Jun '21

18 Jun '21

Hi all, I have created a role (project_admin) and have given access to anyone with that role to be allowed delete VM's in their group/project. I am trying to allow that user to now add or remove users in the domain but I can't seem to figure it out. I have edited the /etc/keystone/policy.yaml and added role:project_admin to the create user rule. Is this the way I should be doing it? Or does anyone have any advice? Thanks in advance and happy Friday :) Regards,Derek

1 1

packstack stuck at Testing if puppet apply is finished: x.x.x.x_compute.pp
by cloud learner 18 Jun '21

18 Jun '21

Dear Experts, I have installed the single node all in one using victoria, i have to add the new node in current setup, as documented at RDO site, we have to made changes in EXCLUDE_SERVER=controllerip CONFIG_COMPUTE_HOST=newcompute ip, i edited the answer file and run on the controller node but it stuck at Testing if puppet apply is finished: X.X.X.X_compute.pp And it does not show any error, kindly suggest. Thanks

1 0

ImportError: cannot import name greenpool
by Pete Zhang 18 Jun '21

18 Jun '21

Not sure if my previous email went through or not. Just resend it. We hit this error during "glance-manage db_sync": *ImportError: cannot import name greenpool.* Any idea what the root cause is and how to fix it? We have the following rpms installed (thought related). python2-greenlet-0.4.9-1.el7.x86_64.rpm python2-eventlet-0.18.4-2.el7.noarch.rpm python2-gevent-1.1.2-2.el7.x86_64.rpm Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Sleeping for 5 seconds between tries Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Exec try 10/10 Debug: Exec[neutron-db-sync](provider=posix): Executing 'neutron-db-manage upgrade heads' Debug: Executing: 'neutron-db-manage upgrade heads' Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Sleeping for 5 seconds between tries Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Traceback (most recent call last): Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/bin/neutron-db-manage", line 10, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: sys.exit(main()) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 657, in main Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: return_val |= bool(CONF.command.func(config, CONF.command.name <http://conf.command.name/>)) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 179, in do_upgrade Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: run_sanity_checks(config, revision) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 641, in run_sanity_checks Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: script_dir.run_env() Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/script/base.py", line 425, in run_env Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: util.load_python_file(self.dir, 'env.py') Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/util/pyfiles.py", line 81, in load_python_file Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: module = load_module_py(module_id, path) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/util/compat.py", line 141, in load_module_py Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: mod = imp.load_source(module_id, path, fp) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/env.py", line 24, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from neutron.db.migration.models import head # noqa Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/models/head.py", line 28, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from neutron.common import utils Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 35, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: import eventlet Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/eventlet/__init__.py", line 10, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from eventlet import convenience Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/eventlet/convenience.py", line 4, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from eventlet import greenpool Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: ImportError: cannot import name greenpool Error: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: Failed to call refresh: 'neutron-db-manage upgrade heads' returned 1 instead of one of [0] Error: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: 'neutron-db-manage upgrade heads' returned 1 instead of one of [0] Notice: /Stage[main]/Neutron::Deps/Anchor[neutron::dbsync::end]: Dependency Exec[neutron-db-sync] has failures: true -- <https://smart.salesforce.com/sig/peiyong.zhang//us_mb/default/link.html>

3 5

[neutron] Drivers meeting agenda for 18.06.2021
by Slawek Kaplonski 18 Jun '21

18 Jun '21

Hi, Agenda for tomorrow's drivers meeting is at [1]. We have one new RFE to discuss [2] - It's another approach to do OpenFlow based DVR :) We have also one new RFE [3] which I would like You to check and help triaging before we will discuss it in the drivers meeting. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda [2] https://bugs.launchpad.net/neutron/+bug/1931953 [3] https://bugs.launchpad.net/neutron/+bug/1932154 -- Slawek Kaplonski Principal Software Engineer Red Hat

4 7

[victoria][cinder ?] Dell Unity + Iscsi
by Albert Shih 17 Jun '21

17 Jun '21

Hi everyone I've a small openstack configuration with 4 computes nodes, a Dell Unity 480F for the storage. I'm using cinder with iscsi. Everything work when I create a instance. But some instance after few time are not reponsive. When I check on the hypervisor I can see [888240.310461] sd 14:0:0:2: [sdb] tag#120 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [888240.310493] sd 14:0:0:2: [sdb] tag#120 Sense Key : Illegal Request [current] [888240.310502] sd 14:0:0:2: [sdb] tag#120 Add. Sense: Logical unit not supported [888240.310510] sd 14:0:0:2: [sdb] tag#120 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [888240.310519] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0 [888240.311045] sd 14:0:0:2: [sdb] tag#121 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [888240.311050] sd 14:0:0:2: [sdb] tag#121 Sense Key : Illegal Request [current] [888240.311065] sd 14:0:0:2: [sdb] tag#121 Add. Sense: Logical unit not supported [888240.311070] sd 14:0:0:2: [sdb] tag#121 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [888240.311074] blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0 [888240.342482] sd 14:0:0:2: [sdb] tag#70 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [888240.342490] sd 14:0:0:2: [sdb] tag#70 Sense Key : Illegal Request [current] [888240.342496] sd 14:0:0:2: [sdb] tag#70 Add. Sense: Logical unit not supported I check on the hypervisor, no error at all on the ethernet interface. I check on the switch, no error at all on the interface on the switch. No sure but it's seem the problem appear more often when the instance are doing nothing during some time. Every firmware, software on the Unity are uptodate. The 4 computes are exactly same, they run the same version of the nova-compute & OS & firmware on the hardware. Any clue ? Or place to search the problem ? Regards -- Albert SHIH Observatoire de Paris xmpp: jas(a)obspm.fr Heure local/Local time: Tue Jun 1 08:27:42 PM CEST 2021

3 3

[dev] Mass patch filing for skipdist->skipsdist in tox.ini
by Jeremy Stanley 17 Jun '21

17 Jun '21

I just pushed changes for the master branches of 26 projects under topic:tox-skipsdist to correct a frequent typographical error found in many projects' tox.ini files, which seems to get copied around a lot. I'm hoping by getting rid of the mistake everywhere we can stamp out future cargo-cult copies. The skipsdist option is set by many projects to avoid unilaterally building an sdist of the local tree every time tox is invoked, which can sometimes be quite time-consuming. Unfortunately it's all too easy to miss that 's' in the middle of the option name, and since tox ignores options it doesn't recognize, this ends up not having the intended effect. If you would rather keep the current behavior in your project, feel free to amend the change to one which removes the invalid "skipdist" line from your tox.ini instead. If you want to backport this to your stable branches, you can do that as well (it may even save some seconds on average tox-based job runtime); my main concern was more for people copying the mistake around, and it's far more likely they'll be copying from master branches so I didn't bother proposing any backports. -- Jeremy Stanley

1 0

[TripleO] next irc meeting Tuesday 22 June @ 1400 UTC in OFTC #tripleo
by Marios Andreou 17 Jun '21

17 Jun '21

Reminder the next TripleO irc meeting is this coming Tuesday 22 June 1400 UTC in OFTC irc channel #tripleo. agenda: https://wiki.openstack.org/wiki/Meetings/TripleO one-off items: https://etherpad.opendev.org/p/tripleo-meeting-items (feel free to add any tripleo status/ongoing work etc to the etherpad). Our last meeting was on Jun 8th - you can find logs @ http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-06-08-14.… Hope you can make it on Tuesday, regards, marios

1 0

Current market share of OpenStack implementations?
by Linebarger, John 17 Jun '21

17 Jun '21

This is more of a marketing than a technical question, but the online sources seem to be either a few years old or the links have gone stale. What is the collective assessment of the OpenStack Hive Mind about the current worldwide market share of OpenStack implementations, in descending order? And which ones are growing and which ones are leveling off or declining? Candidates would seem to be: 1. TripleO OpenStack 2. Canonical's Charmed OpenStack 3. RedHat OpenStack Platform 4. Mirantis Cloud Platform 5. Packstack 6. Devstack (possibly; but that's just build from source, right?) But does something more comprehensive, more definitive, more current exist with regard to worldwide market share of OpenStack implementations? Or even segmented by continent, geographical region, or country? Thanks! Enjoy! John M. Linebarger, PhD, MBA Principal Member of Technical Staff Sandia National Laboratories (Office) 505-845-8282 (Cell) 505-681-4879 [cid:image002.jpg@01D76285.70750A90]<http://www.sandia.gov/>[AWS Certified Solutions Architect - Professional]<https://www.youracclaim.com/badges/24fe4e43-2f72-4ecc-a11a-783d21dada0f>[AWS Certified Solutions Architect - Associate]<https://www.youracclaim.com/badges/707a5f6f-d919-4daa-bbc4-81b5a779a6cd>[AWS Certified Developer - Associate]<https://www.youracclaim.com/badges/b52ac093-5415-4493-85c3-b77e055211f5>[cid:image003.png@01D76282.D64E1170]<https://www.youracclaim.com/badges/d6e5a453-0e61-4dbe-9716-6af51f364710/pub…>[cid:image005.png@01D76285.70750A90]<https://www.youracclaim.com/badges/035d4967-f77d-476e-915b-1061bb789ec3/pub…>

10 10

Sql query for generating list of router associated with IP and there L3 agent
by Adivya Singh 17 Jun '21

17 Jun '21

Hi, Does anybody know of this sql query , or any reference to Regards Adivya Singh

1 0

ImportError: cannot import name greenpool
by Pete Zhang 17 Jun '21

17 Jun '21

We hit this error during "glance-manage db_sync": *ImportError: cannot import name greenpool.* Any idea what the root cause is and how to fix it? We have the following rpms installed (thought related). python2-greenlet-0.4.9-1.el7.x86_64.rpm python2-eventlet-0.18.4-2.el7.noarch.rpm python2-gevent-1.1.2-2.el7.x86_64.rpm Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Sleeping for 5 seconds between tries Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Exec try 10/10 Debug: Exec[neutron-db-sync](provider=posix): Executing 'neutron-db-manage upgrade heads' Debug: Executing: 'neutron-db-manage upgrade heads' Debug: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Sleeping for 5 seconds between tries Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: Traceback (most recent call last): Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/bin/neutron-db-manage", line 10, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: sys.exit(main()) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 657, in main Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: return_val |= bool(CONF.command.func(config, CONF.command.name)) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 179, in do_upgrade Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: run_sanity_checks(config, revision) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/cli.py", line 641, in run_sanity_checks Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: script_dir.run_env() Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/script/base.py", line 425, in run_env Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: util.load_python_file(self.dir, 'env.py') Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/util/pyfiles.py", line 81, in load_python_file Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: module = load_module_py(module_id, path) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/alembic/util/compat.py", line 141, in load_module_py Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: mod = imp.load_source(module_id, path, fp) Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/alembic_migrations/env.py", line 24, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from neutron.db.migration.models import head # noqa Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/db/migration/models/head.py", line 28, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from neutron.common import utils Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 35, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: import eventlet Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/eventlet/__init__.py", line 10, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from eventlet import convenience Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: File "/usr/lib/python2.7/site-packages/eventlet/convenience.py", line 4, in <module> Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: from eventlet import greenpool Notice: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]/returns: ImportError: cannot import name greenpool Error: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: Failed to call refresh: 'neutron-db-manage upgrade heads' returned 1 instead of one of [0] Error: /Stage[main]/Neutron::Db::Sync/Exec[neutron-db-sync]: 'neutron-db-manage upgrade heads' returned 1 instead of one of [0] Notice: /Stage[main]/Neutron::Deps/Anchor[neutron::dbsync::end]: Dependency Exec[neutron-db-sync] has failures: true -- <https://smart.salesforce.com/sig/peiyong.zhang//us_mb/default/link.html>

1 0

[all][tc] Technical Committee next weekly meeting on June 17th at 1500 UTC
by Ghanshyam Mann 17 Jun '21

17 Jun '21

Hello Everyone, NOTE: TC MEETINGS WILL BE HELD IN #openstack-tc CHANNEL ON OFTC NETWORK (NOT FREENODE) Technical Committee's next weekly meeting is scheduled for June 17th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, June 16th , at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

Customization of nova-scheduler
by Levon Melikbekjan 16 Jun '21

16 Jun '21

Hello Openstack team, is it possible to customize the nova-scheduler via Python? If yes, how? Best regards Levon

8 16

networking-calico-1.4.2-1.el7.centos.noarch.rpm
by Pete Zhang 16 Jun '21

16 Jun '21

Anyone know where I can download this rpm? thx. Pete -- <https://smart.salesforce.com/sig/peiyong.zhang//us_mb/default/link.html>

2 6

Fwd: Regarding RBAC tests
by Soniya Vyas 16 Jun '21

16 Jun '21

Hello everyone, I was just curious about writing RBAC tests, hence while writing them I came across certain analysis and confusions. Analysis:- Whenever an api is called within patrole for its testing, it's the call to its respective service client. Like, let's say we need to test 'create_network:is_default', naturally for expected result we need to call the api first, which would be a call to neutron client's create_network[1]. Question:- But which api's to call for logging resource[2]?For example, let's say we need to write a RBAC test for Create log. As far as I know, Openstack uses python's default logging extension. So the question is which api's to call for the expected result. In Patrole, there are no assertions with expected and actual data. So, How do RBAC-tests test the api? Any help with these confusions would be greatly appreciated. [1] https://review.opendev.org/c/openstack/patrole/+/583340/4/patrole_tempest_p… [2] https://docs.openstack.org/api-ref/network/v2/?expanded=#log-resource Thanks and Regards, Soniya Vyas

2 1

[ironic][ovn] Ironic with OVN as the SDN
by David Ames 16 Jun '21

16 Jun '21

I am looking for a summary of the support or lack thereof for Ironic and OVN. Missing OVN features are explained in [0] and [1]. This bug [2] seems to imply one can run a Neutron OVS DHCP agent alongside OVN. Can I get definitive answers to the following questions: Is it possible to run neutron-dhcp-agent alongside OVN to handle the iPXE boot process? If so, is there documentation anywhere? What is the roadmap/projected timeline for OVN to support Ironic? [0] https://docs.openstack.org/neutron/latest/ovn/gaps.html [1] https://bugzilla.redhat.com/show_bug.cgi?id=1622154 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1620943 Thanks, -- David Ames OpenStack Charm Engineering

3 3

[cinder] Bug deputy report for week of 2021-16-06
by Sofia Enriquez 16 Jun '21

16 Jun '21

Hello, This is a bug report from 2021-09-06 to 2021-16-06. You're welcome to join the Cinder Bug Meeting today. Weekly on Wednesday at 1500 UTC on #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- We only have one bug reported this period: Critical:- High:- Medium: - https://bugs.launchpad.net/cinder/+bug/1931629 'netapp_pool_name_search_pattern doesn't accept regex'. Unassigned. Cheers, Sofia -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[cinder] festival of XS reviews 18 June 2021
by Brian Rosmaita 16 Jun '21

16 Jun '21

Hello Cinder community members, This is a reminder that the most recent edition of the Cinder Festival of XS Reviews will be held at the end of this week on Friday 18 June. who: Everyone! what: The Cinder Festival of XS Reviews when: Friday 18 June 2021 from 1400-1600 UTC where: https://meetpad.opendev.org/cinder-festival-of-reviews This recurring meeting can be placed on your calendar by using this handy ICS file: http://eavesdrop.openstack.org/calendars/cinder-festival-of-reviews.ics See you there! brian

1 0

[cinder] revert volume to snapshot
by Boxiang Zhu 16 Jun '21

16 Jun '21

Hi, There is a restful api[1] to revert volume to snapshot. But the description means we can only use this api to revert volume to its latest snapshot. Are some drivers limited to rolling back only to the latest snapshot? Or just nobody helps to improve the api to revert volume to any snapshots of the volume? [1] https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=rev… Thanks, Boxiang

3 3

[all] CRITICAL: Upcoming changes to the OpenStack Community IRC this weekend
by Ghanshyam Mann 16 Jun '21

16 Jun '21

Greetings contributors & community members! With recent events, the Technical Committee held an emergency meeting today (Wednesday, May 26th, 2021) regarding Freenode IRC and what our decision would be [1]. Earlier in the week, the consensus amongst the TC was to gather more information from the individual projects, and make a decision from there[2]. With #rdo, #ubuntu, and #wikipedia having been hijacked, the consensus amongst the TC and the community members who were able to attend the meeting was to move away from Freenode as soon as possible. The TC agreed that this move away from Freenode needs to be a community-wide move to the same, new IRC network for all projects to avoid splintering of the community. As has been long-planned in the event of a contingency, we will be moving to OFTC. We recognize this is a contentious topic, and ultimately we seek to ensure community continuity before evolution to something beyond IRC, as many have expressed interest in doing via Mailing List discussions. At this point, we had to make a decision to solve the immediate problem in the simplest and most expedient way possible, so this is that announcement. We welcome continued discussion about future alternatives on the other threads. With this in mind, we suggest the following steps. Everyone: ======= 1. Do NOT change any channel topics to represent this change. This is likely to result in the channel being taken over by Freenode and will disrupt communications within our community. 2. Register your nicknames on OFTC [3][4] 3. Be *prepared* to join your channels on OFTC[4]. The OpenStack community channels have already been registered on OFTC and await you. 4. Continue to use Freenode for OpenStack discussions until the bots have been moved and the official cut-over takes place this coming weekend. We anticipate using OFTC starting Monday, May 31st. Projects/Project Leaders: ==================== 1. Projects should work to get a few volunteers to staff their project channels on Freenode, for the near future to help redirect people to OFTC. This should occur via private messages to avoid a ban. 2. Continue to hold project meetings on Freenode until the bots are enabled on OFTC. 3. Update project wikis/documentation with the new IRC network information. We ask that you consider referring to the central contributor guide[5]. 4. The TC is asking that projects take advantage of this time of change to consider moving project meetings from the #openstack-meeting* channels to their project channel. 5. Please avoid discussing the move to OFTC in Freenode channels as this may also trigger a takeover of the channel. We are working on getting our bots over to OFTC, and they will be moved over the weekend. Starting Monday May 31, the bots will be on OFTC. Communication regarding this migration will take place on OFTC[4] in #openstack-dev, and we're working on updating the contributor guide[5] to reflect this migration. Sincerely, The OpenStack TC and community leaders who came together to agree on a path forward. [1]: https://etherpad.opendev.org/p/openstack-irc [2]: https://etherpad.opendev.org/p/feedback-on-freenode [3]: https://www.oftc.net/Services/#register-your-account [4]: https://www.oftc.net/ [5]: https://docs.openstack.org/contributors/common/irc.html

3 6

Re: 3rd party CI failures with devstack 'master' using devstack-gate
by Katari Kumar 15 Jun '21

15 Jun '21

6 8

[nova] GPU VMs using MIG?
by António Paulo 15 Jun '21

15 Jun '21

Hi! Has anyone looked into instancing VMs with NVIDIA's Multi-Instance GPU (MIG) devices [1] without having to rely on vGPUs? Unfortunately, NVIDIA vGPUs lack tracing and profiling support that our users need. I could not find anything specific to MIG in the OpenStack docs but I was wondering if doing PCI passthrough [2] of MIG devices is an option that someone has seen or tested? Maybe some massaging to expose the MIG as a Linux device is required [3]? Cheers, António [1] https://docs.nvidia.com/datacenter/tesla/mig-user-guide/ [2] https://docs.openstack.org/nova/pike/admin/pci-passthrough.html [3] https://docs.nvidia.com/datacenter/tesla/mig-user-guide/#device-nodes

2 2

[neutron][nova][placement] bug 1926693: What would be the reasonable solution ?
by Takashi Kajinami 15 Jun '21

15 Jun '21

Hi All, I've been working on bug 1926693[1], and am lost about the reasonable solutions we expect. Ideally I'd need to bring this topic in the team meeting but because of the timezone gap and complicated background, I'd like to gather some feedback in ml first. [1] https://bugs.launchpad.net/neutron/+bug/1926693 TL;DR Which one(or ones) would be reasonable solutions for this issue ? (1) https://review.opendev.org/c/openstack/neutron/+/763563 (2) https://review.opendev.org/c/openstack/neutron/+/788893 (3) Implement something different The issue I reported in the bug is that there is an inconsistency between nova and neutron about the way to determine a hypervisor name. Currently neutron uses socket.gethostname() (which always returns shortname) to determine a hypervisor name to search the corresponding resource provider. On the other hand, nova uses libvirt's getHostname function (if libvirt driver is used) which returns a canonical name. Canonical name can be shortname or FQDN (*1) and if FQDN is used then neutron and nova never agree. (*1) IMO this is likely to happen in real deployments. For example, TripelO uses FQDN for canonical names. Neutron already provides the resource_provider_defauly_hypervisors option to override a hypervisor name used. However because this option accepts a map between interface and hypervisor, setting this parameter requires very redundant description especially when a compute node has multiple interfaces/bridges. The following example shows how redundant the current requirement is. ~~~ [OVS] resource_provider_bandwidths=br-data1:1024:1024,br-data2:1024:1024,\ br-data3:1024,1024,br-data4,1024:1024 resource_provider_hypervisors=br-data1:compute0.mydomain,br-data2:\ compute0.mydomain,br-data3:compute0.mydomain,br-data4:compute0.mydomain ~~~ I've submitted a change to propose a new single parameter to override the base hypervisor name but this is currently -2ed, mainly because I lacked analysis about the root cause of mismatch when I proposed this. (1) https://review.opendev.org/c/openstack/neutron/+/763563 On the other hand, I submitted a different change to neutron which implements the logic to get a hypervisor name which is fully compatible with libvirt. While this would save users from even overriding hypervisor names, I'm aware that this might break the other virt driver which depends on a different logic to generate a hypervisor name. IMO the patch is still useful considering the libvirt driver would be the most popular option now, but I'm not fully aware of the impact on the other drivers, especially because I don't know which virt driver would support the minimum QoS feature now. (2) https://review.opendev.org/c/openstack/neutron/+/788893/ In the review of (2), Sean mentioned implementing a logic to determine an appropriate resource provider(3) even if there is a mismatch about host name format, but I'm not sure how I would implement that, tbh. My current thought is to merge (1) as a quick solution first, and discuss whether we should merge (2), but I'd like to ask for some feedback about this plan (like we should NOT merge (2)). I'd appreciate your thoughts about this $topic. Thank you, Takashi

5 13

Missing dependency on librte_xxxx when installing openstack-nova-scheduler
by Pete Zhang 15 Jun '21

15 Jun '21

Julie, The original email is too long and requires moderator approval. So I have a new email thread instead. The openstack-vswitch is required (>=11.0.0 < 12.0.0) by openstack-neutron (v15.0.0, from openstack-release-train, the release we chose). I downloaded openstack-vswitch-11.0.0 from https://forge.puppet.com/modules/openstack/vswitch/11.0.0. Where I can download the missing *librte and its dependencies*? I don't think we have a yum-repo for Centos Extra so I might need to have those dependencies downloaded as well. Thanks a lot! Pete -- <https://smart.salesforce.com/sig/peiyong.zhang//us_mb/default/link.html>

3 5

[openstack-helm] No meeting tomorrow
by Gage Hugo 15 Jun '21

15 Jun '21

Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow, the meeting is cancelled. Our next meeting will be June 22nd. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

[Interop] co-chair requirement
by Arkady Kanevsky 14 Jun '21

14 Jun '21

team, after discussing with a few board members I think we should drop the requirement that one of the co-chairs of the Interop WG is from the OIF board. Are you comfortable with this? Thanks, -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456

1 0

[all] Naming Poll for my Y Release Name Vote
by Jay Bryant 14 Jun '21

14 Jun '21

All, As I reviewed the excellent list of names for the 'Y' release I had a hard time choosing. This inspired me to create a poll to get the community's feedback on how you all would like me to vote as a member of the Technical Committee. To cast your vote please visit: https://www.surveymonkey.com/r/RHR3NCY Happy voting! Jay (jungleboyj)

2 1

[TC][All] Election Officiating!
by Kendall Nelson 14 Jun '21

14 Jun '21

Come join the election officials! I setup a meeting for June 29th at 16:00 UTC for those that would like to join and learn about running an election. We can adjust it. I just wanted to get something on the calendar before its too late and we are behind again. The election officials team really could use your help! I will walk through the scripts we use to generate dates and the electorate and answer questions you might have about the README.rst that has the entire process in it. Hope to see you there! - Kendall Nelson (diablo_rojo) [1] https://opendev.org/openstack/election/src/branch/master/README.rst

1 0

Install v version failed on centos 8
by tommy 14 Jun '21

14 Jun '21

Why?? [root@control ~]# packstack --answer-file=./openstack.ini Welcome to the Packstack setup utility The installation log file is available at: /var/tmp/packstack/20210614-203611-y8gez97l/openstack-setup.log Installing: Clean Up [ DONE ] Discovering ip protocol version [ DONE ] root(a)192.168.10.32's <mailto:root@192.168.10.32's> password: root(a)192.168.10.30's <mailto:root@192.168.10.30's> password: root(a)192.168.10.30's <mailto:root@192.168.10.30's> password: root(a)192.168.10.31's <mailto:root@192.168.10.31's> password: root(a)192.168.10.33's <mailto:root@192.168.10.33's> password: Setting up ssh keys [ DONE ] Preparing servers [ DONE ] Pre installing Puppet and discovering hosts' details [ DONE ] Preparing pre-install entries [ DONE ] Setting up CACERT [ DONE ] Preparing AMQP entries [ DONE ] Preparing MariaDB entries [ DONE ] Fixing Keystone LDAP config parameters to be undef if empty[ DONE ] Preparing Keystone entries [ DONE ] Preparing Glance entries [ DONE ] Preparing Nova API entries [ DONE ] Creating ssh keys for Nova migration [ DONE ] Gathering ssh host keys for Nova migration [ DONE ] Preparing Nova Compute entries [ DONE ] Preparing Nova Scheduler entries [ DONE ] Preparing Nova VNC Proxy entries [ DONE ] Preparing OpenStack Network-related Nova entries [ DONE ] Preparing Nova Common entries [ DONE ] Preparing Neutron API entries [ DONE ] Preparing Neutron L3 entries [ DONE ] Preparing Neutron L2 Agent entries [ DONE ] Preparing Neutron DHCP Agent entries [ DONE ] Preparing Neutron Metering Agent entries [ DONE ] Checking if NetworkManager is enabled and running [ DONE ] Preparing OpenStack Client entries [ DONE ] Preparing Horizon entries [ DONE ] Preparing Swift builder entries [ DONE ] Preparing Swift proxy entries [ DONE ] Preparing Swift storage entries [ DONE ] Preparing Gnocchi entries [ DONE ] Preparing Redis entries [ DONE ] Preparing Ceilometer entries [ DONE ] Preparing Aodh entries [ DONE ] Preparing Puppet manifests [ DONE ] Copying Puppet modules and manifests [ DONE ] Applying 192.168.10.30_controller.pp 192.168.10.30_controller.pp: [ DONE ] Applying 192.168.10.32_network.pp Applying 192.168.10.30_network.pp Applying 192.168.10.31_network.pp Applying 192.168.10.33_network.pp 192.168.10.31_network.pp: [ ERROR ] Applying Puppet manifests [ ERROR ] ERROR : Error appeared during Puppet run: 192.168.10.31_network.pp Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Missing title. The title expression resulted in undef (file: /var/tmp/packstack/a201c33193194a599c3654c79945e4a1/modules/ovn/manifests/co ntroller/port.pp, line: 11, column: 13) (file: /var/tmp/packstack/a201c33193194a599c3654c79945e4a1/modules/ovn/manifests/co ntroller.pp, line: 137) on node comps1 You will find full trace in log /var/tmp/packstack/20210614-203611-y8gez97l/manifests/192.168.10.31_network. pp.log Please check log file /var/tmp/packstack/20210614-203611-y8gez97l/openstack-setup.log for more information Additional information: * Parameter CONFIG_NEUTRON_L2_AGENT: You have chosen OVN Neutron backend. Note that this backend does not support the VPNaaS plugin. Geneve will be used as the encapsulation method for tenant networks * Time synchronization installation was skipped. Please note that unsynchronized time on server instances might be problem for some OpenStack components. * File /root/keystonerc_admin has been created on OpenStack client host 192.168.10.30. To use the command line tools you need to source the file. * To access the OpenStack Dashboard browse to http://192.168.10.30/dashboard . Please, find your login credentials stored in the keystonerc_admin in your home directory.

1 1

[neutron] Bug deputy report for week of June 7th
by Brian Haley 14 Jun '21

14 Jun '21

Hi, I was Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1931220 - _ObjectChangeHandler.handle_event failing on port after_create event - https://review.opendev.org/c/openstack/neutron/+/795260 High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1931244 - ovn sriov broken from ussuri onwards - broken by https://review.opendev.org/c/openstack/neutron/+/765874 - https://review.opendev.org/c/openstack/neutron/+/795781 * https://bugs.launchpad.net/neutron/+bug/1931583 - Wrong status of trunk sub-port after setting binding_profile - Kamil is working on it * https://bugs.launchpad.net/neutron/+bug/1931639 - [OVN Octavia Provider] Load Balancer not reachable from some Subnets - Flavio is working on it Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1931098 - With pyroute 0.6.2, eventlet fails in lower-constraints test - https://review.opendev.org/c/openstack/neutron/+/795082 Low bugs -------- * https://bugs.launchpad.net/bugs/1931259 - API "subnet-segmentid-writable" does not include "is_filter" in the "segment_id" field - https://review.opendev.org/c/openstack/neutron-lib/+/795340 Misc bugs --------- * https://bugs.launchpad.net/neutron/+bug/1926045 - Restrictions on FIP binding - Re-opened without supplying reason, asked for more information * https://bugs.launchpad.net/neutron/+bug/1931513/ - neutron bootstrap container failed during deploy openstack victoria - Asked for more information as it looks like an error communicating with SQL server Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1931100 - [rfe] Add RBAC support for BGPVPNs

1 0

Hiding tabs for users with _member_ role
by Derek O keeffe 14 Jun '21

14 Jun '21

Hi all, I have enabled the octavia dashboard and also swift object store. I would like to keep these for the admin or project admin and not display them (tabs) to regular users. Is this possible? thanks in advance. Regards,Derek

1 0

[tripleo] master jobs down
by Wesley Hayutin 14 Jun '21

14 Jun '21

Having some issues w/ infra... https://bugs.launchpad.net/tripleo/+bug/1931821 Details are in the bug.. this will block upstream master jobs.

1 1

[CLOUDKITTY] Missed CloudKitty meeting today
by Rafael Weingärtner 14 Jun '21

14 Jun '21

Hello guys, I would like to apologize for missing the CloudKitty meeting today. I was concentrating on some work, and my alarm for the meeting did not ring. If you need something, just let me know. Sorry for the inconvenience; see you guys at our next meeting. -- Rafael Weingärtner

1 0

Regaring Volume not getting attached
by Adivya Singh 14 Jun '21

14 Jun '21

Hello Team, I am facing a issue, where i am unable to attach a volume to Instances , The third party is using qnap storage, what i am seeing is whenever i am trying to attach, i can see the volume goes from reserved state to attached state and finally goes to receive state and give a error state, regarding HTTP 400, Regards Adivya Singh 9590986094

1 0

[release] Release countdown for week R-16, Jun 14 - Jun 18
by Herve Beraud 14 Jun '21

14 Jun '21

Development Focus ----------------- The Xena-2 milestone will happen next month, on 15 July, 2021. Xena-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/xena/schedule.html for details. General Information ------------------- Please remember that libraries need to be released at least once per milestone period. At milestone 2, the release team will propose releases for any library that has not been otherwise released since milestone 1. Other non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. At milestone-2 we also freeze the contents of the final release. If you have a new deliverable that should be included in the final release, you should make sure it has a deliverable file in: https://opendev.org/openstack/releases/src/branch/master/deliverables/xena You should request a beta release (or intermediary release) for those new deliverables by milestone-2. We understand some may not be quite ready for a full release yet, but if you have something minimally viable to get released it would be good to do a 0.x release to exercise the release tooling for your deliverables. See the MembershipFreeze description for more details: https://releases.openstack.org/xena/schedule.html#x-mf Finally, now may be a good time for teams to check on any stable releases that need to be done for your deliverables. If you have bug fixes that have been backported, but no stable release getting those. If you are unsure what is out there committed but not released, in the openstack/releases repo, running the command "tools/list_stable_unreleased_changes.sh <cycle_name>" gives a nice report. Upcoming Deadlines & Dates -------------------------- Xena-2 Milestone: 15 July, 2021 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[ops] Automatically recover guests from down host
by DHilsbos＠performair.com 14 Jun '21

14 Jun '21

All; What is the most effective means of having the OpenStack cluster restart guests when a hypervisor host fails? We're running OpenStack Victoria, installed manually through packages. My apologies, but my Google foo fails me on this issue; I don't know how to ask it the question. I recognize that OpenStack covers a great many different deployment scenarios, and in many of these this isn't feasible. In our case, images, volumes, and ephemeral storage are all on our Ceph cluster, so all storage is always available to all hypervisor hosts. I also recognize that resource restrictions mean that even in an environment such as mine, not all failed guests may be able to be restarted on new hosts. I'm ok with a dumb best effort, at least for now. Is there something already present in OpenStack which would allow this? Thank you, Dominic L. Hilsbos, MBA Vice President - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

3 2

master jobs down
by Wesley Hayutin 14 Jun '21

14 Jun '21

Greetings, Having some issues w/ infra... https://bugs.launchpad.net/tripleo/+bug/1931821 Details are in the bug.. this will block upstream master jobs.

2 3

[Magnum] Rocky Openstack Magnum Error
by dangerzone ar 13 Jun '21

13 Jun '21

Hi, I'm getting error while trying to verify my magnum installation Here is my keystone_admin details:- *unset OS_SERVICE_TOKEN* * export OS_USERNAME=admin* * export OS_PASSWORD='b6cf5552a9be44e7'* * export OS_REGION_NAME=RegionOne* * export OS_AUTH_URL=http://192.168.0.122:5000/v3 <http://192.168.0.122:5000/v3>* * export PS1='[\u@\h \W(keystone_admin)]\$ '* *export OS_PROJECT_NAME=admin* *export OS_USER_DOMAIN_NAME=Default* *export OS_PROJECT_DOMAIN_NAME=Default* *export OS_IDENTITY_API_VERSION=3* Pls find attached my magnum.conf file and this is error output:- *[root@myosptac ~(keystone_admin)]# magnum --debug service-list* *DEBUG (extension:189) found extension EntryPoint.parse('v1password = swiftclient.authv1:PasswordLoader')* *DEBUG (extension:189) found extension EntryPoint.parse('token_endpoint = openstackclient.api.auth_plugin:TokenEndpoint')* *DEBUG (extension:189) found extension EntryPoint.parse('noauth = cinderclient.contrib.noauth:CinderNoAuthLoader')* *DEBUG (extension:189) found extension EntryPoint.parse('v2token = keystoneauth1.loading._plugins.identity.v2:Token')* *DEBUG (extension:189) found extension EntryPoint.parse('none = keystoneauth1.loading._plugins.noauth:NoAuth')* *DEBUG (extension:189) found extension EntryPoint.parse('*v3oauth1* = keystoneauth1.extras.oauth1._loading:V3OAuth1')* *DEBUG (extension:189) found extension EntryPoint.parse('admin_token = keystoneauth1.loading._plugins.admin_token:AdminToken')* *DEBUG (extension:189) found extension EntryPoint.parse('*v3oidcauthcode* = keystoneauth1.loading._plugins.identity.v3:*OpenIDConnectAuthorie*')* *DEBUG (extension:189) found extension EntryPoint.parse('v2password = keystoneauth1.loading._plugins.identity.v2:Password')* *DEBUG (extension:189) found extension EntryPoint.parse('v3samlpassword = keystoneauth1.extras._saml2._loading:Saml2Password')* *DEBUG (extension:189) found extension EntryPoint.parse('v3password = keystoneauth1.loading._plugins.identity.v3:Password')* *DEBUG (extension:189) found extension EntryPoint.parse('*v3adfspassword* = keystoneauth1.extras._saml2._loading:ADFSPassword')* *DEBUG (extension:189) found extension EntryPoint.parse('v3oidcaccesstoken = keystoneauth1.loading._plugins.identity.v3:OpenIDConnectAcce* *DEBUG (extension:189) found extension EntryPoint.parse('*v3oidcpassword* = keystoneauth1.loading._plugins.identity.v3:*OpenIDConnectPasswor *DEBUG (extension:189) found extension EntryPoint.parse('v3kerberos = keystoneauth1.extras.kerberos._loading:Kerberos')* *DEBUG (extension:189) found extension EntryPoint.parse('token = keystoneauth1.loading._plugins.identity.generic:Token')* *DEBUG (extension:189) found extension EntryPoint.parse('v3oidcclientcredentials = keystoneauth1.loading._plugins.identity.v3:OpenIDConneredentials')* *DEBUG (extension:189) found extension EntryPoint.parse('v3tokenlessauth = keystoneauth1.loading._plugins.identity.v3:TokenlessAuth')* *DEBUG (extension:189) found extension EntryPoint.parse('v3token = keystoneauth1.loading._plugins.identity.v3:Token')* *DEBUG (extension:189) found extension EntryPoint.parse('v3totp = keystoneauth1.loading._plugins.identity.v3:TOTP')* *DEBUG (extension:189) found extension EntryPoint.parse('* v3applicationcredential* = keystoneauth1.loading._plugins.identity.v3:* Applicationl*')* *DEBUG (extension:189) found extension EntryPoint.parse('password = keystoneauth1.loading._plugins.identity.generic:Password')* *DEBUG (extension:189) found extension EntryPoint.parse('v3fedkerb = keystoneauth1.extras.kerberos._loading:*MappedKerberos*')* *DEBUG (extension:189) found extension EntryPoint.parse('gnocchi-basic = * gnocchiclient.auth*:GnocchiBasicLoader')* *DEBUG (extension:189) found extension EntryPoint.parse('gnocchi-noauth = * gnocchiclient.auth*:GnocchiNoAuthLoader')* *DEBUG (extension:189) found extension EntryPoint.parse('aodh-noauth = aodhclient.noauth:AodhNoAuthLoader')* *DEBUG (session:448) REQ: curl -g -i -X GET http://192.168.0.122:5000/v3 <http://192.168.0.122:5000/v3> -H "Accept: application/json" -H "User-Agent: magnum *keystoneaut* python-requests/2.19.1 CPython/2.7.5"* *DEBUG (connectionpool:207) Starting new HTTP connection (1): 192.168.0.122* *DEBUG (connectionpool:395) http://192.168.0.122:5000 <http://192.168.0.122:5000> "GET /v3 HTTP/1.1" 200 196* *DEBUG (session:479) RESP: [200] Connection: Keep-Alive Content-Encoding: gzip Content-Length: 196 Content-Type: application/json Date: Sn 2021 18:28:25 GMT Keep-Alive: timeout=15, max=100 Server: Apache/2.4.6 (CentOS) Vary: X-Auth-Token,Accept-Encoding x-openstack-requeste8a01587-a1ea-4b9e-9960-b7f1c64cebd6* *DEBUG (session:511) RESP BODY: {"version": {"status": "stable", "updated": "2018-10-15T00:00:00Z", "media-types": [{"base": "applicationtype": "application/vnd.openstack.identity-v3+json"}], "id": "v3.11", "links": [{"href": "http://192.168.0.122:5000/v3/ <http://192.168.0.122:5000/v3/>", "rel": "self"}* *DEBUG (session:853) GET call to http://192.168.0.122:5000/v3 <http://192.168.0.122:5000/v3> used request id req-e8a01587-a1ea-4b9e-9960-b7f1c64cebd6* *DEBUG (base:176) Making authentication request to http://192.168.0.122:5000/v3/auth/tokens <http://192.168.0.122:5000/v3/auth/tokens>* *DEBUG (connectionpool:395) http://192.168.0.122:5000 <http://192.168.0.122:5000> "POST /v3/auth/tokens HTTP/1.1" 201 10983* *DEBUG (base:181) {"token": {"is_domain": false, "methods": ["password"], "roles": [{"id": "ff6467cba06d4325b5dc26ffec6d67ea", "name": "h_owner"}, {"id": "9fe2ff9ee4384b1894a90878d3e92bab", "name": "_member_"}, {"id": "37dc1fb164684e77bba1df8ced2faa9f", "name": "reader"}, a78bcad80fe4ae897adf16e5b2b265a", "name": "member"}, {"id": "3c2996b04b5c46189c6d618f69b4aa8b", "name": "admin"}], "expires_at": "2021-08:25.000000Z", "project": {"domain": {"id": "default", "name": "Default"}, "id": "d430c3698e8f4d7d874ea7e708ac17d7", "name": "admin"}, " [{"endpoints": [{"url": "http://192.168.0.122:8000/v1 <http://192.168.0.122:8000/v1>", "interface": "admin", "region": "RegionOne", "region_id": "RegionOne", "id": "14b4e2798b31fa00eaaa823"}, {"url": "http://192.168.0.122:8000/v1 <http://192.168.0.122:8000/v1>", "interface": "internal", "region": "RegionOne", "region_id": "RegionOn "9e33b93ca2f24206983d6f6b2e58d2f9"}, {"url": "http://192.168.0.122:8000/v1 <http://192.168.0.122:8000/v1>", "interface": "public", "region": "RegionOne", "region_id":ne", "id": "fc5eadc7dbfd492299f9b9e9585c8201"}], "type": "cloudformation", "id": "001cd752638e46eb8fbc96c9181a9efc", "name": "heat-cfn"}ints": [{"url": "http://192.168.0.122:8080/v1/AUTH_d430c3698e8f4d7d874ea7e708ac17d7 <http://192.168.0.122:8080/v1/AUTH_d430c3698e8f4d7d874ea7e708ac17d7>", "interface": "admin", "region": "RegionOne", "regiRegionOne", "id": "0030669365ad497d8eefd13a99850c68"}, {"url": "http://192.168.0.122:8080/v1/AUTH_d430c3698e8f4d7d874ea7e708ac17d7 <http://192.168.0.122:8080/v1/AUTH_d430c3698e8f4d7d874ea7e708ac17d7>", "in "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "53e2d455b96c4fc0951d98d5ce7790cf"}, {"url": "http://192.168.0.122:8TH_d430c3698e8f4d7d874ea7e708ac17d7", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "9f037da9221f43a1a3017d5"}], "type": "object-store", "id": "0610a7bebc1642f398e6de9f25b582e8", "name": "swift"}, {"endpoints": [{"url": "http://192.168.0.12 <http://192.168.0.12>"interface": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "553632abff5a4380911acb11a5e16b74"}, {"url": "http://1922:9696 <http://1922:9696>", "interface": "admin", "region": "RegionOne", "region_id": "RegionOne", "id": "6fb59f7c44d44ceaa0da2dfe0a4e4935"}, {"url": "http8.0.122:9696", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "c234ac3128294662b2a3c5b445b81d28"}], "typerk", "id": "068e962709db4d4d8904e740824503c8", "name": "neutron"}, {"endpoints": [{"url": "http://192.168.0.122:8004/v1/d430c3698e8f4d7d8ac17d7 <http://192.168.0.122:8004/v1/d430c3698e8f4d7d8ac17d7>", "interface": "admin", "region": "RegionOne", "region_id": "RegionOne", "id": "2ff81a5c643546b49900256cc12aa739"}, {"url": "htt68.0.122:8004/v1/d430c3698e8f4d7d874ea7e708ac17d7", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "8ffb8f2bf17cfc24206ac99"}, {"url": "http://192.168.0.122:8004/v1/d430c3698e8f4d7d874ea7e708ac17d7 <http://192.168.0.122:8004/v1/d430c3698e8f4d7d874ea7e708ac17d7>", "interface": "internal", "region": "Regioegion_id": "RegionOne", "id": "925912fbfcc14e8eac063aae807021c2"}], "type": "orchestration", "id": "08c8970db6ca4c4c9592070b78002ea3", "eat"}, {"endpoints": [{"url": "http://192.168.0.122:5000/v3 <http://192.168.0.122:5000/v3>", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "i49a40c7542fbb6f031d8eb3d66ac"}, {"url": "http://192.168.0.122:5000/v3 <http://192.168.0.122:5000/v3>", "interface": "internal", "region": "RegionOne", "region_id": "Re "id": "8b49647ee89246bba936e6717a6915f9"}, {"url": "http://192.168.0.122:35357/v3 <http://192.168.0.122:35357/v3>", "interface": "admin", "region": "RegionOne", "regioegionOne", "id": "e80547d366fa403a87af0a04926d5fe8"}], "type": "identity", "id": "0c65ebd11cb549008dd49fe960623ed9", "name": "keystone"}ints": [{"url": "http://192.168.0.122:8776/v3/d430c3698e8f4d7d874ea7e708ac17d7 <http://192.168.0.122:8776/v3/d430c3698e8f4d7d874ea7e708ac17d7>", "interface": "internal", "region": "RegionOne", "regiongionOne", "id": "2ad2414e6c9a4bc78fa83fa53a1fbf4e"}, {"url": "http://192.168.0.122:8776/v3/d430c3698e8f4d7d874ea7e708ac17d7 <http://192.168.0.122:8776/v3/d430c3698e8f4d7d874ea7e708ac17d7>", "interfacec", "region": "RegionOne", "region_id": "RegionOne", "id": "2b70431e0c0049a88c7d0bf76d04a033"}, {"url": "http://192.168.0.122:8776/v3/d4f4d7d874ea7e708ac17d7 <http://192.168.0.122:8776/v3/d4f4d7d874ea7e708ac17d7>", "interface": "admin", "region": "RegionOne", "region_id": "RegionOne", "id": "64e454f408c24549aeb1e720295992ce"}: "volumev3", "id": "1b07bd83eeb4460d9b8330794ba33850", "name": "cinderv3"}, {"endpoints": [{"url": "http://192.168.0.122:9890/ <http://192.168.0.122:9890/>", "interdmin", "region": "RegionOne", "region_id": "RegionOne", "id": "0473f73ee7e44b918b08736636570df8"}, {"url": "http://192.168.0.122:9890/ <http://192.168.0.122:9890/>",ce": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "89af54ac6f1e4f109324b8c4e9b8bca5"}, {"url": "http://192.168.0.1 <http://192.168.0.1>, "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "d8deb8aa66264ff292b206424ebe735a"}], "type": "nfv-orche, "id": "22d0c99d2b9147c992c430bc01955b59", "name": "tacker"}, {"endpoints": [{"url": "http://192.168.0.122:8776/v2/d430c3698e8f4d7d874e7d7 <http://192.168.0.122:8776/v2/d430c3698e8f4d7d874e7d7>", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "11cee7c429b24730abff08cbcc99d4b7"}, {"url": "http:/0.122:8776/v2/d430c3698e8f4d7d874ea7e708ac17d7", "interface": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "caf5b4b874a44321adb7db9"}, {"url": "http://192.168.0.122:8776/v2/d430c3698e8f4d7d874ea7e708ac17d7 <http://192.168.0.122:8776/v2/d430c3698e8f4d7d874ea7e708ac17d7>", "interface": "admin", "region": "RegionOnen_id": "RegionOne", "id": "eab5457ca880490b8cbe357ef870fcaa"}], "type": "volumev2", "id": "488472e3277d4e568a169246b899d223", "name": "c, {"endpoints": [{"url": "http://192.168.0.122:8776/v1/d430c3698e8f4d7d874ea7e708ac17d7 <http://192.168.0.122:8776/v1/d430c3698e8f4d7d874ea7e708ac17d7>", "interface": "admin", "region": "RegionOne", "": "RegionOne", "id": "24e810d702ff47c6880b0c5231aa9f1a"}, {"url": "http://192.168.0.122:8776/v1/d430c3698e8f4d7d874ea7e708ac17d7 <http://192.168.0.122:8776/v1/d430c3698e8f4d7d874ea7e708ac17d7>", "int"internal", "region": "RegionOne", "region_id": "RegionOne", "id": "3d887ec2f90a48d9bb2cf6c71264b6bc"}, {"url": "http://192.168.0.122:870c3698e8f4d7d874ea7e708ac17d7", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "532bf115ce0741b0afe052b3b], "type": "volume", "id": "4941273cd7734cdcb01eb6423dd3c2d9", "name": "cinder"}, {"endpoints": [{"url": "http://192.168.0.122:9311 <http://192.168.0.122:9311>", "i: "public", "region": "RegionOne", "region_id": "RegionOne", "id": "9ccc3fbd5cb240ae972aa26b3e7a0082"}, {"url": "http://192.168.0.122:93erface": "admin", "region": "RegionOne", "region_id": "RegionOne", "id": "e3bc06b47fad453c8880f80950d3978c"}, {"url": "http://192.168.0 <http://192.168.0>., "interface": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "e9f9e7f2a5814d2cbe52b126288bd399"}], "type": "key-mand": "4d342a315084482b86f616299eebfd3a", "name": "barbican"}, {"endpoints": [{"url": "http://192.168.0.122:8774/v2.1/d430c3698e8f4d7d874e7d7 <http://192.168.0.122:8774/v2.1/d430c3698e8f4d7d874e7d7>", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "01b84df8a50f47df96c66dca731c8999"}, {"url": "http:/0.122:8774/v2.1/d430c3698e8f4d7d874ea7e708ac17d7", "interface": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "2c339fca57d65acce177bcd"}, {"url": "http://192.168.0.122:8774/v2.1/d430c3698e8f4d7d874ea7e708ac17d7 <http://192.168.0.122:8774/v2.1/d430c3698e8f4d7d874ea7e708ac17d7>", "interface": "admin", "region": "Regioegion_id": "RegionOne", "id": "898b9568e1bc46309870bfb1a432995e"}], "type": "compute", "id": "83e61d9ee67e4c4b9da5f2aeb342ac33", "name": {"endpoints": [{"url": "http://192.168.0.122:8042 <http://192.168.0.122:8042>", "interface": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "3da4ffea975d229f4208cab"}, {"url": "http://192.168.0.122:8042 <http://192.168.0.122:8042>", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "iee5bb6a049ab944e828c66af861c"}, {"url": "http://192.168.0.122:8042 <http://192.168.0.122:8042>", "interface": "admin", "region": "RegionOne", "region_id": "RegionOn "8745e0169c8c498fac9033e301cfeb3e"}], "type": "alarming", "id": "989e7012ea604c7794455a197fdedf6b", "name": "aodh"}, {"endpoints": [{"up://192.168.0.122:8778/placement <http://192.168.0.122:8778/placement>", "interface": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "9b81b11df55d4651bffe0af"}, {"url": "http://192.168.0.122:8778/placement <http://192.168.0.122:8778/placement>", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "c1940aebbed105332160986"}, {"url": "http://192.168.0.122:8778/placement <http://192.168.0.122:8778/placement>", "interface": "admin", "region": "RegionOne", "region_id": "Region": "f6fc036a48bf47f1ba034d5c46a3257d"}], "type": "placement", "id": "b975d296f13141539055f90971b870a7", "name": "placement"}, {"endpointl": "http://192.168.0.122:9511/v1 <http://192.168.0.122:9511/v1>", "interface": "admin", "region": "RegionOne", "region_id": "RegionOne", "id": "3d83664ffd1e4fafb605adb"}, {"url": "http://192.168.0.122:9511/v1 <http://192.168.0.122:9511/v1>", "interface": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "7f06217f1297822167470ca"}, {"url": "http://192.168.0.122:9511/v1 <http://192.168.0.122:9511/v1>", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "71d466a953e3727aea930f2"}], "type": "container-infra", "id": "bb891040e2f24a4f86aa596f780a668e", "name": "magnum"}, {"endpoints": [{"url//192.168.0.122:9292 <http://192.168.0.122:9292>", "interface": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "0355aeb6a9bf41e19c33adb5d207c40b"} "http://192.168.0.122:9292 <http://192.168.0.122:9292>", "interface": "admin", "region": "RegionOne", "region_id": "RegionOne", "id": "3e894b75a3494f2792e8c479493c"url": "http://192.168.0.122:9292 <http://192.168.0.122:9292>", "interface": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "5baff29672d44f308eb33f4"}], "type": "image", "id": "da951f6f026b46918337129a67331f0d", "name": "glance"}, {"endpoints": [{"url": "http://192.168.0.122:8777face": "public", "region": "RegionOne", "region_id": "RegionOne", "id": "753f5b41610c4de3b7ea283dcecab32a"}, {"url": "http://192.168.0.1 <http://192.168.0.1> "interface": "internal", "region": "RegionOne", "region_id": "RegionOne", "id": "b5c21dfe1d1e496093c1bfb16d9d5161"}, {"url": "http://1922:8777 <http://1922:8777>", "interface": "admin", "region": "RegionOne", "region_id": "RegionOne", "id": "cfc236dbffd846cb94f3add4cfbb5448"}], "type": "me"id": "e378bc2a0adc451e905a35ffdc59cf35", "name": "ceilometer"}, {"endpoints": [{"url": "http://192.168.0.122:8041 <http://192.168.0.122:8041>", "interface": "adminn": "RegionOne", "region_id": "RegionOne", "id": "3ea207d844b44d77806a359bf49b3b46"}, {"url": "http://192.168.0.122:8041 <http://192.168.0.122:8041>", "interface": ", "region": "RegionOne", "region_id": "RegionOne", "id": "78d7ac10e85745148af1f01f2942ed83"}, {"url": "http://192.168.0.122:8041 <http://192.168.0.122:8041>", "int"public", "region": "RegionOne", "region_id": "RegionOne", "id": "f15500eca821457c994ce8d8c4c859f6"}], "type": "metric", "id": "ebd1ffd8161a292ff66140d", "name": "gnocchi"}], "user": {"domain": {"id": "default", "name": "Default"}, "password_expires_at": null, "name": "ad": "9c91d3f3e3c943f09b57fe70889894b8"}, "audit_ids": ["vOQFHBd6QJCOBEAz_1Y7jA"], "issued_at": "2021-06-12T18:28:25.000000Z"}}* *DEBUG (session:448) REQ: curl -g -i -X GET http://192.168.0.122:9511/v1/mservices <http://192.168.0.122:9511/v1/mservices> -H "Accept: application/json" -H "Content-Type: applicn" -H "OpenStack-API-Version: container-infra latest" -H "User-Agent: None" -H "X-Auth-Token: {SHA1}1f364e2302d9282710c8314355929963d3b4* *DEBUG (connectionpool:207) Starting new HTTP connection (1): 192.168.0.122* *DEBUG (connectionpool:395) http://192.168.0.122:9511 <http://192.168.0.122:9511> "GET /v1/mservices HTTP/1.1" 503 218* *DEBUG (session:479) RESP: [503] Content-Length: 218 Content-Type: application/json Date: Sat, 12 Jun 2021 18:28:26 GMT Server: Werkzeug/thon/2.7.5 x-openstack-request-id: req-d9894aff-b197-4a36-b9b9-f752d38f29d3* *DEBUG (session:511) RESP BODY: {"message": "The server is currently unavailable. Please try again at a later time.<br /><br />\nThe Keysice is temporarily unavailable.\n\n", "code": "503 Service Unavailable", "title": "Service Unavailable"}* *DEBUG (session:844) GET call to container-infra for http://192.168.0.122:9511/v1/mservices <http://192.168.0.122:9511/v1/mservices> used request id req-d9894aff-b197-4a36-b9b9-fd3* *DEBUG (shell:643) 'errors'* *Traceback (most recent call last):* * File "/usr/lib/python2.7/site-packages/magnumclient/shell.py", line 640, in main* * OpenStackMagnumShell().main(map(encodeutils.safe_decode, sys.argv[1:]))* * File "/usr/lib/python2.7/site-packages/magnumclient/shell.py", line 552, in main* * args.func(self.cs, args)* * File "/usr/lib/python2.7/site-packages/magnumclient/v1/mservices_shell.py", line 22, in do_service_list* * mservices = cs.mservices.list()* * File "/usr/lib/python2.7/site-packages/magnumclient/v1/mservices.py", line 68, in list* * return self._list(self._path(path), "mservices")* * File "/usr/lib/python2.7/site-packages/magnumclient/common/base.py", line 121, in _list* * resp, body = self.api.json_request('GET', url)* * File "/usr/lib/python2.7/site-packages/magnumclient/common/httpclient.py", line 368, in json_request* * resp = self._http_request(url, method, **kwargs)* * File "/usr/lib/python2.7/site-packages/magnumclient/common/httpclient.py", line 349, in _http_request* * error_json = _extract_error_json(resp.content)* * File "/usr/lib/python2.7/site-packages/magnumclient/common/httpclient.py", line 55, in _extract_error_json* * error_body = body_json['errors'][0]* *KeyError: 'errors'* *ERROR: 'errors'* I'm running rocky openstack, install magnum and not use barbican. Appreciate if someone could advise magnum.conf or anything to resolve the above error. Please help. Thank you.

1 0

[all][tc] What's happening in Technical Committee: summary 11th June, 21: Reading: 5 min
by Ghanshyam Mann 12 Jun '21

12 Jun '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Added 'vulnerability:managed' tag for os-brick[1]. * Replaced the ATC (Active Technical Contributors) terminology with AC (Active Contributors). ** TC resolution is also merged [2]. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-06-10-15.00.log.html * We will have next week's meeting on June 17th, Thursday 15:00 UTC[3]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[4] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * One open review for ongoing activities[5]. Migration from Freenode to OFTC ----------------------------------------- * All the required work for this migration is tracked in this etherpad[6] * Today we are changing the Freenode channels Topic about this migration. * We are in 'Communicate with community' work where all projects need to update all contributor doc etc. Please finish this in your project and mark the progress in etherpad[6]. * This migration has been published in Open Infra newsletter OpenStack's news also[8]. 'Y' release naming process ------------------------------- * Y release naming nomination is closed now. I have started the CIVS poll with TC members as the electorate. Retiring devstack-gate -------------------------- * As communicated over email, we are finally retiring the devstack-gate. It will keep supporting the stable branch until stable/wallaby goes to EOL[9]. The governance patch for officially retirement is also up[10] Updating project-team-guide for the meeting channel preference ---------------------------------------------------------------------------- * As communicated over email during migration to OFTC, we are adding the meeting channel preference to project own channel in project team guide[11] Test support for TLS default: ---------------------------------- Rico has started a separate email thread over testing with tls-proxy enabled[12], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [15] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/794680 [2] https://review.opendev.org/c/openstack/governance/+/794366 [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4] https://etherpad.opendev.org/p/tc-xena-tracker [5] https://review.opendev.org/q/project:openstack/governance+status:open [6] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc [7] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022780.html [8] https://superuser.openstack.org/articles/inside-open-infrastructure-the-lat… [9] https://review.opendev.org/q/topic:%22deprecate-devstack-gate%22+(status:op… [10] https://review.opendev.org/c/openstack/governance/+/795385 [11] https://review.opendev.org/c/openstack/project-team-guide/+/794839 [12] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [15] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

kayobe deploying Openstack - Train or Victoria
by Tony Pearce 11 Jun '21

11 Jun '21

I am running into issues with deploying Openstack using Kayobe. Is this list group the best place to raise? If not, my apologies - please could you share where I need to go? 1. kayobe hangs during deployment, does not time out, does not error out when has previously been successful and without configuration changes. 2. deployment fails due to breaking the network relating to the bridge. Also changes login password which locks out of console. Details: 1. Environment deployment: Train all-in-one host: centos7 Ansible control host: Ubuntu 18 With the first issue, I've seen this multiple times but have not been able to find the root cause. I searched online and came across other ansible users that state their playbooks were hanging and were able to resolve by clearing cache. I've tried clearing out ~/.ansible/* and /tmp/* on the control host. Also tried doing the same on the all-in-one host without success. This issue came about after doing a full destroy of the environment and then redeploying, making a minor config change and then redeploying. 2. Environment deployment: Victoria all-in-one host: centos8 Ansible control host: Ubuntu 20 Because I couldnt resolve the issue above and centos 8.4 is available, I decided to try and go to centos 8 and deploy Victoria. I hit 2 issues: 1. I am unable to login with "kayobe_ansible_user" using after "kayobe overcloud host configure" with "wrong password" message. Resetting the password resolves but the password seems changed again with a host configure. 2. deployment fails when "TASK [openvswitch : Ensuring OVS bridge is properly setup]" Looking at the ovs container, it's unable to add the physical interface to the bridge bond0 interface, complaining that the device is busy or is already up. I saw some log messages relating to ipv6 so I tried disabling ipv6 and redeploying but the same issue. I then rebuilt the host again and opted not to use a bond0 interface however the same loss of network occurs. If I log into the openvswitch_db container then there are CLI commands where I can delete the bridge to restore the network. So at this point, after turning off ipv6 again and running without bond0 bond, I tried another deploy wile tailing `/var/log/kolla/openvswitch/ovs-vswitchd.log` and now I do not see any errors but the network is lost to the host and the script fails to finish deployment. I've attached the logs that appear at the point the network dies: https://pasteboard.co/K65qwzR.png Are these known issues and does anyone have any information as to how I can work through or around them? Regards, Tony Pearce

2 1

[nova][gate] openstack-tox-pep8 job broken
by melanie witt 11 Jun '21

11 Jun '21

Hi all, The openstack-tox-pep8 job is currently failing with the following error: > nova/crypto.py:39:1: error: Library stubs not installed for "paramiko" (or incompatible with Python 3.8) > nova/crypto.py:39:1: note: Hint: "python3 -m pip install types-paramiko" > nova/crypto.py:39:1: note: (or run "mypy --install-types" to install all missing stub packages) > nova/crypto.py:39:1: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports > Found 1 error in 1 file (checked 23 source files) > ERROR: InvocationError for command /usr/bin/bash tools/mypywrap.sh (exited with code 1) Please hold your rechecks until the fix merges: https://review.opendev.org/c/openstack/nova/+/795533 Cheers, -melanie

2 1

How to flush UE context from USRP B210
by Kumar Prasad, Vikash 11 Jun '21

11 Jun '21

Dear All, I am using USRP B210 for my eNB. USRP B210 is storing the context of previous connected UEs, I want to flush the UE context from USRP, could anyone suggest me how I can flush this previously connected UEs contexts? Thanks Vikash kumar prasad

2 1

Domain tab
by Derek O keeffe 11 Jun '21

11 Jun '21

Hi all, I have two domains in my setup (default & ldap) If I log in as default admin I cannot see a domain tab in the identity dropdown (all cli works fine). I'm sure I had it there before and think it could be a setting in /etc/opoenstack-dashboard/local_settings.py Any pointers as to what I might be missing? Thanks in advance. Regards,Derek

2 3

PTO - Friday 11
by Herve Beraud 10 Jun '21

10 Jun '21

Hello, I'm on PTO tomorrow (June 11). See you on Monday -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[TripleO] Proposing ysandeep for tripleo-ci core
by Marios Andreou 10 Jun '21

10 Jun '21

Hello all Having discussed this with some members of the tripleo ci team (weshay, sshnaidm), we would like to propose Sandeep Yadav (irc: ysandeep) for core on the tripleo-ci repos (tripleo-ci, tripleo-quickstart and tripleo-quickstart-extras). Sandeep joined the team about 1.5 years ago and has from the start demonstrated his eagerness to learn and an excellent work ethic, having made many useful code submissions [1] and code reviews [2] to the CI repos and beyond. Thanks Sandeep and keep up the good work! Please reply to this mail with a +1 or -1 for objections in the usual manner. If there are no objections we can declare it official in a few days regards, marios [1] https://review.opendev.org/q/owner:sandeepyadav93 [2] https://www.stackalytics.io/report/contribution?module=tripleo-group&projec…

17 18

[glance] How to limit access to particular store
by at 10 Jun '21

10 Jun '21

Hi, I have Glance with multi-store config and I want one store (not default) to be read-only for everyone except cloud Admin. How can I do it? Is there any way to limit store names visibility (which are visible i.e. in properties section of "openstack image show IMAGE_NAME" output)? Best regards Adam Tomas

3 2

[neutron] Drivers meeting - agenda for 11.06.2021
by Slawek Kaplonski 10 Jun '21

10 Jun '21

Hi, Agenda for our tomorrow's meeting is at [1]. We have to discuss some details about existing spec [2] and one new RFE [3]. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda[1] [2] https://review.opendev.org/c/openstack/neutron-specs/+/783791[2] [3] https://bugs.launchpad.net/neutron/+bug/1931100[3] -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda [2] https://review.opendev.org/c/openstack/neutron-specs/+/783791 [3] https://bugs.launchpad.net/neutron/+bug/1931100

1 0

[all][tc] Technical Committee next weekly meeting on June 10th at 1500 UTC
by Ghanshyam Mann 10 Jun '21

10 Jun '21

Hello Everyone, NOTE: TC MEETINGS WILL BE HELD IN #openstack-tc CHANNEL ON OFTC NETWORK (NOT FREENODE) Technical Committee's next weekly meeting is scheduled for June 10th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, June 9th , at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

Regarding Floating IP not reachbale
by Adivya Singh 09 Jun '21

09 Jun '21

Hello Team, I need a hint , where to check, as often my floating IP are not reachable in Openstack , it uses OVS based networking , and most of the time if i changed the l3 agent router it start working, I can ping the gateway from the qrouter namespace but can not ping the actual floating IP Regards Adivya Singh

2 1

[all][stable] Ocata - End of Life
by Előd Illés 09 Jun '21

09 Jun '21

Hi, Sorry, this will be long :) as there are 3 topics around old stable branches and 'End of Life'. 1. Deletion of ocata-eol tagged branches With the introduction of Extended Maintenance process [1][2] some cycles ago, the 'End of Life' (EOL) process also changed: * branches were no longer EOL tagged and "mass-deleted" at the end of maintenance phase * EOL'ing became a project decision * if a project decides to cease maintenance of a branch that is in Extended Maintenance, then they can tag their branch with $series-eol However, the EOL-tagging process was not automated or redefined process-wise, so that meant the branches that were tagged as EOL were not deleted. Now (after some changing in tooling) Release Management team finally will start to delete EOL-tagged branches. In this mail I'm sending a *WARNING* to consumers of old stable branches, especially *ocata*, as we will start deleting the *ocata-eol* tagged branches in a *week*. (And also newer *-eol branches later on) 2. Ocata branch Beyond the 1st topic we must clarify the future of Ocata stable branch in general: tempest jobs became broken about ~ a year ago. That means that projects had two ways forward: a. drop tempest testing to unblock gate b. simply don't support ocata branch anymore As far as I see the latter one happened and stable/ocata became unmaintained probably for every projects. So my questions are regarding this: * Is any project still using/maintaining their stable/ocata branch? * If not: can Release Team initiate a mass-EOL-tagging of stable/ocata? 3. The 'next' old stable branches Some projects still support their Pike, Queens and Rocky branches. These branches use Xenial and py2.7 and both are out of support. This results broken gates time to time. Especially nowadays. These issues suggest that these branches are closer and closer to being unmaintained. So I call the attention of interested parties, who are for example still consuming these stable branches and using them downstream to put effort on maintaining the branches and their CI/gates. It is a good practice for stable maintainers to check if there are failures in their projects' periodic-stable jobs [3], as those are good indicators of the health of their stable branches. And if there are, then try to fix it as soon as possible. [1] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.… [2] https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… [3] http://lists.openstack.org/pipermail/openstack-stable-maint/2021-April/date… Thanks, Előd

1 2

[cinder] Bug deputy report for week of 2021-06-09
by Sofia Enriquez 09 Jun '21

09 Jun '21

Hello, Sorry for the late report. This is a bug report from 2021-25-05 to 2021-09-06. You're welcome to join the next Cinder Bug Meeting next week. Weekly on Wednesday at 1500 UTC on #openstack-cinder Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Critical:- High: - https://bugs.launchpad.net/cinder/+bug/1929678 'Attachment_create api leaks reserved attachments'. Assigned to Felix Huettner. Medium:- Low: - https://bugs.launchpad.net/cinder/+bug/1931003 'Add support for Pacific to RBD driver'. Assigned to Jon Bernard. - https://bugs.launchpad.net/cinder/+bug/1930526 ' Block Storage API V3 (CURRENT) in cinder - wrong URL for backup-detail'. Unassigned. - https://bugs.launchpad.net/cinder/+bug/1928947 ' Block Storage API V2 (DEPRECATED) - Still see v2 endpoints after disabling per documentation'. Unassigned. - https://bugs.launchpad.net/cinder/+bug/1930773 ' Block Storage API V3 (CURRENT) in cinder - remove Optional flag for key_size and cipher'. Assigned to Sofia Enriquez - https://bugs.launchpad.net/os-brick/+bug/1928331 ' Some operating systems use / lib / udev / SCSI_ ID to get the SCI_ WWN error'. Unassigned. Low:- Incomplete: - https://bugs.launchpad.net/cinder/+bug/1929810 'SVC: unable to create data volume using Compressed template'. Unassigned. Cheers, Sofia -- L. Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

OpenInfra Live - June 10th at 9am CT (1400 UTC)
by Erin Disney 09 Jun '21

09 Jun '21

Hi everyone, This week’s OpenInfra Live episode is brought to you by the OpenStack Community. Keeping up with new OpenStack releases can be a challenge. In this continuation of the May 20th OpenInfra Live episode, a panel of large scale OpenStack infrastructure operators from Blizzard Entertainment, OVHcloud, Workday, Vexxhost and CERN join us again to further discuss upgrades. Episode: Upgrades in Large Scale OpenStack Infrastructure: The Discussion Date and time: Thursday, June 10th at 9am CT (1400 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=C2fSy005lDs LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:6806241782301626368/ Facebook: https://www.facebook.com/openinfradev/videos/474846136944392 WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Belmiro Moreira (CERN), Arnaud Morin (OVH). Mohammed Naser (Vexxhost), Imtiaz Chowdhury (Workday), Joshua Slater (Blizzard) First Upgrades OpenInfra Live Episode: https://www.youtube.com/watch?v=yf5iFiCg_Tw Thanks, Erin Erin Disney Event Marketing Open Infrastructure Foundation

1 0

[Neutron] sriov network setup for victoria - clarification needed
by forums＠mossakowski.ch 09 Jun '21

09 Jun '21

Hello, I have two victoria environments: 1) a working one, standard setup with separate dedicated interface for sriov (pt0 and pt1) 2) a broken one, where I'm trying to reuse one of already used interfaces (ens2f0 or ens2f1) for sriov. ens2f0 is used for several VLANs (mgmt and storage) and ens2f1 is a neutron external interface which I bridged for VLAN tenant networks. On both I have enabled 63 VFs, it's a standard intetl 10Gb x540 adapter. On broken environment, when I'm trying to boot a VM with sriov port that I created before, I see this error shown on below gist: https://gist.github.com/moss2k13/8e6272cbe7748b2c5210fab291360e0b I'm investigating this for couple days now but I'm out of ideas so I'd like to ask for your support. Is this possible to achieve what I'm trying to do on 2nd environment? To use PF as normal interface and use its VFs for sriov-agent at the same time? Regards, Piotr Mossakowski

3 5

[horizon] Weekly meeting move to #openstack-horizon channel
by vishal manchanda 09 Jun '21

09 Jun '21

Hello everyone, As discussed during the last weekly meeting, I have purposed a patch[1] to move our weekly meeting from openstack-meeting-alt to the openstack-horizon channel. So from today onwards, our weekly meeting will be on the #openstack-horizon channel (OFTC n/w). See you at the meeting. Thanks & regards, Vishal Manchanda [1] https://review.opendev.org/c/opendev/irc-meetings/+/795110

1 0

[baremetal-sig][ironic] Tue June 8, 2021, 2pm UTC: The Ironic Python Agent Builder
by Arne Wiebalck 09 Jun '21

09 Jun '21

Dear all, The Bare Metal SIG will meet tomorrow Tue June 8, 2021, at 2pm UTC on zoom. The meeting will feature a "topic-of-the-day" presentation by Dmitry Tantsur (dtantsur) with an "Introduction to the Ironic Python Agent Builder" As usual, all details on https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome, hope to see you there! Cheers, Arne

2 1

[nova] destroy_secrets being added to nova.virt.driver.ComputeDriver.{cleanup, destroy}
by Lee Yarwood 08 Jun '21

08 Jun '21

Hello all, I'm looking to introduce and likely backport an optional kwarg to the signature of the cleanup and destroy virt driver methods below: virt: Add destroy_secrets kwarg to destroy and cleanup https://review.opendev.org/c/openstack/nova/+/794252 While this is optional for any callers any out of tree driver implementing either method will need to add this kwarg. This is part of the following bugfix series where I am attempting to avoid secrets from being destroyed during a hard reboot within the libvirt driver: https://review.opendev.org/q/topic:bug/1905701+status:open+branch:master Hopefully this is trivial but if there are any concerns or issues with this then please let me know! Cheers, Lee

1 0

Missing dependency on librte_xxxx when installing openstack-nova-scheduler
by Pete Zhang 08 Jun '21

08 Jun '21

I hit this error when installing “openstack-nova-scheduler” of release train.Anyone knows the issue/fix? What is the librte? is it another rpm i can download somewhere? or what is the best channel/DL to post this question, thx.Here is what I did. 1. I did this in a test box. 2. I have puppet-modules installed on the box 3. I have openstack-release-train’s rpms on the box and built a local-repo for puppet to install Debug: Executing: '/bin/yum -d 0 -e 0 -y install openstack-nova-scheduler' Error: Execution of '/bin/yum -d 0 -e 0 -y install openstack-nova-scheduler' returned 1: Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_bucket.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vmbus.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx4.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4()(64bit) Error: Package: python2-pynacl-1.3.0-1.el7.x86_64 (local_openstack-tnrp) Requires: libsodium.so.23()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_2.2)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gso.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-tooz >= 1.58.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_bnxt.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gro.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_latencystats.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx5.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_member.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_nfp.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_tap.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_17.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_pci.so.2()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-os-traits >= 0.16.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pdump.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_vdev_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-os-resource-classes >= 0.4.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2(DPDK_18.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_failsafe.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_ring.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_ixgbe.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bitratestats.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_stack.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vdev.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_qede.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_vhost.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_metrics.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_i40e.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pci.so.1()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Error: /Stage[main]/Nova::Scheduler/Nova::Generic_service[scheduler]/Package[nova-scheduler]/ensure: change from 'purged' to 'present' failed: Execution of '/bin/yum -d 0 -e 0 -y install openstack-nova-scheduler' returned 1: Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_bucket.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vmbus.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx4.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4()(64bit) Error: Package: python2-pynacl-1.3.0-1.el7.x86_64 (local_openstack-tnrp) Requires: libsodium.so.23()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_2.2)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gso.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-tooz >= 1.58.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_bnxt.so.2()(64bit) -- <https://smart.salesforce.com/sig/peiyong.zhang//us_mb/default/link.html>

6 9

[nova][placement] Weekly meeting moves to #openstack-nova
by Balazs Gibizer 08 Jun '21

08 Jun '21

Hi, As we agreed on the today's meeting[1] we will try out to hold our meetings on the project channel. I've update the agenda page on the Wiki and proposed the patch to update the official meeting schedule page [2]. So next week we will use #openstack-nova for the weekly meeting. cheers, gibi [1] https://meetings.opendev.org/meetings/nova/2021/nova.2021-06-08-16.00.log.h… [2] https://review.opendev.org/c/opendev/irc-meetings/+/795377

1 0

Re: [ops] rabbitmq queues for nova versioned notifications queues keep filling up
by Ajay Tikoo (BLOOMBERG/ 120 PARK) 08 Jun '21

08 Jun '21

Thank you, Christopher. From: cmccarth(a)mathworks.com At: 06/04/21 11:17:23 UTC-4:00To: openstack-discuss(a)lists.openstack.org Subject: Re: [ops] rabbitmq queues for nova versioned notifications queues keep filling up Hi Ajay, We work around this by setting a TTL on our notifications queues via RabbitMQ policy definition. We include the following in our definitions.json for RabbitMQ: "policies":[ {"vhost": "/", "name": "notifications-ttl", "pattern": "^(notifications|versioned_notifications)\\.", "apply-to": "queues", "definition": {"message-ttl":600000}, "priority":0} ] This expires messages in the notifications and versioned_notifications queues after 10 minutes, which seems to work well for us. I believe we initially picked up this workaround from this[1] bug report. Hope this helps, - Chris -- Christopher McCarthy MathWorks cmccarth(a)mathworks.com [1] https://bugs.launchpad.net/charm-rabbitmq-server/+bug/1737170 Date: Wed, 2 Jun 2021 22:39:54 -0000 From: "Ajay Tikoo (BLOOMBERG/ 120 PARK)" <atikoo(a)bloomberg.net> To: openstack-discuss(a)lists.openstack.org Subject: [ops] rabbitmq queues for nova versioned notifications queues keep filling up Message-ID: <60B808BA00D0068401D80001_0_3025859@msclnypmsgsv04> Content-Type: text/plain; charset="utf-8" I am not sure if this is the right channel/format to post this question, so my apologies in advance if this is not the right place. We are using Openstack Rocky. Watcher needs versioned notifications to be enabled. However after enabling versioned notifications, the queues for versioned_notifications (info and error) keep filling up Based on the updates the the Watchers cluster data model, it appears that Watcher is consuming messages, but they still linger in these queues. So with nova versioned notifications disabled, Watcher is unable to update the cluster data model (between rebuild intervals), and with them enabled, it keeps filling up the MQ queues. What is the best way to resolve this? Thank you, Ajay Tikoo

2 1

[nova][glance] Instance Password Reset
by Ammad Syed 08 Jun '21

08 Jun '21

Hi, I am trying to enable guest password reset for windows and linux guests. Is it possible to do it when the instance is running ? I am using wallaby release. By searching, I have found that qemu-guest-agent is required to reset the password. But I didn't see the the image property for it. https://opendev.org/openstack/glance/src/branch/stable/wallaby/doc/source/a… On other link I have found hw_qemu_guest_agent property for image this will help in this but looks too old and seems to be deprepacted. https://wiki.openstack.org/wiki/VirtDriverImageProperties My objective is to reset the linux and windows guest password or inject new key pair. Need your help, how to achieve it. - Ammad

1 0

[CLOUDKITTY] Fix tests cases broken by flask >=2.0.1
by Rafael Weingärtner 08 Jun '21

08 Jun '21

Hello guys, I was reviewing the patch https://review.opendev.org/c/openstack/cloudkitty/+/793790, and decided to propose an alternative patch ( https://review.opendev.org/c/openstack/cloudkitty/+/793973) Could you guys review it? The idea I am proposing is that, instead of mocking the root object ("flask.request"), we address the issue by mocking only the needed methods and attributes. This facilitates the understanding of the unit test, and also helps people to pin-point problems right away as the mocked attributes/methods are clearly seen in the unit test. -- Rafael Weingärtner

2 2

3rd party CI failures with devstack 'master' using devstack-gate
by Katari Kumar 08 Jun '21

08 Jun '21

1 0

[tripleo][ci] ovb jobs
by Wesley Hayutin 08 Jun '21

08 Jun '21

0/ Update on the OVB jobs across all centos-stream-8 branches. OVB jobs should be SUCCESSFUL If your overcloud has the rpm hostname.3.20-6.el8 and NOT 3.20-7.el8. e.g. [1] . The hostname package is being fixed via centos packaging. Related Change: https://git.centos.org/rpms/hostname/c/e097d2aac3e76eebbaac3ee4c2b95f575f37… Related Bugs: https://bugs.launchpad.net/tripleo/+bug/1930849 https://bugzilla.redhat.com/show_bug.cgi?id=1965897 https://bugzilla.redhat.com/show_bug.cgi?id=1956378 The CI team is putting in a temporary patch to force any OVB job to BUILD the overcloud images vs. pulling the prebuilt images until new overcloud images are rebuilt and promoted at this time [2] Thanks to Sandeep, Arx, Yatin and MIchele!!! [1] https://logserver.rdoproject.org/61/33961/6/check/tripleo-ci-centos-8-ovb-3… https://logserver.rdoproject.org/42/795042/1/openstack-check/tripleo-ci-cen… [2] https://review.rdoproject.org/r/c/rdo-jobs/+/34022 https://review.rdoproject.org/r/c/config/+/34023/

1 1

[mogan] Should we retire x/mogan?
by Martin Kopec 08 Jun '21

08 Jun '21

Hi all, x/mogan project has been inactive for some time now. It causes sanity issues in Tempest due to which it's excluded from the sanity check [1] and a review which should help to resolve them [2] is left untouched with failing gates - which also shows that the project is not maintained. Plus there haven't been any real changes done in the past 3 years [3]. I'm bringing this up to start a discussion about the future of the project. Should it be retired? Is it used? Are there any plans with it? [1] https://opendev.org/openstack/tempest/src/commit/663787ee794df54e7ded41e5f3… [2] https://review.opendev.org/c/x/mogan/+/767718 [3] https://opendev.org/x/mogan/commits/branch/master Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

3 2

Getting error during install openstack-nova-scheduler
by Pete Zhang 08 Jun '21

08 Jun '21

I hit the following errors and would like to know the fix. Debug: Executing: '/bin/yum -d 0 -e 0 -y install openstack-nova-scheduler' Error: Execution of '/bin/yum -d 0 -e 0 -y install openstack-nova-scheduler' returned 1: Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_bucket.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vmbus.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx4.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4()(64bit) Error: Package: python2-pynacl-1.3.0-1.el7.x86_64 (local_openstack-tnrp) Requires: libsodium.so.23()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_2.2)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gso.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-tooz >= 1.58.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_bnxt.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gro.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_latencystats.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx5.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_member.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_nfp.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_tap.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_17.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_pci.so.2()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-os-traits >= 0.16.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pdump.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_vdev_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-os-resource-classes >= 0.4.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2(DPDK_18.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_failsafe.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_ring.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_ixgbe.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bitratestats.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_stack.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vdev.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_qede.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_vhost.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_metrics.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_i40e.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pci.so.1()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Error: /Stage[main]/Nova::Scheduler/Nova::Generic_service[scheduler]/Package[nova-scheduler]/ensure: change from 'purged' to 'present' failed: Execution of '/bin/yum -d 0 -e 0 -y install openstack-nova-scheduler' returned 1: Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_bucket.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vmbus.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx4.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4()(64bit) Error: Package: python2-pynacl-1.3.0-1.el7.x86_64 (local_openstack-tnrp) Requires: libsodium.so.23()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_2.2)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gso.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-tooz >= 1.58.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_bnxt.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gro.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_latencystats.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx5.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_member.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_nfp.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_tap.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_17.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_pci.so.2()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-os-traits >= 0.16.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pdump.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_vdev_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-os-resource-classes >= 0.4.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2(DPDK_18.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_failsafe.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_ring.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_ixgbe.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bitratestats.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_stack.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vdev.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_qede.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_vhost.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_metrics.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_i40e.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pci.so.1()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest

4 4

[ops][victoria] Instance Hostname Metadata
by DHilsbos＠performair.com 08 Jun '21

08 Jun '21

All; Is there an instance metadata value that will set and / or change the instance hostname? Thank you, Dominic L. Hilsbos, MBA Vice President - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

2 1

Missing dependency on librte_xxxx when installing openstack-nova-scheduler
by Pete Zhang 07 Jun '21

07 Jun '21

I hit this error when installing “openstack-nova-scheduler” of release train.Anyone knows the issue/fix? What is the librte? is it another rpm i can download somewhere? or what is the best channel/DL to post this question, thx.Here is what I did. 1. I did this in a test box. 2. I have puppet-modules installed on the box 3. I have openstack-release-train’s rpms on the box and built a local-repo for puppet to install Debug: Executing: '/bin/yum -d 0 -e 0 -y install openstack-nova-scheduler' Error: Execution of '/bin/yum -d 0 -e 0 -y install openstack-nova-scheduler' returned 1: Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_bucket.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vmbus.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx4.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4()(64bit) Error: Package: python2-pynacl-1.3.0-1.el7.x86_64 (local_openstack-tnrp) Requires: libsodium.so.23()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_2.2)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gso.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-tooz >= 1.58.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_bnxt.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gro.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_latencystats.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx5.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_member.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_nfp.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_tap.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_17.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_pci.so.2()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-os-traits >= 0.16.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pdump.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_vdev_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-os-resource-classes >= 0.4.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2(DPDK_18.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_failsafe.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_ring.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_ixgbe.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bitratestats.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.08)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_16.07)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_stack.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vdev.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_qede.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_vhost.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_metrics.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_i40e.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pci.so.1()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Error: /Stage[main]/Nova::Scheduler/Nova::Generic_service[scheduler]/Package[nova-scheduler]/ensure: change from 'purged' to 'present' failed: Execution of '/bin/yum -d 0 -e 0 -y install openstack-nova-scheduler' returned 1: Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool_bucket.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_bus_vmbus.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_mlx4.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4()(64bit) Error: Package: python2-pynacl-1.3.0-1.el7.x86_64 (local_openstack-tnrp) Requires: libsodium.so.23()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ethdev.so.11(DPDK_2.2)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_17.05)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_meter.so.2()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_vhost.so.4(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_eal.so.9(DPDK_18.11)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mbuf.so.4(DPDK_2.1)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_ring.so.2(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_gso.so.1()(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_mempool.so.5(DPDK_2.0)(64bit) Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_netvsc.so.1()(64bit) Error: Package: 1:python2-nova-20.6.0-1.el7.noarch (local_openstack-tnrp) Requires: python2-tooz >= 1.58.0 Error: Package: 1:openvswitch-2.12.0-1.el7.x86_64 (local_openstack-tnrp) Requires: librte_pmd_bnxt.so.2()(64bit)

1 0

[oslo][taskflow][tooz][infra] Proposal to retire #openstack-state-management IRC channel
by Michael Johnson 07 Jun '21

07 Jun '21

Hello OpenStack community, The recent need to update various pointers to OpenStack IRC channels raised a question about the continued need for the #openstack-state-management channel[1]. This channel is for discussions of the OpenStack state management libraries such as TaskFlow and Tooz. Both libraries fall under the Oslo project. These projects are both in a maintenance phase and discussions in the #openstack-state-management channel have been few and far between. Today, at the Oslo IRC meeting, we discussed retiring this channel and updating the IRC channel information to the main Oslo IRC channel #openstack-oslo[2]. The intent of this change is to help users find a larger group of people that may be able to help answer questions as well as reduce the number of channels people and bots need to monitor. If you have any questions or concerns about the plan to consolidate this channel into the main Oslo IRC channel, please let us know. I plan to work on updating the documentation update patches (grin) to point to the Oslo channel and will work with OpenDev/Infra to retire the #openstack-state-management channel. Michael [1] https://review.opendev.org/c/openstack/taskflow/+/793992 [2] https://meetings.opendev.org/meetings/oslo/2021/oslo.2021-06-07-15.00.log.h…

1 0

[ops] Windows Guest Resolution
by DHilsbos＠performair.com 07 Jun '21

07 Jun '21

All; We finally have reliable means to generate Windows images for our OpenStack, but we're running into a minor annoyance. Our Windows instances appear to have a resolution cap of 1024x768. It would be extremely useful to be able use resolutions higher than this, especially 1920x1080. Is this possible with OpenStack on KVM? As a second request; is there a way to add a second virtual monitor? Or to achieve the same thing, increase the resolution to 3840x1080? Thank you, Dominic L. Hilsbos, MBA Vice President - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

3 3

[kingbird] Should we retire x/kingbird?
by Martin Kopec 07 Jun '21

07 Jun '21

Hi all, x/kingbird project has been inactive for some time now, f.e. there is a bug [1] which has been open for more than a year and which would solve sanity issues in Tempest. The project is on an exclude list due to that [2]. Also there haven't been any real changes for the past 3 years [3]. I'm bringing this up to start a discussion about the future of the project. Should it be retired? Is it used? Are there any plans with it? [1] https://bugs.launchpad.net/kingbird/+bug/1869722 [2] https://opendev.org/openstack/tempest/src/commit/663787ee794df54e7ded41e5f3… [3] https://opendev.org/x/kingbird/commits/branch/master Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[valet] Should we retire x/valet?
by Martin Kopec 07 Jun '21

07 Jun '21

Hi all, x/valet project has been inactive for some time now, f.e. there is a review [1] which has been open for more than 2 years and which would solve sanity issues in Tempest. The project is on an exclude list due to that [2]. Also there haven't been any real changes for the past 3 years [3]. I'm bringing this up to start a discussion about the future of the project. Should it be retired? Is it used? Are there any plans with it? [1] https://review.opendev.org/c/x/valet/+/638339 [2] https://opendev.org/openstack/tempest/src/commit/663787ee794df54e7ded41e5f3… [3] https://opendev.org/x/valet/commits/branch/master Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[neutron] IRC meetings location
by Slawek Kaplonski 07 Jun '21

07 Jun '21

Hi, As we discussed on the last team meeting, I proposed [1] and it was merged today. So our meetings starting this week will be on the #openstack-neutron channel @OFTC. Please be aware of that change and see You on the channel at the meetings :) [1] https://review.opendev.org/c/opendev/irc-meetings/+/794711[1] -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/opendev/irc-meetings/+/794711

1 0

[neutron][interop][refstack] New tests and capabilities to track in interop
by Martin Kopec 07 Jun '21

07 Jun '21

Hi everyone, I would like to further discuss the topics we covered with the neutron team during the PTG [1]. * adding address_group API capability It's tested by tests in neutron-tempest-plugin. First question is if tests which are not directly in tempest can be a part of a non-add-on marketing program? It's possible to move them to tempest though, by the time we do so, could they be marked as advisory? * Shall we include QoS tempest tests since we don't know what share of vendors enable QoS? Could it be an add-on? These tests are also in neutron-tempest-plugin, I assume we're talking about neutron_tempest_plugin.api.test_qos tests. If we want to include these tests, which program should they belong to? Do we wanna create a new one? [1] https://etherpad.opendev.org/p/neutron-xena-ptg Thanks, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

4 8

[kolla] [kolla-ansible] Magnum UI
by Alexandros Soumplis 07 Jun '21

07 Jun '21

Hi all, Before submitting a bug against launchpad I would like to ask if anyone else can confirm this issue. I deploy Magnum on Victoria release using the ubuntu binary containers and I do not have the UI installed. Changing to the source binaries, the UI is installed and working as expected. Is this a configerror, a bug or a feature maybe :) Thank you, a.

2 1

[Tacker] Tacker Not able to create VIM
by dangerzone ar 07 Jun '21

07 Jun '21

Hi all, I just deployed Tacker and tried to add my 1st VIM but I’m getting errors as per attached file. Pls advise how to resolve this problem. Thanks 1. *Error: *Failed to register VIM: {"error": {"message": "( http://192.168.0.121:5000/v3/tokens) The resource could not be found.", "code": 404, "title": "Not Found"}} 1. *Error as below**à** WARNING keystonemiddleware.auth_token [-] Authorization failed for token: InvalidToken* *{"vim": {"vim_project": {"name": "admin", "project_domain_name": "Default"}, "description": "d", "is_default": false, "auth_cred": {"username": "admin", "user_domain_name": "Default", "password": "c81e0c7a842f40c6"}, "auth_url": "**http://192.168.0.121:5000/v3 <http://192.168.0.121:5000/v3>**", "type": "openstack", "name": "d"}} process_request /usr/lib/python2.7/site-packages/tacker/alarm_receiver.py:43* *2021-06-04 09:41:44.655 61233 WARNING keystonemiddleware.auth_token [-] Authorization failed for token: InvalidToken* *2021-06-04 09:41:44.655 61233 INFO tacker.wsgi [-] 192.168.0.121 - - [04/Jun/2021 09:41:44] "POST //v1.0/vims.json HTTP/1.1" 401 384 0.001720* Below is my tacker.conf [DEFAULT] auth_strategy = keystone policy_file = /etc/tacker/policy.json debug = True use_syslog = False bind_host = 192.168.0.121 bind_port = 9890 service_plugins = nfvo,vnfm state_path = /var/lib/tacker [nfvo] vim_drivers = openstack [keystone_authtoken] region_name = RegionOne auth_type = password project_domain_name = Default user_domain_name = Default username = tacker password = password auth_url = http://192.168.0.121:35357 auth_uri = http://192.168.0.121:5000 [agent] root_helper = sudo /usr/bin/tacker-rootwrap /etc/tacker/rootwrap.conf [database] connection = mysql://tacker:password@192.168.0.121:3306/tacker?charset=utf8

4 5

[neutron][all] Functional/tempest/rally jobs not running on changes
by Brian Haley 07 Jun '21

07 Jun '21

Hi, This might be affecting more than Neutron so I added the [all] tag, and is maybe being discussed in one of the #opendev channels and I missed it (?), but looking at a recent patch recheck shows a number of jobs not being run, for example [0] has just 11 jobs instead of 25 in the previous run. So for now I would not approve any changes since they could merge accidentally with broken code. I pinged gmann and he thought [1] might have caused this, and it just merged... so perhaps a quick revert is in order. -Brian [0] https://review.opendev.org/c/openstack/neutron/+/790060 [1] https://review.opendev.org/c/openstack/devstack/+/791541

4 4

[neutron] Bug deputy report - week of May 31th
by Hongbin Lu 07 Jun '21

07 Jun '21

Hi, I was bug deputy last week. Here is my report regarding bugs from it: Critical: * https://bugs.launchpad.net/neutron/+bug/1930397 neutron-lib from master branch is breaking our UT job * https://bugs.launchpad.net/neutron/+bug/1930401 Fullstack l3 agent tests failing due to timeout waiting until port is active * https://bugs.launchpad.net/neutron/+bug/1930402 SSH timeouts happens very often in the ovn based CI jobs * https://bugs.launchpad.net/neutron/+bug/1930750 pyroute2 >= 0.6.2 fails in pep8 import analysis High: * https://bugs.launchpad.net/neutron/+bug/1930367 "TestNeutronServer" related tests failing frequently Medium: * https://bugs.launchpad.net/neutron/+bug/1930294 Port deletion fails due to foreign key constraint * https://bugs.launchpad.net/neutron/+bug/1930432 [L2] provisioning_block should be added to Neutron internal service port? Or should not? * https://bugs.launchpad.net/neutron/+bug/1930443 [LB] Linux Bridge agent always loads trunk extension, regardless of the loaded service plugins * https://bugs.launchpad.net/neutron/+bug/1930926 Failing over OVN dbs can cause original controller to permanently lose connection * https://bugs.launchpad.net/neutron/+bug/1930996 "rpc_response_max_timeout" configuration variable not present in neutron-sriov-nic agent Low: * https://bugs.launchpad.net/neutron/+bug/1930283 PUT /v2.0/qos/policies/{policy_id}/minimum_bandwidth_rules/{rule_id} returns HTTP 501 which is undocumented in the API ref * https://bugs.launchpad.net/neutron/+bug/1930876 "get_reservations_for_resources" execute DB operations without opening a DB context Triaging in progress * https://bugs.launchpad.net/neutron/+bug/1930838 key error in deleted_ports * https://bugs.launchpad.net/neutron/+bug/1930858 OVN central service does not start properly

1 0

[all][tc] What's happening in Technical Committee: summary 4th June, 21: Reading: 5 min
by Ghanshyam Mann 06 Jun '21

06 Jun '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Retired the sushy-cli[1]. * Replaced freenode ref with OFTC[2]. * Added TC resolution to move the IRC network from Freenode to OFTC[3] 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-06-03-15.00.log.html * We will have next week's meeting on June 10th, Thursday 15:00 UTC[4]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[5] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Two open reviews for ongoing activities[6]. MIgration from Freenode to OFTC ----------------------------------------- * All the required work for this migration is tracked in this etherpad[7] * TC resolution is merged[3]. * OFTC bot/logging is done. All project teams started their discussion/meetings to OFTC. * I have communicated the next steps on openstack-discuss ML[8] as well as to all PTLs individual email. * We are in 'Communicate with community' work where we need to update all contributor doc etc. Please finish this in your project and mark the progress in etherpad[7]. * This migration has been proposed to add in Open Infra newsletter OpenStack's news also[9]. * Topic change on Freenode channels will be done on June 11th. Nomination is open for the 'Y' release naming ------------------------------------------------------ * Y release naming process is started[10]. Nomination is open until June 10th feel free to propose names in below wiki ** https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals Replacing ATC terminology with AC (Active Contributors) ------------------------------------------------------------------- * Governance charter change for ATC->AC has been merged [11]. * TC resolution to map the ATC with the new term AC from Bylaws' perspective is up[12]. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [15] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://review.opendev.org/c/openstack/governance/+/792348 [2] https://review.opendev.org/c/openstack/governance/+/793864 [3] https://review.opendev.org/c/openstack/governance/+/793260 [4] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [5] https://etherpad.opendev.org/p/tc-xena-tracker [6] https://review.opendev.org/q/project:openstack/governance+status:open [7] https://etherpad.opendev.org/p/openstack-irc-migration-to-oftc [8] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022780.html [9] https://etherpad.opendev.org/p/newsletter-openstack-news [10] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022383.html [11] https://review.opendev.org/c/openstack/governance/+/790092 [12] https://review.opendev.org/c/openstack/governance/+/794366 [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [15] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[Diversity] Diversity and Inclusion Meeting Reminder - OFTC
by Amy Marrich 05 Jun '21

05 Jun '21

The Diversity & Inclusion WG invites members of all OIF projects to attend our next meeting Monday June 7th, at 17:00 UTC in the #openinfra-diversity channel on OFTC. The agenda can be found at https://etherpad.openstack.org/p/ diversity-wg-agenda. Please feel free to add any topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

[novnc-console] Cannot connect to console
by Derek O keeffe 04 Jun '21

04 Jun '21

Hi all, This is my first post to this list so excuse me if I have not submitted correctly. I have installed openstack Victoria manually as a multi node setup. A controller & 3 computes. Everything works fine and the way it's expected. I have secured horizon with letsencrypt certs (for now) and again all is fine. When I did a test deploy I also used those certs to load the novnc console securely and it worked. My problem with my new deploy is that the console will not load no matter what I try. I get the following error when I enable debug mode in nova. 2021-06-04 15:54:11.004 356545 ERROR nova.console.websocketproxy Traceback (most recent call last):2021-06-04 15:54:11.004 356545 ERROR nova.console.websocketproxy File "/usr/lib/python3/dist-packages/websockify/websockifyserver.py", line 691, in top_new_client2021-06-04 15:54:11.004 356545 ERROR nova.console.websocketproxy client = self.do_handshake(startsock, address)2021-06-04 15:54:11.004 356545 ERROR nova.console.websocketproxy File "/usr/lib/python3/dist-packages/websockify/websockifyserver.py", line 578, in do_handshake2021-06-04 15:54:11.004 356545 ERROR nova.console.websocketproxy context.load_cert_chain(certfile=self.cert, keyfile=self.key, password=self.key_password)2021-06-04 15:54:11.004 356545 ERROR nova.console.websocketproxy PermissionError: [Errno 13] Permission denied If I don't have debug enabled I just get the permission denied error. I have switched to the nova user and confirmed I can access the certs directory and read the certs. All my nova services are running fine as well. My controller conf is the following:[default]ssl_only=true cert=/etc/letsencrypt/live/ <MY_CONTROLLER_FQDN>/fullchain.pemkey=/etc/letsencrypt/live/ <MY_CONTROLLER_FQDN>/privkey.pem [vnc]enabled = trueserver_listen = 0.0.0.0server_proxyclient_address = $my_ipnovncproxy_base_url = https://<MY_CONTROLLER_FQDN>:6080/vnc_auto.html My compute config is the following:[vnc]enabled = trueserver_listen = 0.0.0.0server_proxyclient_address = $my_ipnovncproxy_base_url = https://<MY_CONTROLLER_FQDN>:6080/vnc_auto.html If anyone could help that would be really appreciated or any advice to further troubleshoot!! I cannot see anything else in any logs but I might not be looking in the right place. Thank you in advance. Derek

2 2

[nova] stable branches nova-grenade-multinode job broken
by melanie witt 04 Jun '21

04 Jun '21

Hi all, FYI the nova-grenade-multinode CI job is known to be broken on stable branches at the moment due to a too new version of Ceph (Pacific) being installed that is incompatible with the older jobs. We have fixes proposed with the following patch (and its backports to victoria/ussuri/train) to convert the job to native Zuul v3: https://review.opendev.org/c/openstack/nova/+/794345 Once these patches merge, the CI should be passing again. Cheers, -melanie

1 0

[Interop] draft of presentation to the board
by Kanevsky, Arkady 04 Jun '21

04 Jun '21

https://docs.google.com/presentation/d/1-9H1cTXZxW0vCSTzfBe0aMKbd7nggd8SOHQ… Comments welcome. Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

1 0

[kolla-ansible] kolla-ansible destroy
by at 04 Jun '21

04 Jun '21

Hi is kolla-ansible destroy "--tags" aware? What is the best way to remove all unwanted containers, configuration files, logs, etc. when you want to remove some service or move it to another node? Regards Adam Tomas

2 4

[TripleO] next irc meeting Tuesday 08 June @ 1400 UTC in OFTC #tripleo
by Marios Andreou 04 Jun '21

04 Jun '21

Reminder that the next TripleO irc meeting is: ** Tuesday 08 June 1400 UTC in OFTC irc channel: #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Add anything you want to highlight at https://etherpad.opendev.org/p/tripleo-meeting-items This can be recently completed things, ongoing review requests, blocking issues, or anything else tripleo you want to share. Our last meeting was on May 25 - you can find logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-05-25-14.… Hope you can make it on Tuesday, regards, marios

1 0

[Victoria][magnum][octavia]ingress-controller health degraded
by Luke Camilleri 04 Jun '21

04 Jun '21

Hi Everyone, we have the following problem that we are trying to identify the main cause: Basically we have deployed an ingress and an ingress-controller (using the following deployment file https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.44…) the ingress controller deployment is successful with 1 replica of the ingress-controller pod, the Octavia LoadBalancer is successfully created and points to the NodePorts being published on each node. This was showing only 1 member in the LoadBalancers screen as healthy/online. I increased the replicas to 3, from the LoadBalancers screen in Horizon, I can see the service being reported as degraded and only the kubernetes-worker-nodes that have the ingress-controller pod/s deployed on are being reported as online, this behaviour is not the same as a standard deployment where the NodePort actually communicates with the ClusterIP:Port of the internal service and hence once there is a single pod UP the NodePorts are shown as up when queried: ingress-nginx-controller-74fd5565fb-d86h9 1/1 Running 0 14h 10.100.3.13 k8s-c1-prod-2-klctfd24lze6-node-1 <none> <none> ingress-nginx-controller-74fd5565fb-h9985 1/1 Running 0 15h 10.100.1.8 k8s-c1-prod-2-klctfd24lze6-node-0 <none> <none> ingress-nginx-controller-74fd5565fb-qkddq 1/1 Running 0 15h 10.100.1.7 k8s-c1-prod-2-klctfd24lze6-node-0 <none> <none> The below shows the status of the members in the pool as replica3: | 834750fe-e43e-408d-abc3-aad3dcde0fdb | member_0_node-0 | id | ACTIVE | 192.168.1.75 | 32054 | ONLINE | 1 | | 1ddffd80-acae-40b3-a2de-19be0a69a039 | member_0_node-2 | id | ACTIVE | 192.168.1.90 | 32054 | ERROR | 1 | | d4e4baa4-0a69-4775-8ea0-165a207f11ae | member_0_node-1| id | ACTIVE | 192.168.1.148 | 32054 | ONLINE | 1 | In fact to have the deployment spread across all 3 nodes, I had to increase the replicas until all 3 nodes had at least an instance of the ingress controller running on them (in this case it was replica 5). I do not believe this as being an Octavia issue as the health check is being done via TCP port number which is the NodePort exposed by Kubernetes and if the ingress-controller is not running on that node the port check fails, I added the label octavia mainly to get some input that may confirm the correct behavior of Octavia I am expecting to receive a healthy state when i check the members of the pool since I can query the ClusterIP from any worker node on ports 80 and 443 and the outcome is always successful but not when using the NodePort Thanks in advance

1 0

Re: [ops] rabbitmq queues for nova versioned notifications queues keep filling up
by Christopher McCarthy 04 Jun '21

04 Jun '21

Hi Ajay, We work around this by setting a TTL on our notifications queues via RabbitMQ policy definition. We include the following in our definitions.json for RabbitMQ: "policies":[ {"vhost": "/", "name": "notifications-ttl", "pattern": "^(notifications|versioned_notifications)\\.", "apply-to": "queues", "definition": {"message-ttl":600000}, "priority":0} ] This expires messages in the notifications and versioned_notifications queues after 10 minutes, which seems to work well for us. I believe we initially picked up this workaround from this[1] bug report. Hope this helps, - Chris -- Christopher McCarthy MathWorks cmccarth(a)mathworks.com [1] https://bugs.launchpad.net/charm-rabbitmq-server/+bug/1737170 Date: Wed, 2 Jun 2021 22:39:54 -0000 From: "Ajay Tikoo (BLOOMBERG/ 120 PARK)" <atikoo(a)bloomberg.net> To: openstack-discuss(a)lists.openstack.org Subject: [ops] rabbitmq queues for nova versioned notifications queues keep filling up Message-ID: <60B808BA00D0068401D80001_0_3025859@msclnypmsgsv04> Content-Type: text/plain; charset="utf-8" I am not sure if this is the right channel/format to post this question, so my apologies in advance if this is not the right place. We are using Openstack Rocky. Watcher needs versioned notifications to be enabled. However after enabling versioned notifications, the queues for versioned_notifications (info and error) keep filling up Based on the updates the the Watchers cluster data model, it appears that Watcher is consuming messages, but they still linger in these queues. So with nova versioned notifications disabled, Watcher is unable to update the cluster data model (between rebuild intervals), and with them enabled, it keeps filling up the MQ queues. What is the best way to resolve this? Thank you, Ajay Tikoo

1 0

[security-sig][cinder] propose vulnerability:managed tag for os-brick
by Brian Rosmaita 04 Jun '21

04 Jun '21

I've posted a patch to add the 'vulnerablity:managed' tag to the os-brick library: https://review.opendev.org/c/openstack/governance/+/794680 I just want to give a heads-up to the OpenStack Vulnerablity Management Team, since this will impact the VMT, though hopefully not very much. The Cinder team was under the impression that the VMT was already managing private security bugs for os-brick. The issue may not have come up before because usually there's a driver + connector involved and the bug gets filed under cinder (which is already tagged vulnerablity:managed). In any case, the cinder team discussed this at our recent midcycle meeting and decided that we appreciate the extra eyes and long-term perspective the VMT brings to the table, and we'd like to formalize a relation between the VMT and the os-brick library. cheers, brian

2 1

[cinder] reminder: xena spec freeze 25 June
by Brian Rosmaita 04 Jun '21

04 Jun '21

This is a reminder that all Cinder Specs for features to be implemented in Xena must be approved by Friday 25 June 2021 (23:59 UTC). We discussed several specs at the R-18 virtual midcycle meeting. Please take a look at the summary and take any appropriate action for your spec proposal: https://wiki.openstack.org/wiki/CinderXenaMidCycleSummary#Xena_Specs_Review Anyone with a spec proposal that wasn't discussed, and who needs more feedback than is currently on the Gerrit review, should reach out to the Cinder team for help by putting a topic on the weekly meeting agenda, asking in the OFTC #openstack-cinder channel, or via the openstack-discuss mailing list. cheers, brian

1 0

[cinder] xena R-18 mid-cycle summary available
by Brian Rosmaita 04 Jun '21

04 Jun '21

In case you missed the Xena cinder R-18 virtual mid-cycle session earlier this week, I've posted a summary: https://wiki.openstack.org/wiki/CinderWallabyMidCycleSummary It includes a link to the recording if you want more context for any topic that interests you. We're planning to have another mid-cycle session the week of R-9, namely, on Wednesday 4 August 2021, 1400-1600 UTC. As always, you can add topics to the planning etherpad: https://etherpad.opendev.org/p/cinder-xena-mid-cycles cheers, brian

1 1

libcloud
by Massimo Canonico 04 Jun '21

04 Jun '21

Hi, I'm new and I'm not sure if here is the right place to post the questions related to OpenStack and Libcloud. I've used for years OpenStack provided by Chameleon project and recently they change the autentication procedure (they use a federate login). Since them, I'm having problem to use my script with libcloud. This script was working with the legacy login: provider = get_driver(Provider.OPENSTACK) conn = provider(auth_username,auth_password,ex_force_auth_url=auth_url, ex_force_auth_version='3.x_password', ex_tenant_name=project_name, ex_force_service_region=region_name,api_version='2.1') Now it is not working. If I take a look at the openrc file I can note this: export OS_AUTH_TYPE="v3oidcpassword" Maybe, this is the problem. Any idea about how can I fix my script? Thanks, Massimo

2 1

[blazar] IRC meeting moving to #openstack-blazar
by Pierre Riteau 04 Jun '21

04 Jun '21

Hello, Following the latest recommendation from the TC, the bi-weekly IRC meeting of the Blazar project is moving to the #openstack-blazar channel on OFTC. This will be effective from the next meeting on June 17. Pierre Riteau (priteau)

1 0

[wallaby][neutron][ovn] MTU in Neutron for Production
by Malik Obaid 04 Jun '21

04 Jun '21

Hi, I am using Openstack Wallaby release on Ubuntu 20.04. I am configuring openstack neutron for production. While setting mtu I am a bit confused between the 2 use cases. *Case 1* External (public) network mtu 1500 self service (tenent) network geneve mtu 9000 VLAN external network mtu 1500 *Case 2* External (public) network mtu 9000 self service (tenent) network geneve mtu 9000 VLAN external network mtu 9000 I just want to know which case would be better for production. I would really appreciate any input in this regard. Thank you. Regards, Malik Obaid

1 0

[neutron] Meetings channel changes
by Slawek Kaplonski 04 Jun '21

04 Jun '21

Hi, As we discussed on our last team meeting, I just proposed change to move our meetings from the openstack-meeeting-* channels to the openstack-neutron channel [1]. Let's have today's drivers meeting still on the #openstack-meeting channel @OFTC but starting next week all our meetings will take place on the #openstack-neutron channel. [1] https://review.opendev.org/c/opendev/irc-meetings/+/794711[1] -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/opendev/irc-meetings/+/794711

1 0

Fwd: [ironic] IPA image does not want to boot with UEFI
by Vuk Gojnic 04 Jun '21

04 Jun '21

Hi Julia, thanks for the response. I have now verified that the server has Secure Boot set to Disabled. It happens on all our HPE Gen10 and Gen10+ servers that are booting with UEFI in the same configuration (Secure Boot Disabled). Unsigned initrd from ubuntu for example works with Kernel from IPA: I have also updated firmware of the server to the latest version, but it is still the same. I am going to try to drill deeper in IPA builder code and IPA initrd which seems not to go well with UEFI boot mode. I am grateful for any hint. Bests, Vuk

3 7

[vitrage]The vitrage api "vitrage alarm list" get wrong response
by Tahoe Wang (王太浩) 04 Jun '21

04 Jun '21

Hello. I have successfully installed vitrage, configured the datasources from nova. host and Prometheus, also configured the mapping file from ALARM to RESOURCE, and seen the alarm received from the request log of vitrage API. However, when I use the “vitrage alarm list” command through cli, the list returned is empty. Why? Look forward to your reply. Thanks！

1 0

[tc] Moving IRC meetings to project channels
by Pierre Riteau 04 Jun '21

04 Jun '21

Hello, In the guidance to PTLs for the freenode to OFTC migration, there was this guideline: > The TC is asking that projects take advantage of this time of change to consider moving project meetings from the #openstack-meeting* channels to their project channel. I was surprised since it was the first time I heard about this suggested change. The project team guide [1] actually still states the following: > The OpenStack infrastructure team maintains a limited number of channels dedicated to meetings. While teams can hold meetings on their own team IRC channels, they are encouraged to use those common meeting channels to give their meeting some external exposure. The limited number of meeting channels encourages teams to spread their meetings around and reduce conflicts. Is there any background regarding this proposed change? Not that I am against it in any way: I have participated in meetings in both kinds of channels and haven't really seen any difference. Thanks, Pierre Riteau (priteau) [1] https://docs.openstack.org/project-team-guide/open-community.html#public-me…

3 2

[Manila ] Upcoming Bug Squash starting June 7th through June 11th 2021
by Vida Haririan 03 Jun '21

03 Jun '21

Hi everyone, As discussed, a new Bug Squash event is around the corner! The event will be held from 7th to 11th June, 2021, providing an extended contribution window. There will be a synchronous call held simultaneously on IRC, Thursday June 10th, 2021 at 15:00 UTC and we will use this Jitsi bridge [1]. A list of selected bugs will be shared here [2]. Please feel free to add any additional bugs you would like to address during the event. Thanks for your participation in advance. Vida [1] https://meetpad.opendev.org/ManilaX-ReleaseBugSquash [2] https://ethercalc.openstack.org/i3vwocrkk776 <https://meetpad.opendev.org/ManilaX-ReleaseBugSquash> <https://meetpad.opendev.org/ManilaX-ReleaseBugSquash>

2 1