- openstack-discuss - lists.openstack.org

[neutron] Bug deputy report for week of May 9
by Lajos Katona 16 May '22

16 May '22

Hi Neutron Team I was bug deputy in neutron last week. Needs attention ================= * OVN revision_number infinite update loop ( https://bugs.launchpad.net/neutron/+bug/1973347 ) In Progress ============ * Slow queries after upgrade to Xena ( https://bugs.launchpad.net/neutron/+bug/1973349 ) Done ======= * [Wallaby] OVNPortForwarding._handle_lb_on_ls fails with TypeError: _handle_lb_on_ls() got an unexpected keyword argument 'context' ( https://bugs.launchpad.net/neutron/+bug/1972764) Question ======== * Does FWaaS v2 support linuxbridge-agent ? ( https://bugs.launchpad.net/neutron/+bug/1973039) Invalid / Won't fix ================= * Skip DB retry when update on "standardattributes" fails ( https://bugs.launchpad.net/neutron/+bug/1973049 ) * FWaaS rules lost on l3 agent restart ( https://bugs.launchpad.net/neutron/+bug/1973035 ) * Unable to delete FWaaS v2 firewall group stuck ACTIVE ( https://bugs.launchpad.net/neutron/+bug/1972746 ) * [neutron-dynamic-routing] Train CI is broken ( https://bugs.launchpad.net/neutron/+bug/1972854 ) ** https://review.opendev.org/c/openstack/releases/+/841292 train will be EOL-d Lajos Katona (lajoskatona)

1 0

Fwd: unable to connect instance to external network
by Vinesh N 15 May '22

15 May '22

hi, openstack - tripleo installed and was able to launch the instances. Machine has two interfaces, eth2 for external(WAN 192.168.35.0/24) and eth3 for internal(LAN 10.0.20.0/24). issue: unable to reach route interface by following command. (in this case, my route ipaddres 10.0.1.73) * openstack network create public * openstack subnet create --network public public --subnet-range 10.0.1.0/24 --allocation-pool start=10.0.1.40,end=10.0.1.80 --dns-nameserver 8.8.8.8 --gateway 10.0.1.1 --no-dhcp * openstack network create public --provider-physical-network datacentre --provider-network-type vlan --provider-segment 1 --external --share here is my ml2_conf.ini ******************************************************** [ml2] type_drivers=geneve,vlan,flat tenant_network_types=geneve mechanism_drivers=ovn path_mtu=0 extension_drivers=qos,port_security,dns [ml2_type_geneve] max_header_size=38 vni_ranges=1:65536 [ml2_type_vlan] network_vlan_ranges=datacentre:1:1000 [ml2_type_flat] flat_networks=datacentre #[linux_bridge] #physical_interface_mappings = datacentre:br-ex #physical_interface_mappings = datacentre:ens20f2 [ovn] ovn_nb_connection=tcp:10.0.1.158:6641 ovn_sb_connection=tcp:10.0.1.158:6642 ovsdb_connection_timeout=180 neutron_sync_mode=log ovn_l3_mode=True vif_type=ovs ovn_metadata_enabled=True enable_distributed_floating_ip=True dns_servers= ovn_emit_need_to_frag=False **************************************************************** here is my controller network: (ens2042 external and ens2043 internal interfaces) [root@overcloud-controller-0 ~]# ip a |more 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens20f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000 link/ether 00:25:90:fe:0f:dc brd ff:ff:ff:ff:ff:ff inet6 fe80::225:90ff:fefe:fdc/64 scope link valid_lft forever preferred_lft forever 3: ens20f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 00:25:90:fe:0f:dd brd ff:ff:ff:ff:ff:ff 4: ens20f2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:25:90:fe:0f:de brd ff:ff:ff:ff:ff:ff inet 192.168.35.86/24 brd 192.168.35.255 scope global dynamic noprefixroute ens20f2 valid_lft 39528sec preferred_lft 39528sec inet6 fe80::f2d5:4cdf:ab4f:4f14/64 scope link noprefixroute valid_lft forever preferred_lft forever 5: ens20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:25:90:fe:0f:df brd ff:ff:ff:ff:ff:ff inet6 fe80::225:90ff:fefe:fdf/64 scope link valid_lft forever preferred_lft forever 6: ib0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 4092 qdisc fq_codel state DOWN group default qlen 256 link/infiniband 80:00:02:08:fe:80:00:00:00:00:00:00:e4:1d:2d:03:00:21:eb:51 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff 7: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether fa:8f:18:e9:44:e6 brd ff:ff:ff:ff:ff:ff 8: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 00:25:90:fe:0f:dc brd ff:ff:ff:ff:ff:ff inet 10.0.1.179/24 brd 10.0.1.255 scope global br-ex valid_lft forever preferred_lft forever inet6 fe80::225:90ff:fefe:fdc/64 scope link valid_lft forever preferred_lft forever 9: vlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 42:f0:35:f5:cf:5f brd ff:ff:ff:ff:ff:ff inet 10.0.1.179/24 brd 10.0.1.255 scope global vlan1 valid_lft forever preferred_lft forever inet 10.0.1.141/32 brd 10.0.1.255 scope global vlan1 valid_lft forever preferred_lft forever inet 10.0.1.158/32 brd 10.0.1.255 scope global vlan1 valid_lft forever preferred_lft forever inet6 fe80::40f0:35ff:fef5:cf5f/64 scope link valid_lft forever preferred_lft forever 10: br-int: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 76:36:79:8f:4f:b7 brd ff:ff:ff:ff:ff:ff 11: genev_sys_6081: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65000 qdisc noqueue master ovs-system state UNKNOWN group default qlen 1000 link/ether 0e:59:d6:99:85:78 brd ff:ff:ff:ff:ff:ff inet6 fe80::c59:d6ff:fe99:8578/64 scope link valid_lft forever preferred_lft forever Note: I tried with 192.168.35.0/24/200.168.35.0/24 for the external network topology as well. Thanks, Vinesh ---------------

1 0

ImportError: cannot import name 'ceph_spec'" | Openstack Wallaby | Tripleo
by Swogat Pradhan 15 May '22

15 May '22

Hi Team, I am deploying openstack wallaby using the deployed ceph method. I am currently facing this issue while deploying overcloud. Can someone please check ? "2022-05-13 14:17:51.022353 | 48d539a1-1679-730f-272a-0000000000cb | TASK | Create the RGW Daemon spec definition", "An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ImportError: cannot import name 'ceph_spec'", "2022-05-13 14:17:51.669288 | 48d539a1-1679-730f-272a-0000000000cb | FATAL | Create the RGW Daemon spec definition | overcloud-controller-0 | error={\"changed\": false, \"module_stderr\": \"Traceback (most recent call last):\\n File \\\"<stdin>\\\", line 102, in <module>\\n File \\\"<stdin>\\\", line 94, in _ansiballz_main\\n File \\\"<stdin>\\\", line 40, in invoke_module\\n File \\\"/usr/lib64/python3.6/runpy.py\\\", line 205, in run_module\\n return _run_module_code(code, init_globals, run_name, mod_spec)\\n File \\\"/usr/lib64/python3.6/runpy.py\\\", line 96, in _run_module_code\\n mod_name, mod_spec, pkg_name, script_name)\\n File \\\"/usr/lib64/python3.6/runpy.py\\\", line 85, in _run_code\\n exec(code, run_globals)\\n File \\\"/tmp/ansible_ceph_mkspec_payload_iwqyfs7g/ansible_ceph_mkspec_payload.zip/ansible/modules/ceph_mkspec.py\\\", line 24, in <module>\\nImportError: cannot import name 'ceph_spec'\\n\", \"module_stdout\": \"\", \"msg\": \"MODULE FAILURE\\nSee stdout/stderr for the exact error\", \"rc\": 1}", With regards, Swogat Pradhan

2 6

[all][tc] What's happening in Technical Committee: summary May 13, 2022: Reading: 5 min
by Ghanshyam Mann 14 May '22

14 May '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on May 12. Most of the meeting discussions are summarized in this email. Meeting summary logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-12-15.00.log.html * Next TC weekly meeting will be on May 19 Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by May 18. 2. What we completed this week: ========================= * FIPS goal is selected community-wide goal now[2]. 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[3], we have started the many items. Open Reviews ----------------- * Nine open reviews for ongoing activities[4]. Change OpenStack release naming policy proposal ----------------------------------------------------------- In today's TC meeting [5], we discussed this topic with Foundation staff and we all agreed to give the release name process handling to Foundation. TC will not be involved in the process. The release name will be mainly used for marketing purposes and we will use the release number as the primary identifier in our release scheduling, automated processes, directory structure etc. The agreed proposal is up for review[6] New release cadence open items --------------------------------------- 1. release notes strategy: Brian presented the different possible ways to reflect the tick-tock ( hoping this is the last time I am using these names as we agree to change them, see below ) release notes combination[7] and we agreed with the 'simple' approach[8]. 2. release cadence terminology With the outcome of the legal check, it is not clear to us that tick-tock words are ok to use for the new release cadence terminology and in what form/combination. In TC, we decided to use a different name and 'SLURP' (Skip Level Upgrade Release Process) is the choice of the majority. I have pushed the patch to reflect the same in the TC resolution[9]. Improve project governance --------------------------------- Slawek has the proposal the framework up and it is under review[10]. New ELK service dashboard: e-r service ----------------------------------------------- Tripleo team joined the TC meeting and we agreed to merge the master and rdo branches in the elastic-recheck repo. It is completely fine to keep both devstack-based and tripleo focus things and maintain them collaboratively. The hosting part will be investigated by the dpawlik Consistent and Secure Default RBAC ------------------------------------------- We had our weekly call on Tuesday 10 May and we agreed on the 'service' role part. I will update the spec for this. The heat open item is still in discussion and Takashi sent an email asking the feedback about the 'split stack' approach, please respond with your thought[11] While we are discussing the heat/scope things, we agreed to work on the 'new defaults' at least (separate from scope which will see later). Please find the summary/plan in etherpad L97[12] 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[13]. Feel free to check and provide feedback. Zed cycle Leaderless projects ---------------------------------- No updates on this. Only Adjutant project is leaderless/maintainer-less. We will check Adjutant's the situation again on ML and hope Braden will be ready with their company side permission[14]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[15]. Project updates ------------------- * None 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[16]. [2] https://governance.openstack.org/tc/goals/selected/fips.html 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [17] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [3] https://etherpad.opendev.org/p/tc-zed-tracker [4] https://review.opendev.org/q/projects:openstack/governance+status:open [5] https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-12-15.00.log.html#… [6] https://review.opendev.org/c/openstack/governance/+/841800 [7] https://review.opendev.org/c/openstack/cinder/+/840996 [8] https://review.opendev.org/c/openstack/cinder/+/840996/1/releasenotes/sourc… [9] https://review.opendev.org/c/openstack/governance/+/840354 [10] https://review.opendev.org/c/openstack/governance/+/839880 [11] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028490.html [12] https://etherpad.opendev.org/p/rbac-zed-ptg#L97 [13] https://review.opendev.org/c/openstack/governance/+/836888 [14] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.ht… [15] https://etherpad.opendev.org/p/zuul-config-error-openstack [16] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [17] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[manila] Manila Zed hack-a-thon
by Carlos Silva 14 May '22

14 May '22

Hi Zorillas and fellow stackers, Over the past cycles we had a good effort to add OSC support to Manila. We are quite close to parity now (thanks to all the Zorillas involved). In those changes, we didn't focus on automated functional testing. Over PTG we came up with the idea to host a hack-a-thon, so we could enhance our functional test coverage, helping to ensure the quality of our OSC. We will be doing that from *May 16th to May 23rd.* The work on OSC is currently being tracked here: https://tree.taiga.io/project/gouthampacha-openstack-manila-osc-integration… What are the plans for the hack-a-thon: - There are few examples of recent additions [1][2] that could serve as inspiration. You're free to create, claim and edit Taiga cards for the implementation you're chasing. Please reach out to me (carloss) or Goutham (gouthamr) if you have to be added to the taiga board. Also, Add yourself as a "watcher" to two other Taiga cards that someone else is implementing, this will mean that you will be a code reviewer on these implementations! - You can work in teams - min size: 1, max size: 2 - You can submit code between May 16th 1500 UTC and May 23rd 1500 UTC to count towards this hack-a-thon - During the hack-a-thon, we'll use #openstack-manila on OFTC to chat, and hop onto a meeting room [3] - We'll have a one hour kick-off session on May 16th at 1500 UTC - On this session we will also cover the environment setup - We'll use the manila community meeting hour as a mid-point status check (May 19th, 1500 UTC) - We'll have a half-hour close out meeting to discuss reviews, AIs and futures (May 23rd, 1500 UTC) All sessions will take place on the [3] bridge. Please feel free to reach out here or on OFTC's #openstack-manila if you have any questions! Huge thank you to Maari for helping us out with the backlog. I hope to see you there and that we accomplish good things with this Hackathon! [1] https://review.opendev.org/c/openstack/python-manilaclient/+/707577 [2] https://review.opendev.org/c/openstack/python-manilaclient/+/836834 [3] https://bluejeans.com/371190441 Regards, carloss

1 0

[release] Release countdown for week R-20, May 16 - 20
by Előd Illés 14 May '22

14 May '22

Development Focus ----------------- The Zed-1 milestone is next week, on May 19th, 2022! Project team plans for the Zed cycle should now be solidified. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Yoga release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Zed-1 milestone: May 19th, 2022 OpenInfra Summit: June 7-9, 2022 (Berlin) Előd Illés irc: elodilles

1 0

[puppet] Gate blocker: Installation of the systemtap package fails
by Takashi Kajinami 13 May '22

13 May '22

Hello, We are currently facing consistent failure in centos stream 9 integration jobs. which is caused by the new dyninst package. I've already reported the issue in bz[1] and we are currently waiting for the updated systemtap package. Please avoid rechecking until the package is released [1] https://bugzilla.redhat.com/show_bug.cgi?id=2079892 If the fix is not released for additional days then we can merge the temporal workaround to unblock our jobs. https://review.opendev.org/c/openstack/puppet-openstack-integration/+/840188 Last week we also saw centos stream 8 jobs consistently failing but it seems these jobs were already fixed by the new python3-qt5 package. [2] https://bugzilla.redhat.com/show_bug.cgi?id=2079895 Thank you, Takashi

2 3

[TripleO] Gate blocker on Wallaby/Victoria/Train - Content-provider job failing
by Sandeep Yadav 13 May '22

13 May '22

Hello All, Currently, we have a check/gate blocker on Tripleo Content-provider job for wallaby and earlier branches. The content-provider job cannot pull Ceph related containers because quay.ceph.io is not accessible. The details have been added to the launchpad bug[1]. Please hold rechecks while we are investigating the issue. In the meantime, We are trying to switch the registry to pull ceph related containers and waiting for the triple ceph team squad reviews on the patch[2]. [1] https://bugs.launchpad.net/tripleo/+bug/1973115 [2] https://review.opendev.org/c/openstack/tripleo-common/+/841512 Sandeep (on behalf of TripleO CI team)

1 1

Meet the OpenStack community in Berlin, June 7-9
by Helena Spease 13 May '22

13 May '22

Hi everyone, OpenInfra Summit Berlin is around the corner, and in less than a month, hundreds of OpenStack community members will be in Berlin, Germany to present and share the latest upstream development, use cases and news in the OpenStack community. Here I have compiled all the OpenStack sessions that you can look forward to at the Summit. https://superuser.openstack.org/articles/what-can-you-expect-to-learn-about… <https://superuser.openstack.org/articles/what-can-you-expect-to-learn-about…> Don’t forget to register before the Summit prices increase on May 16 at 11:59 PM PT to save on your ticket purchase and learn all about the OpenStack project at the OpenInfra Summit Berlin, June 7-9. You can register for your ticket here: https://openinfrasummitberlin.eventbrite.com <https://openinfrasummitberlin.eventbrite.com/> Cheers, Helena

1 0

[neutron] Drivers meeting agenda - 13.05.2022.
by Lajos Katona 13 May '22

13 May '22

Hi Neutron Drivers, The agenda for tomorrow's drivers meeting is at [1]. [RFE][fwaas][OVN]support l3 firewall for ovn driver (#link https://bugs.launchpad.net/neutron/+bug/1971958) * On Demand agenda: (ralonsoh): https://bugs.launchpad.net/neutron/+bug/1973049: with the SQLAlchemy 2.0 compatibility patch in place (n-lib 2.21.0), there are some issues when an API call (e.g.: user command) updates the same resource as another RPC call (agent call). This is very frequent with port status and FIP status. Sometimes (I still need to investigate the reason), the retry command detects that there is another SQL transaction in progress ( https://paste.opendev.org/show/beHzMCKjVLmE5nX0ZXZX/) [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda See you at the meeting tomorrow. Lajos Katona (lajoskatona)

1 0

[Neutron][neutron-vpnaas] proposing Mohammed Naser for neutron-vpnaas core reviewer
by Lajos Katona 13 May '22

13 May '22

Hi, I would like to propose Mohammed Naser (mnaser) as a core reviewer to neutron-vpnaas. He and his company uses neutron-vpnaas in production and volunteered to help in the maintenance of it. You can vote/feedback in this email thread. If there is no objection by 6th of May, we will add Mohammed to the core list. Thanks Lajos

6 6

[cinder][kolla][OSA][release] Yoga cycle-trailing release deadline
by Előd Illés 13 May '22

13 May '22

Hello teams with deliverables following the cycle-trailing release model! This is just a reminder to wrap up your trailing deliverables for Yoga. A few cycles ago the deadline for cycle-trailing projects was extended to give more time. The deadline for Yoga is *June 23rd, 2022* [1]. If things are ready sooner than that though, all the better for our downstream consumers. For reference, the following cycle-trailing deliverables will need final releases at some point until the above deadline: ansible-collection-kolla cinderlib kayobe kolla-ansible kolla openstack-ansible-roles openstack-ansible Thanks! Előd Illés irc: elodilles [1]https://releases.openstack.org/zed/schedule.html#z-cycle-trail

1 0

[TripleO] Gate blocker on master - tripleo-ci-centos-9-undercloud-upgrade
by Ronelle Landy 12 May '22

12 May '22

Hello All, Currently we have a gate blocker in test: tripleo-ci-centos-9-undercloud-upgrade. The details have been added to https://bugs.launchpad.net/tripleo/+bug/1973043. We are testing a workaround until we can promote a new master build with new containers. Please hold rechecks in the meantime. Thanks, Ronelle (for TripleO CI)

2 1

[all][tc] Technical Committee next weekly meeting on May 12, 2022 at 1500 UTC
by Ghanshyam Mann 12 May '22

12 May '22

Hello Everyone, Technical Committee's next weekly meeting is scheduled for May 12, 2022 at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, May 11, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[docs] feedback mechanism
by Peter Matulis 12 May '22

12 May '22

Hi, I was wondering what the various projects use to gather user feedback for their documentation. Is something like what is visible here [0,1] acceptable to the OpenStack community?There is a widget at the right side of the page (disable your ad-blocker!). [0]: https://juju.is/docs/olm [1]: https://charmed-kubeflow.io/docs Peter Matulis OpenStack Charms team

2 2

[largescale-sig] Next meeting: May 11th, 15utc
by Thierry Carrez 12 May '22

12 May '22

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can check how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220511T15 Feel free to add topics to the agenda: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[neutron][opencontrail]Trunk ports doesn't have standard attributes
by Gleb Zimin 11 May '22

11 May '22

Environment: Openstack Victoria, OpenContrail (TungstenFabric) R2011. Problem: Trunk ports doesn't have standard attributes such as description, timestamp. I have an environment where core plugin is OpenContrail. OpenContrail has tf-neutron-plugin for proper work with neutron. There is TrunkPlugin, that proxies all trunk-related request to the OpenContrail backend. Here is the link for this plugin. https://gerrit.tungsten.io/r/gitweb?p=tungstenfabric/tf-neutron-plugin.git;… According to the openstack documentation: Resources that inherit from the HasStandardAttributes DB class can automatically have the extensions written for standard attributes (e.g. timestamps, revision number, etc) extend their resources by defining the ‘api_collections’ on their model. These are used by extensions for standard attr resources to generate the extended resources map. As I understood, it works only for plugins, which using Openstack database. For example, openstack native trunk plugin has models.py file where we can see this inheritance. https://github.com/openstack/neutron/blob/master/neutron/services/trunk/mod… In case of OpenContrail+OpenStack Trunk plugin only redirect requests. What can I do to make Contrail Trunk plugin works in the same way? I'll appreciate any help. Thanks in advance.

3 3

[cinder] Bug deputy report for week of 05-11-2022
by Sofia Enriquez 11 May '22

11 May '22

This is a bug report from 05-04-2022 to 05-11-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- High - https://bugs.launchpad.net/cinder/+bug/1971970 "Cinder do not encrypt volumes correctly(25% success ratio)." Possible fix already on master. Medium - https://bugs.launchpad.net/cinder/+bug/1971668 " [IBM Storwize_SVC] Able to create Volume -type, Volume, and snapshot with Invalid clean_rate." Unassigned. Cheers, -- 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

OpenStack - OVS 2.15.2 - Intel E810-C - SR-IOV issue
by Halil Ibrahim ERYALCIN 11 May '22

11 May '22

Hello, We 've a issue about running SR-IOV feature on OVS with Intel E810-C NIC. Ovs configuration is shared. When try to attach interface to VM , gives error as below. I wonder , can OVS work with Intel - SR-IOV ? Has anyone ever successed about it? Best Regards, OS: Ubuntu 20.04.4 LTS (GNU/Linux 5.13.0-40-lowlatency x86_64) **************** ovs_version: "2.15.2" **************** root@cmp15:/home/ulak# lspci |grep Eth b1:00.0 Ethernet controller: Intel Corporation Ethernet Controller E810-C for QSFP (rev 02) b3:00.0 Ethernet controller: Intel Corporation Ethernet Controller E810-C for QSFP (rev 02) b3:01.0 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:01.1 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:01.2 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:01.3 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:01.4 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:01.5 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:01.6 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:01.7 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:02.0 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:02.1 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:02.2 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:02.3 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:02.4 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:02.5 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:02.6 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) b3:02.7 Ethernet controller: Intel Corporation Ethernet Adaptive Virtual Function (rev 02) **************** root@cmp15:/home/ulak# ethtool -i enp179s0 driver: ice version: 1.8.3 firmware-version: 3.00 0x80008271 1.2992.0 expansion-rom-version: bus-info: 0000:b3:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes **************** nova.conf [pci] passthrough_whitelist = { "address": "*:b1:00.*", "physical_network": null } passthrough_whitelist = { "address": "*:b3:00.*", "physical_network": null } passthrough_whitelist = { "address": "*:b3:01.*", "physical_network": null } passthrough_whitelist = { "address": "*:b3:02.*", "physical_network": null } passthrough_whitelist = { "devname": "enp177s0", "physical_network": null } passthrough_whitelist = { "devname": "enp179s0", "physical_network": null } passthrough_whitelist = { "vendor_id":"8086", "product_id":"1592", "physical_network": null } passthrough_whitelist = { "vendor_id":"8086", "product_id":"1889", "physical_network": null } passthrough_whitelist = { "address": "0000:b3:02.7", "physical_network": null } **************** root@cmp15:/home/ulak# dpdk-devbind.py -s Network devices using kernel driver =================================== 0000:4b:00.0 'MT27710 Family [ConnectX-4 Lx] 1015' if=enp75s0f0 drv=mlx5_core unused=vfio-pci 0000:4b:00.1 'MT27710 Family [ConnectX-4 Lx] 1015' if=enp75s0f1 drv=mlx5_core unused=vfio-pci 0000:4c:00.0 'Ethernet Controller 10G X550T 1563' if=enp76s0f0 drv=ixgbe unused=vfio-pci 0000:4c:00.1 'Ethernet Controller 10G X550T 1563' if=enp76s0f1 drv=ixgbe unused=vfio-pci 0000:98:00.0 'MT2894 Family [ConnectX-6 Lx] 101f' if=enp152s0f0 drv=mlx5_core unused=vfio-pci 0000:98:00.1 'MT2894 Family [ConnectX-6 Lx] 101f' if=enp152s0f1 drv=mlx5_core unused=vfio-pci 0000:b1:00.0 'Ethernet Controller E810-C for QSFP 1592' if=enp177s0 drv=ice unused=vfio-pci 0000:b3:00.0 'Ethernet Controller E810-C for QSFP 1592' if=enp179s0 drv=ice unused=vfio-pci *Active* 0000:b3:01.0 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v0 drv=iavf unused=vfio-pci 0000:b3:01.1 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v1 drv=iavf unused=vfio-pci 0000:b3:01.2 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v2 drv=iavf unused=vfio-pci 0000:b3:01.3 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v3 drv=iavf unused=vfio-pci 0000:b3:01.4 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v4 drv=iavf unused=vfio-pci 0000:b3:01.5 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v5 drv=iavf unused=vfio-pci 0000:b3:01.6 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v6 drv=iavf unused=vfio-pci 0000:b3:01.7 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v7 drv=iavf unused=vfio-pci 0000:b3:02.0 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v8 drv=iavf unused=vfio-pci 0000:b3:02.1 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v9 drv=iavf unused=vfio-pci 0000:b3:02.2 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v10 drv=iavf unused=vfio-pci 0000:b3:02.3 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v11 drv=iavf unused=vfio-pci 0000:b3:02.4 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v12 drv=iavf unused=vfio-pci 0000:b3:02.5 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v13 drv=iavf unused=vfio-pci 0000:b3:02.6 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v14 drv=iavf unused=vfio-pci 0000:b3:02.7 'Ethernet Adaptive Virtual Function 1889' if=enp179s0v15 drv=iavf unused=vfio-pci /var/log/nova/nova-compute.log 2022-05-10 17:00:43.684 706104 INFO nova.virt.libvirt.driver [req-222a65f6-2db1-4dc1-b4c6-a08b016bfd8f 2896d201c5ed44d8813273c48bed5ba3 fe8aaa7d14f44459b6c46e230d538765 - default default] [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] Deletion of /var/lib/nova/instances/e8adc95a-2d7c-40f9-a5ab-bbfa640418b7_del complete 2022-05-10 17:00:43.759 706104 INFO nova.compute.manager [req-222a65f6-2db1-4dc1-b4c6-a08b016bfd8f 2896d201c5ed44d8813273c48bed5ba3 fe8aaa7d14f44459b6c46e230d538765 - default default] [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] Took 3.12 seconds to destroy the instance on the hypervisor. 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [req-222a65f6-2db1-4dc1-b4c6-a08b016bfd8f 2896d201c5ed44d8813273c48bed5ba3 fe8aaa7d14f44459b6c46e230d538765 - default default] [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] Failed to build and run instance: nova.exception.InternalError: Failure running os_vif plugin plug method: Failed to plug VIF VIFHostDevice(active=False,address=fa:16:3e:53:e0:10,dev_address=0000:b3:02.7,dev_type='ethernet',has_traffic_filtering=True,id=7ae16610-d6d9-461a-948f-9922cac62aae,network=Network(c260906e-04c6-4a49-a120-3389c7380247),plugin='ovs',port_profile=VIFPortProfileOVSRepresentor,preserve_on_delete=True). Got error: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] Traceback (most recent call last): 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/os_vif/__init__.py", line 77, in plug 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] plugin.plug(vif, instance_info) 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/vif_plug_ovs/ovs.py", line 305, in plug 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] self._plug_vf(vif, instance_info) 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/vif_plug_ovs/ovs.py", line 269, in _plug_vf 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] pf_ifname = linux_net.get_ifname_by_pci_address( 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/vif_plug_ovs/linux_net.py", line 357, in get_ifname_by_pci_address 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] raise exception.PciDeviceNotFoundById(id=pci_addr) 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] vif_plug_ovs.exception.PciDeviceNotFoundById: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] During handling of the above exception, another exception occurred: 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] Traceback (most recent call last): 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/vif.py", line 696, in _plug_os_vif 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] os_vif.plug(vif, instance_info) 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/os_vif/__init__.py", line 82, in plug 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] raise os_vif.exception.PlugException(vif=vif, err=err) 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] os_vif.exception.PlugException: Failed to plug VIF VIFHostDevice(active=False,address=fa:16:3e:53:e0:10,dev_address=0000:b3:02.7,dev_type='ethernet',has_traffic_filtering=True,id=7ae16610-d6d9-461a-948f-9922cac62aae,network=Network(c260906e-04c6-4a49-a120-3389c7380247),plugin='ovs',port_profile=VIFPortProfileOVSRepresentor,preserve_on_delete=True). Got error: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] During handling of the above exception, another exception occurred: 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] Traceback (most recent call last): 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 2409, in _build_and_run_instance 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] self.driver.spawn(context, instance, image_meta, 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 4172, in spawn 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] self._create_guest_with_network( 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7240, in _create_guest_with_network 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] self._cleanup( 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 227, in __exit__ 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] self.force_reraise() 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 200, in force_reraise 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] raise self.value 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7205, in _create_guest_with_network 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] self.plug_vifs(instance, network_info) 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 1277, in plug_vifs 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] self.vif_driver.plug(instance, vif) 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/vif.py", line 720, in plug 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] self._plug_os_vif(instance, vif_obj) 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/vif.py", line 700, in _plug_os_vif 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] raise exception.InternalError(msg) 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] nova.exception.InternalError: Failure running os_vif plugin plug method: Failed to plug VIF VIFHostDevice(active=False,address=fa:16:3e:53:e0:10,dev_address=0000:b3:02.7,dev_type='ethernet',has_traffic_filtering=True,id=7ae16610-d6d9-461a-948f-9922cac62aae,network=Network(c260906e-04c6-4a49-a120-3389c7380247),plugin='ovs',port_profile=VIFPortProfileOVSRepresentor,preserve_on_delete=True). Got error: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.304 706104 ERROR nova.compute.manager [instance: e8adc95a-2d7c-40f9-a5ab-bbfa640418b7] 2022-05-10 17:00:47.310 706104 ERROR os_vif [req-222a65f6-2db1-4dc1-b4c6-a08b016bfd8f 2896d201c5ed44d8813273c48bed5ba3 fe8aaa7d14f44459b6c46e230d538765 - default default] Failed to unplug vif VIFHostDevice(active=False,address=fa:16:3e:53:e0:10,dev_address=0000:b3:02.7,dev_type='ethernet',has_traffic_filtering=True,id=7ae16610-d6d9-461a-948f-9922cac62aae,network=Network(c260906e-04c6-4a49-a120-3389c7380247),plugin='ovs',port_profile=VIFPortProfileOVSRepresentor,preserve_on_delete=True): vif_plug_ovs.exception.PciDeviceNotFoundById: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.310 706104 ERROR os_vif Traceback (most recent call last): 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/os_vif/__init__.py", line 77, in plug 2022-05-10 17:00:47.310 706104 ERROR os_vif plugin.plug(vif, instance_info) 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/vif_plug_ovs/ovs.py", line 305, in plug 2022-05-10 17:00:47.310 706104 ERROR os_vif self._plug_vf(vif, instance_info) 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/vif_plug_ovs/ovs.py", line 269, in _plug_vf 2022-05-10 17:00:47.310 706104 ERROR os_vif pf_ifname = linux_net.get_ifname_by_pci_address( 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/vif_plug_ovs/linux_net.py", line 357, in get_ifname_by_pci_address 2022-05-10 17:00:47.310 706104 ERROR os_vif raise exception.PciDeviceNotFoundById(id=pci_addr) 2022-05-10 17:00:47.310 706104 ERROR os_vif vif_plug_ovs.exception.PciDeviceNotFoundById: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.310 706104 ERROR os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif During handling of the above exception, another exception occurred: 2022-05-10 17:00:47.310 706104 ERROR os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif Traceback (most recent call last): 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/virt/libvirt/vif.py", line 696, in _plug_os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif os_vif.plug(vif, instance_info) 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/os_vif/__init__.py", line 82, in plug 2022-05-10 17:00:47.310 706104 ERROR os_vif raise os_vif.exception.PlugException(vif=vif, err=err) 2022-05-10 17:00:47.310 706104 ERROR os_vif os_vif.exception.PlugException: Failed to plug VIF VIFHostDevice(active=False,address=fa:16:3e:53:e0:10,dev_address=0000:b3:02.7,dev_type='ethernet',has_traffic_filtering=True,id=7ae16610-d6d9-461a-948f-9922cac62aae,network=Network(c260906e-04c6-4a49-a120-3389c7380247),plugin='ovs',port_profile=VIFPortProfileOVSRepresentor,preserve_on_delete=True). Got error: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.310 706104 ERROR os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif During handling of the above exception, another exception occurred: 2022-05-10 17:00:47.310 706104 ERROR os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif Traceback (most recent call last): 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 2409, in _build_and_run_instance 2022-05-10 17:00:47.310 706104 ERROR os_vif self.driver.spawn(context, instance, image_meta, 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 4172, in spawn 2022-05-10 17:00:47.310 706104 ERROR os_vif self._create_guest_with_network( 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7240, in _create_guest_with_network 2022-05-10 17:00:47.310 706104 ERROR os_vif self._cleanup( 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 227, in __exit__ 2022-05-10 17:00:47.310 706104 ERROR os_vif self.force_reraise() 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 200, in force_reraise 2022-05-10 17:00:47.310 706104 ERROR os_vif raise self.value 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7205, in _create_guest_with_network 2022-05-10 17:00:47.310 706104 ERROR os_vif self.plug_vifs(instance, network_info) 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 1277, in plug_vifs 2022-05-10 17:00:47.310 706104 ERROR os_vif self.vif_driver.plug(instance, vif) 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/virt/libvirt/vif.py", line 720, in plug 2022-05-10 17:00:47.310 706104 ERROR os_vif self._plug_os_vif(instance, vif_obj) 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/virt/libvirt/vif.py", line 700, in _plug_os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif raise exception.InternalError(msg) 2022-05-10 17:00:47.310 706104 ERROR os_vif nova.exception.InternalError: Failure running os_vif plugin plug method: Failed to plug VIF VIFHostDevice(active=False,address=fa:16:3e:53:e0:10,dev_address=0000:b3:02.7,dev_type='ethernet',has_traffic_filtering=True,id=7ae16610-d6d9-461a-948f-9922cac62aae,network=Network(c260906e-04c6-4a49-a120-3389c7380247),plugin='ovs',port_profile=VIFPortProfileOVSRepresentor,preserve_on_delete=True). Got error: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.310 706104 ERROR os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif During handling of the above exception, another exception occurred: 2022-05-10 17:00:47.310 706104 ERROR os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif Traceback (most recent call last): 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 2232, in _do_build_and_run_instance 2022-05-10 17:00:47.310 706104 ERROR os_vif self._build_and_run_instance(context, instance, image, 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 2505, in _build_and_run_instance 2022-05-10 17:00:47.310 706104 ERROR os_vif raise exception.RescheduledException( 2022-05-10 17:00:47.310 706104 ERROR os_vif nova.exception.RescheduledException: Build of instance e8adc95a-2d7c-40f9-a5ab-bbfa640418b7 was re-scheduled: Failure running os_vif plugin plug method: Failed to plug VIF VIFHostDevice(active=False,address=fa:16:3e:53:e0:10,dev_address=0000:b3:02.7,dev_type='ethernet',has_traffic_filtering=True,id=7ae16610-d6d9-461a-948f-9922cac62aae,network=Network(c260906e-04c6-4a49-a120-3389c7380247),plugin='ovs',port_profile=VIFPortProfileOVSRepresentor,preserve_on_delete=True). Got error: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.310 706104 ERROR os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif During handling of the above exception, another exception occurred: 2022-05-10 17:00:47.310 706104 ERROR os_vif 2022-05-10 17:00:47.310 706104 ERROR os_vif Traceback (most recent call last): 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/os_vif/__init__.py", line 110, in unplug 2022-05-10 17:00:47.310 706104 ERROR os_vif plugin.unplug(vif, instance_info) 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/vif_plug_ovs/ovs.py", line 380, in unplug 2022-05-10 17:00:47.310 706104 ERROR os_vif self._unplug_vf(vif) 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/vif_plug_ovs/ovs.py", line 343, in _unplug_vf 2022-05-10 17:00:47.310 706104 ERROR os_vif pf_ifname = linux_net.get_ifname_by_pci_address( 2022-05-10 17:00:47.310 706104 ERROR os_vif File "/usr/lib/python3/dist-packages/vif_plug_ovs/linux_net.py", line 357, in get_ifname_by_pci_address 2022-05-10 17:00:47.310 706104 ERROR os_vif raise exception.PciDeviceNotFoundById(id=pci_addr) 2022-05-10 17:00:47.310 706104 ERROR os_vif vif_plug_ovs.exception.PciDeviceNotFoundById: PCI device 0000:b3:02.7 not found 2022-05-10 17:00:47.310 706104 ERROR os_vif

1 0

[requirements][oslo.log] failure to update to oslo.log===4.8.0
by Matthew Thode 11 May '22

11 May '22

Hi all, It looks like the latest oslo.log update is failing to pass tempest. If anyone is around to look I'd appreciate it. https://review.opendev.org/840630 -- Matthew Thode

5 6

Re: [neutron][opencontrail]Trunk ports doesn't have standard attributes
by Rodolfo Alonso Hernandez 11 May '22

11 May '22

Hi Gleb: Please check the OSC version you are using. The OSC extension for Trunks is in the neutron-pythonclient project. And in particular, the support for the "description" parameter was added in [1]. This is the output in a system using master branches: [2]. In any case, what you need in "contrail-neutron-plugin" is what the API is returning. Don't mix the OSC output and the API. If you execute [3] (as commented in my previous mail), you'll see the "description" parameter (and others). This is what the plugin is retrieving and the information you'll handle. Again, please check the "fields" parameter in order not to select a limited set of fields, discarding what you are looking for. Place a debug line after the API call to check what you are receiving. Regards. [1]https://review.opendev.org/c/openstack/python-neutronclient/+/362614 [2]https://paste.opendev.org/show/bZbnOaKSvGDR6vbR4ITM/ [3]https://paste.opendev.org/show/bh1QD8VqLz4OKMKYBXUa/ On Wed, May 11, 2022 at 6:55 AM Gleb Zimin <gzimin(a)mirantis.com> wrote: > Thanks for reply, Rodolfo. > > When I want to show exact trunk, there is none of standard params. > $ openstack network trunk show trunk1 > +----------------+--------------------------------------+ > | Field | Value | > +----------------+--------------------------------------+ > | admin_state_up | UP | > | id | 96babd03-8d5c-4b80-9118-b5e0a0e8d98d | > | name | trunk1 | > | port_id | b61ac310-35a6-41b6-9af1-8c25f73dec06 | > | project_id | 2923ed63b7934e4b89ce60bfe78dfd87 | > | status | DOWN | > | sub_ports | | > | tenant_id | 2923ed63b7934e4b89ce60bfe78dfd87 | > +----------------+--------------------------------------+ > > Also, if I want to set description to the trunk, I get this: > $ openstack network trunk set trunk1 --description test > Failed to set trunk 'trunk1': Unrecognized attribute(s) 'description' > Neutron server returns request_ids: > ['req-1aca1b69-fa75-466d-aef9-eb0786463555'] > > This request fails on neutron side, it appears before request proceeded on > the contrail-neutron-plugin side. > > https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/attrib… > > On Fri, May 6, 2022 at 7:13 PM Rodolfo Alonso Hernandez < > ralonsoh(a)redhat.com> wrote: > >> Hello Gleb: >> >> The OC plugin is using the Neutron API to execute operations on the >> server. The "get_trunk" method calls "_get_resource" [1]. I've tested the >> Neutron API and this is what you get from the API: [2]. All standard >> attributes are returned. >> >> Maybe this could be related to the "fields" parameter you are passing in >> the method [3]. Check if you are filtering the API call and only retrieving >> a certain subset of fields. >> >> Regards. >> >> [1] >> https://gerrit.tungsten.io/r/gitweb?p=tungstenfabric/tf-neutron-plugin.git;… >> [2]https://paste.opendev.org/show/bh1QD8VqLz4OKMKYBXUa/ >> [3] >> https://gerrit.tungsten.io/r/gitweb?p=tungstenfabric/tf-neutron-plugin.git;… >> >> On Fri, May 6, 2022 at 4:35 PM Gleb Zimin <gzimin(a)mirantis.com> wrote: >> >>> Environment: Openstack Victoria, OpenContrail (TungstenFabric) R2011. >>> Problem: Trunk ports doesn't have standard attributes such as >>> description, timestamp. >>> I have an environment where core plugin is OpenContrail. OpenContrail >>> has tf-neutron-plugin for proper work with neutron. There is TrunkPlugin, >>> that proxies all trunk-related request to the OpenContrail backend. Here is >>> the link for this plugin. >>> https://gerrit.tungsten.io/r/gitweb?p=tungstenfabric/tf-neutron-plugin.git;… >>> According to the openstack documentation: Resources that inherit from >>> the HasStandardAttributes DB class can automatically have the extensions >>> written for standard attributes (e.g. timestamps, revision number, etc) >>> extend their resources by defining the ‘api_collections’ on their model. >>> These are used by extensions for standard attr resources to generate the >>> extended resources map. >>> As I understood, it works only for plugins, which using Openstack >>> database. For example, openstack native trunk plugin has models.py file >>> where we can see this inheritance. >>> https://github.com/openstack/neutron/blob/master/neutron/services/trunk/mod… >>> In case of OpenContrail+OpenStack Trunk plugin only redirect requests. >>> What can I do to make Contrail Trunk plugin works in the same way? >>> I'll appreciate any help. Thanks in advance. >>> >>

1 0

[all][tc][policy][heat][cinder] Continuing the RBAC PTG discussion + policy pop-up meeting new time
by Ghanshyam Mann 11 May '22

11 May '22

Hello Everyone, As we said in PTG about continuing the RBAC discussion on open questions (currently from Heat and Cinder), we are scheduling the call on April 26 Tuesday from 14:30-15:00 UTC. And we will use the same time for the policy-popup team meeting every alternate Tuesday to answer RBAC queries from any projects. Meeting Details: - https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… Agenda (you can add for this or coming meetings) - https://etherpad.opendev.org/p/rbac-zed-ptg#L97 -gmann

1 2

[neutron] CI meeting agenda - 10th May
by Slawek Kaplonski 10 May '22

10 May '22

Hi, It's just gentle reminder that we will have Neutron CI meeting today at 1500 UTC. Agenda for the meeting is at [1]. This will be video meeting [2]. [1] https://etherpad.opendev.org/p/neutron-ci-meetings[1] [2] https://meetpad.opendev.org/neutron-ci-meetings -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://etherpad.opendev.org/p/neutron-ci-meetings

1 0

Hi, Nice to meet you, I am very happly to find faimly.
by 朱超 10 May '22

10 May '22

Hi, Nice to meet you, I am very happly to find faimly.

1 0

Hi, I am very happy to meet all of you. I hope to exchange more knowledge about openstack with you.
by Tom NewChao 10 May '22

10 May '22

I am very happy to meet all of you. I hope to exchange more knowledge about openstack with you.

1 0

Hi, Nice to meet you, I am very happly to find faimly.
by 朱超 10 May '22

10 May '22

Hi, Nice to meet you, I am very happly to find faimly.

1 0

Neutron + OVN raft cluster
by Tiago Pires 10 May '22

10 May '22

Hi all, I was checking the mail list history and this thread https://mail.openvswitch.org/pipermail/ovs-discuss/2018-March/046438.html caught my attention about raft ovsdb clustering. In my setup (OVN 20.03 and Openstack Ussuri) on the ovn-controller we have configured the ovn-remote="tcp:10.2X.4X.4:6642,tcp:10.2X.4X.68:6642,tcp:10.2X.4X.132:6642" with the 3 OVN central member that they are in cluster mode. Also on the neutron ML2 side: [ovn] ovn_native_dhcp = True ovn_nb_connection = tcp:10.2X.4X.4:6641,tcp:10.2X.4X.68:6641,tcp:10.2X.4X.132:6641 ovn_sb_connection = tcp:10.2X.4X.4:6642,tcp:10.2X.4X.68:6642,tcp:10.2X.4X.132:6642 We are experiencing an issue with Neutron when the OVN leader decide to take a snapshot and by design another member became leader(more less every 8 minutes): 2022-05-05T16:57:42.135Z|17401|raft|INFO|Transferring leadership to write a snapshot. ovs-appctl -t /var/run/ovn/ovnsb_db.ctl cluster/status OVN_Southbound 4a03 Name: OVN_Southbound Cluster ID: ca74 (ca744caf-40cd-4751-a2f2-86e35ad6541c) Server ID: 4a03 (4a0328dc-e9a4-495e-a4f1-0a0340fc6d19) Address: tcp:10.2X.4X.132:6644 Status: cluster member Role: leader Term: 1912 Leader: self Vote: self Election timer: 10000 Log: [497643, 498261] Entries not yet committed: 0 Entries not yet applied: 0 Connections: ->3d6c ->4ef0 <-3d6c <-4ef0 Servers: 4a03 (4a03 at tcp:10.2X.4X.132:6644) (self) next_index=497874 match_index=498260 3d6c (3d6c at tcp:10.2X.4X.68:6644) next_index=498261 match_index=498260 4ef0 (4ef0 at tcp:10.2X.4X.4:6644) next_index=498261 match_index=498260 As I understood the tcp connections from the Neutron (NB) and ovn-controllers (SB) to OVN Central are established only with the leader: #OVN central leader $ netstat -nap | grep 6642| more tcp 0 0 0.0.0.0:6642 0.0.0.0:* LISTEN - tcp 0 0 10.2X.4X.132:6642 10.24.40.17:47278 ESTABLISHED - tcp 0 0 10.2X.4X.132:6642 10.24.40.76:36240 ESTABLISHED - tcp 0 0 10.2X.4X.132:6642 10.2X.4X.17:47280 ESTABLISHED - tcp 0 0 10.2X.4X.132:6642 10.2X.4X.6:43102 ESTABLISHED - tcp 0 0 10.2X.4X.132:6642 10.2X.4X.75:58890 ESTABLISHED - tcp 0 0 10.2X.4X.132:6642 10.2X.4X.6:43108 ESTABLISHED - tcp 0 0 10.2X.4X.132:6642 10.2X.4X.17:47142 ESTABLISHED - tcp 0 0 10.2X.4X.132:6642 10.2X.4X.71:48808 ESTABLISHED - tcp 0 0 10.2X.4X.132:6642 10.2X.4X.17:47096 ESTABLISHED - #OVN follower 2 $ netstat -nap | grep 6642 tcp 0 0 0.0.0.0:6642 0.0.0.0:* LISTEN - tcp 0 0 10.2X.4X.4:6642 10.2X.4X.76:57256 ESTABLISHED - tcp 0 0 10.2X.4X.4:6642 10.2X.4X.134:54026 ESTABLISHED - tcp 0 0 10.2X.4X.4:6642 10.2X.4X.10:34962 ESTABLISHED - tcp 0 0 10.2X.4X.4:6642 10.2X.4X.6:49238 ESTABLISHED - tcp 0 0 10.2X.4X.4:6642 10.2X.4X.135:59972 ESTABLISHED - tcp 0 0 10.2X.4X.4:6642 10.2X.4X.75:40162 ESTABLISHED - tcp 0 0 10.2X.4X.4:39566 10.2X.4X.132:6642 ESTABLISHED - #OVN follower 3 netstat -nap | grep 6642 tcp 0 0 0.0.0.0:6642 0.0.0.0:* LISTEN - tcp 0 0 10.2X.4X.68:6642 10.2X.4X.70:40750 ESTABLISHED - tcp 0 0 10.2X.4X.68:6642 10.2X.4X.11:49718 ESTABLISHED - tcp 0 0 10.2X.4X.68:45632 10.2X.4X.132:6642 ESTABLISHED - tcp 0 0 10.2X.4X.68:6642 10.2X.4X.16:44816 ESTABLISHED - tcp 0 0 10.2X.4X.68:6642 10.2X.4X.7:45216 ESTABLISHED The issue that we are experiencing is on the neutron-server that disconnects when there is the ovn leader change (due snapshot like each 8 minutes) and reconnects to the next leader. It breaks the Openstack API when someone is trying to create a VM at the same time. First, is my current configuration correct? Should the leader change and break the neutron side? Or is there some missing configuration? I was wondering if it is possible to use a LB with VIP and this VIP balance the connections to the ovn central members and I would reconfigure on the neutron side only with the VIP and also on the ovs-controllers. Does that make sense? Thank you. Regards, Tiago Pires

4 5

[venus] Yoga tarball is still missing
by Radosław Piliszek 10 May '22

10 May '22

Dear Venus team, The Yoga tarball is still missing. [1] As we are releasing Kolla now, we are forced to temporarily exclude Venus from the Yoga release. [1] https://tarballs.opendev.org/openstack/venus/ Kind regards, -yoctozepto

3 2

[skyline] SSO support
by Martin Chlumsky 10 May '22

10 May '22

Hello, We are evaluating Skyline and one major blocker is Single sign-on (SSO) support (we currently federate Keystone/Horizon with AzureAD). I searched through the git repositories and couldn't find any relevant mention of SSO or federation (openidc or saml). Are there plans to support this feature (or is it supported and I just missed it somehow)? Thank you, Martin

2 2

[TripleO] Tear down of Train centOS 7 check jobs and integration line
by Ronelle Landy 09 May '22

09 May '22

Hello All, We have been running check/gate testing and integration lines for the Train release on both CentOS7 and CentOS 8. Following the work on CentOS 9 and the longevity of the Train release, we proposed removing the CentOS 7 Train jobs and building/testing changes to this release on CentOS 8 only. We floated this proposal with some interested parties and received no objections so we are beginning work on this tear down. We anticipate that removing the CentOS 7 jobs will allow patches to merge quicker and will free up resources for future work. Please respond if you have any questions or concerns. Thanks, Ronelle (for the TripleO CI team)

2 2

[neutron] Bug Deputy Report May 03 - 09
by Elvira Garcia Ruiz 09 May '22

09 May '22

Hi, I was the bug deputy last week. Find the summary below: High: ------- - [OVN] Add support for Baremetal provisioning with ML2/OVN https://bugs.launchpad.net/neutron/+bug/1971431 Proposed fix: https://review.opendev.org/c/openstack/neutron/+/840287 - [neutron][api] test_log_deleted_with_corresponding_security_group failing randomly https://bugs.launchpad.net/neutron/+bug/1971569 Unassigned - [FT] Error in "test_virtual_port_host_update" https://bugs.launchpad.net/neutron/+bug/1971672 Unassigned Medium: ----------- - [api] add port_forwarding_id when list floatingip https://bugs.launchpad.net/neutron/+bug/1971646 Fix proposed: https://review.opendev.org/c/openstack/neutron/+/840565 RFE: ------- - [RFE][fwaas][OVN]support l3 firewall for ovn driver https://bugs.launchpad.net/neutron/+bug/1971958 Invalid: --------- - [Neutron][OpenContrail]Trunk ports don't have standard attributes. https://bugs.launchpad.net/neutron/+bug/1971697 Looks like a request for help with an external plugin, I redirected them to the openstack discuss mailing list since I have no idea of how the OpenContrail driver works. Undecided: --------------- - evacuation failure causes POST_FAILURE in nova-ovs-hybrid-plug job https://bugs.launchpad.net/nova/+bug/1971563 I think we might not need to do anything else regarding this bug from the Neutron side, I asked Sean to be sure just in case. Kind regards! Elvira

1 0

[ops][octavia][neutron] Distributed Virtual Routing: Floating IPs attached to virtual IP addresses are assigned on network nodes
by Jan Horstmann 09 May '22

09 May '22

Hello! When we initially deployed openstack we thought that using distributed virtual routing with ml2/ovs-dvr would give us the ability to automatically scale our network capacity with the number of hypervisors we use. Our main workload are kubernetes clusters which receive ingress traffic via octavia loadbancers (configured to use the amphora driver). So the idea was that we could increase the number of loadbalancers to spread the traffic over more and more compute nodes. This would imply that any volume based (distributed) denial of service attack on a single loadbalancer would just saturate a single compute node and leave the rest of the system functional. We have recently learned that, no matter the loadbalancer topology, a virtual IP is created for it by octavia. This, and probably all virtual IPs in openstack, are reserved by an unbound and disabled port and then set as an allowed address pair on any server's port which might hold it. Up to this point our initial assumption should be true, as the server actually holding the virtual IP would reply to any ARP requests and thus any traffic should be routed to the node with the virtual machine of the octavia amphora. However, we are using our main provider network as a floating IP pool and do not allow direct port creation. When a floating IP is attached to the virtual IP it is assigned to the SNAT router namespace on a network node. Naturally in high traffic or even (distributed) denial of service situations the network node might become a bottleneck. A situation we thought we could avoid by using distributed virtual routing in the first place. This leads me to a rabbit hole of questions I hope someone might be able to help with: Is the assessment above correct or am I missing something? If it is correct, do we have any other options than vertically scaling our network nodes to handle traffic? Do other ml2 drivers (e.g. OVN) handle this scenario differently? If our network nodes need to handle most of the traffic anyway, do we still have any advantage using distributed virtual routing? Especially when considering the increased complexity compared to a non- distributed setup? Has anyone ever explored non-virtual IP based high availability options like e.g. BGP multipathing in a distributed virtual routing scenario? Any input is highly appreciated. Regards, Jan

3 3

Glance browser error
by Derek O keeffe 09 May '22

09 May '22

Hi all, Second mail about this issue. I'm getting the following error in the chrome console: Refused to connect to 'https://10.xx.xx.xxx:9292/v2/images/f7df36f3-33d8-49b6-95b6-b16e95bc3225/fi…' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback I can't upload an image through horizon but I can do it from the cli with no issues. I can't find anything online to help with the issue so any input would be greatly appreciated. Regards,Derek

3 2

[magnum] Proposing Mohammed Naser for core-reviewer
by Spyros Trigazis 09 May '22

09 May '22

Dear all, I would like to nominate Mohammed Naser for core reviewer in the magnum project. Mohammed has a proven knowledge of the codebase with frequent contributions and reviews. Mohammed will be of great help in fast and reliable reviews. Cheers, Spyros

1 0

Data Center Survival in case of Disaster / HW Failure in DC
by KK CHN 09 May '22

09 May '22

List, We are having an old cloud setup with OpenStack Ussuri usng Debian OS, (Qemu KVM ). I know its very old and we can't upgrade to to new versions right now. The Deployment is as follows. A. 3 Controller in (cum compute nodes . VMs are running on controllers too..) in HA mode. B. 6 separate Compute nodes C. 3 separate Storage node with Ceph RBD Question is 1. In case of any Sudden Hardware failure of one or more controller node OR Compute node OR Storage Node what will be the immediate redundant recovery setup need to be employed ? 2. In case H/W failure our recovery need to as soon as possible. For example less than30 Minutes after the first failure occurs. 3. Is there setup options like a hot standby or similar setups or what we need to employ ? 4. To meet all RTO (< 30 Minutes down time ) and RPO(from the exact point of crash all applications and data must be consistent) . 5. Please share your thoughts for reliable crash/fault resistance configuration options in DC. We have a remote DR setup right now in a remote location. Also I would like to know if there is a recommended way to make the remote DR site Automatically up and run ? OR How to automate the service from DR site to meet exact RTO and RPO Any thoughts most welcom. Regards, Krish

4 5

[baremetal-sig][ironic] Tue May 10, 2022, 2pm UTC: "Looking back and forward: The Xena and Zed Cycles for Ironic"
by Arne Wiebalck 09 May '22

09 May '22

Dear all, The Bare Metal SIG will meet tomorrow Tue May 10, 2022, 2pm UTC featuring a topic of the day presentation by Ironic PTL Iury Gregory: "Looking back and forward: The Xena and Zed Cycles for Ironic" Everyone is welcome, all details on how to join can be found on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Hope to see you there! Arne -- Arne Wiebalck CERN IT

1 0

[all][tc] What's happening in Technical Committee: summary May 6th, 22: Reading: 5 min
by Ghanshyam Mann 07 May '22

07 May '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on May 5. Most of the meeting discussions are summarized in this email. Meeting summary logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-05-15.00.log.html As it was a video call, the full recording is here @https://www.youtube.com/watch?v=kJdoWcBiMuY&t=205s * Next TC weekly meeting will be on May 12 Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by May 11. 2. What we completed this week: ========================= * Add the cinder-three-par charm to Openstack charms[2] * Update milestones for FIPS goal[3] * Add gmann to oslo tact-sig liaison[4] 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[5], we have started the many items. Open Reviews ----------------- * Nine open reviews for ongoing activities[6]. CFN overview from Jie Niu, China Mobile Research Institute ----------------------------------------------------------------------- As you might have seen CFN proposal on ML[7], China Mobile team(Yu and Jie) joined the TC meeting and presented the CFN idea, architecture, and roadmap in detail. We had a few question-answer at the end. As the discussion is going on between China Mobile team and the Foundation, TC did not take any decision on being CFN as SIG in OpenStack or not. We are open to ideas coming from the discussion with Foundation. 'tick' 'tock' release cadence open items ---------------------------------------------- We are discussing two things here: 1. release notes strategy: This is not concluded yet but the discussion point is how we should make tock release notes noticeable in the next tick release for operators upgrading to tick-tick release? Whether we should copy the key deprecated/upgrade release notes or use like or mention about reading the previous tock release notes if you upgrading from tick->tick? We will continue the discussion in next meeting and conclude. 2. tick tock name using as per legal check >From foundation legal checks, it seems it is not so clear how we should use tick or tock or better we should not use these names, discussion is on gerrit[8]. We discussed a few ideas about using SLU|SLURP (Skip level upgrade release process) but it is not agreed upon by all the TC members. We are stuck with the same "horror naming" show in this too as we are in release naming. We are open to ideas and if you have any better ideas, feel free to add them in Gerrit review[8] Improve project governance --------------------------------- As discussed in PTG (yoga and zed) we are going to try a new framework "Technical-preview" to catch the inactive project or new project moving towards the OpenStack way. Slawek has the proposal up and ready for review[9]. Change OpenStack release naming policy proposal ----------------------------------------------------------- No concrete update on this than what we are discussing on ML[10] and Gerrit[11]. Migration from old ELK service to new Dashboard ----------------------------------------------------------- The new dashboard[12] is ready to use, we encourage community members to use it and provide feedback if any. We discussed the e-r service and repo maintenance. Ananya from tripleO team joined the meeting and they are ok to merge the rdo branch with master. Once that is done we will figure out where we can host this service, Dainel has some ideas about it and will continue the discussion in the TC channel or meeting. Consistent and Secure Default RBAC ------------------------------------------- We had our weekly call on Tuesday 3rd May and discussed the need for 'service' role. There are points that we should not make 'service' role as a light admin but at the same time, it is needed for the inter-service communication. Discussion still going on and we will continue it next Tuesday's call along with heat discussion. Notes are in etherpad[13] and the next meeting details are in wiki page [14], FIPs community-wide goal ------------------------------- Ade proposal of the updated milestone has been merged and goal selection proposal is up[15]. 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[16]. Feel free to check and provide feedback. Zed cycle Leaderless projects ---------------------------------- No updates on this. Only Adjutant project is leaderless/maintainer-less. We will check Adjutant's the situation again on ML and hope Braden will be ready with their company side permission[17]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[18]. Project updates ------------------- * None 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[19]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [20] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/837781 [3] https://review.opendev.org/c/openstack/governance/+/838601 [4] https://review.opendev.org/c/openstack/governance/+/840351 [5] https://etherpad.opendev.org/p/tc-zed-tracker [6] https://review.opendev.org/q/projects:openstack/governance+status:open [7] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028345.ht… [8] https://review.opendev.org/c/openstack/governance/+/840354 [9] https://review.opendev.org/c/openstack/governance/+/839880 [10] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028354.ht… [11] https://review.opendev.org/c/openstack/governance/+/839897 [12] http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028346.ht… [13] https://etherpad.opendev.org/p/rbac-zed-ptg#L103 [14] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… [15] https://review.opendev.org/c/openstack/governance/+/840920 [16] https://review.opendev.org/c/openstack/governance/+/836888 [17] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.ht… [18] https://etherpad.opendev.org/p/zuul-config-error-openstack [19] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [20] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

Openstack OSA Latest - Glance
by Derek O keeffe 06 May '22

06 May '22

Hi all, Could any one tell me if they have come across this error (in the chrome console) while trying to create a new image in horizon: Refused to connect to 'https://10.37.110.104:9292/v2/images/3e553b60-0a6c-48a0-b855-60088839201e/f…' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback If so, any advice? I can scp the image file to the utility container and upload it from there no problem. Also, journalctl -f on the glance container shows nothing when the process fails. We have set the internal and external lb vip addresses differently but both are on the same subnet (internal) as it's an in house deploy. So two addresses on the mgmt interface to be precise. Maybe that's causing an issue. Regards,Derek

2 1

[manila] Zed cycle bug squash
by Carlos Silva 06 May '22

06 May '22

Greetings Zorillas and interested stackers! As mentioned in the previous weekly meetings, we will soon be meeting for the first bugsquash of the Zed release! The event will be held from May 2nd to May 6th, providing an extended contribution window. May 2nd 15:00 - 16:00 UTC - Kick off May 5th 15:00 - 16:00 UTC - Mid term checkpoint (we won't have our regular Manila meeting on this day) May 6th 15:00 - 15:30 UTC - Wrap Up We will use a meetpad for these meetings [1]. The main idea of this event is to go over the list of stale bugs and act on them, either seeing if they are incomplete or invalid at this point or working on them. The stale bugs list will be available on [2]. [1] https://meetpad.opendev.org/ManilaZed1Bugsquash [2] https://ethercalc.openstack.org/1nesczgjufb9 See you next week! Thank you, carloss

1 1

[nova][placement] Incomplete Consumers return negative value after upgrade
by Jan Wasilewski 06 May '22

06 May '22

Hi, after an upgrade from Stein to Train, I hit an issue with negative value during upgrade check for placement: # placement-status upgrade check+------------------------------------------------------------------+| Upgrade Check Results |+------------------------------------------------------------------+| Check: Missing Root Provider IDs || Result: Success || Details: None |+------------------------------------------------------------------+| Check: Incomplete Consumers || Result: Warning || Details: There are -20136 incomplete consumers table records for || existing allocations. Run the "placement-manage db || online_data_migrations" command. |+------------------------------------------------------------------+ Seems that negative value is a result that I get such values from tables consumer and allocations: mysql> select count(id), consumer_id from allocations group by consumer_id;...1035 rows in set (0.00 sec) mysql> select count(*) from consumers;+----------+| count(*) |+----------+| 21171 |+----------+1 row in set (0.04 sec) Unfortunately such warning cannot be solved by execution of suggested command( placement-manage db online_data_migrations) as it seems it adds records to consumers table - not to allocations, which looks like to be a problem here. I was following recommendations from this discussion: http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018536… but unfortunately it doesn't solve the issue(even not changing a negative value). I'm just wondering if I skipped something important and you can suggest some (obvious?) solution. Thank you in advance for your time and help. Best regards, Jan

2 3

[Kolla][CloudKitty] Wrong version in ubuntu-binary-cloudkitty-processor:yoga
by Rafael Weingärtner 06 May '22

06 May '22

Hello guys, I was checking the upstream containers for CloudKittty for Yoga release; and, I noticed that the CloudKitty containers are using version 11.0.1, which is not the Yoga version of CloudKitty. I also checked Xena, and the same thing happens there. Do we need to define these component versions somewhere else for the Kolla containers that are built upstream? -- Rafael Weingärtner

3 4

[Tripleo] Support of PTP in Openstack Train
by Anirudh Gupta 06 May '22

06 May '22

Hi Team, I have installed Undercloud with Openstack Train Release successfully. I need to enable PTP service while deploying the overcloud for which I have included the service in my deployment openstack overcloud deploy --templates \ -n /home/stack/templates/network_data.yaml \ -r /home/stack/templates/roles_data.yaml \ -e /home/stack/templates/environment.yaml \ -e /home/stack/templates/environments/network-isolation.yaml \ -e /home/stack/templates/environments/network-environment.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml \ * -e /usr/share/openstack-tripleo-heat-templates/environments/services/ptp.yaml \* -e /home/stack/templates/ironic-config.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \ -e /home/stack/containers-prepare-parameter.yaml But it gives the following error 2022-05-06 11:30:10.707655 | 5254001f-9952-7fed-4a6d-000000002fde | FATAL | Wait for puppet host configuration to finish | overcloud-controller-0 | error={"ansible_job_id": "5188783868.37685", "attempts": 3, "changed": true, "cmd": "set -o pipefail; puppet apply --modulepath=/etc/puppet/modules:/opt/stack/puppet-modules:/usr/share/openstack-puppet/modules --detailed-exitcodes --summarize --color=false /var/lib/tripleo-config/puppet_step_config.pp 2>&1 | logger -s -t puppet-user", "delta": "0:00:04.440700", "end": "2022-05-06 11:30:12.685508", "failed_when_result": true, "finished": 1, "msg": "non-zero return code", "rc": 1, "start": "2022-05-06 11:30:08.244808", "stderr": "<13>May 6 11:30:08 puppet-user: Warning: The function 'hiera' is deprecated in favor of using 'lookup'. See https://puppet.com/docs/puppet/6.14/deprecated_language.html\n<13>May 6 11:30:08 puppet-user: (file & line not available)\n<13>May 6 11:30:08 puppet-user: Warning: /etc/puppet/hiera.yaml: Use of 'hiera.yaml' version 3 is deprecated. It should be converted to version 5\n<13>May 6 11:30:08 puppet-user: (file: /etc/puppet/hiera.yaml)\n<13>May 6 11:30:08 puppet-user: Warning: Undefined variable '::deploy_config_name'; \n<13>May 6 11:30:08 puppet-user: (file & line not available)\n<13>May 6 11:30:08 puppet-user: Warning: Unknown variable: '::deployment_type'. (file: /etc/puppet/modules/tripleo/manifests/profile/base/database/mysql/client.pp, line: 89, column: 8)\n<13>May 6 11:30:08 puppet-user: error: Could not connect to controller: Connection refused\n<13>May 6 11:30:08 puppet-user: Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::tripleo::profile::base::time::ptp for overcloud-controller-0.localdomain (file: /var/lib/tripleo-config/puppet_step_config.pp, line: 41, column: 1) on node overcloud-controller-0.localdomain", "stderr_lines": ["<13>May 6 11:30:08 puppet-user: Warning: The function 'hiera' is deprecated in favor of using 'lookup'. See https://puppet.com/docs/puppet/6.14/deprecated_language.html", "<13>May 6 11:30:08 puppet-user: (file & line not available)", "<13>May 6 11:30:08 puppet-user: Warning: /etc/puppet/hiera.yaml: Use of 'hiera.yaml' version 3 is deprecated. It should be converted to version 5", "<13>May 6 11:30:08 puppet-user: (file: /etc/puppet/hiera.yaml)", "<13>May 6 11:30:08 puppet-user: Warning: Undefined variable '::deploy_config_name'; ", "<13>May 6 11:30:08 puppet-user: (file & line not available)", "<13>May 6 11:30:08 puppet-user: Warning: Unknown variable: '::deployment_type'. (file: /etc/puppet/modules/tripleo/manifests/profile/base/database/mysql/client.pp, line: 89, column: 8)", "<13>May 6 11:30:08 puppet-user: error: Could not connect to controller: Connection refused", "<13>May 6 11:30:08 puppet-user: *Error: Evaluation Error: Error while evaluating a Function Call, Could not find class ::tripleo::profile::base::time::ptp for overcloud-controller-0.localdomain (file: /var/lib/tripleo-config/puppet_step_config.pp, line: 41, column: 1) on node* overcloud-controller-0.localdomain"], "stdout": "", "stdout_lines": []} Can someone please help in resolving this issue? Regards Anirudh Gupta

1 0

[TripleO] gate blocker please hold rechecks tripleo-heat-templates (openstack-tox-tht)
by Marios Andreou 06 May '22

06 May '22

Hello we have a gate blocker for tripleo-heat-templates affecting master and stable/wallaby at https://bugs.launchpad.net/tripleo/+bug/1971703 If you have failing openstack-tox-tht please hold recheck until we find some resolution thank you! marios

2 1

[charms] OpenStack Charms Yoga release is now available
by Peter Matulis 06 May '22

06 May '22

Version naming for OpenStack Charms releases has changed from being time-based (YY.MM) to one that is based on the newly-supported OpenStack release. Individual charms will also no longer be developed to work with every supported OpenStack release. Instead, each charm will leverage Charmhub tracks, each of which will determine a supported scenario. See the following resource for details: https://docs.openstack.org/charm-guide/latest/project/charm-delivery.html --- The Yoga release of the OpenStack Charms is now available. This release brings several new features to the existing OpenStack Charms deployments for Queens, Stein, Ussuri, Victoria, Wallaby, Xena, Yoga and many stable combinations of Ubuntu + OpenStack. Please see the release notes for full details: https://docs.openstack.org/charm-guide/latest/release-notes/yoga.html == Highlights == * OpenStack Yoga OpenStack Yoga is now supported on Ubuntu 20.04 LTS (via UCA) and Ubuntu 22.04 LTS natively. * vTPM support Virtual Trusted Platform Module (vTPM) devices are now supported on Compute nodes. TPM can be used to enhance computer security and privacy. * Glance storage backend: Cinder iSCSI/FC Cinder iSCSI/FC is now supported as a storage backend for Glance. * Cloud operational improvements Improvements have been implemented at the operational level through the addition of actions and configuration options to the current set of stable charms. * Tech-preview charms This release comes with three new charms, all currently in tech-preview: - cinder-nimblestorage Provides a NimbleStorage storage backend for Cinder. - cinder-solidfire Provides a SolidFire storage backend for Cinder. - nova-compute-nvidia-vgpu Provides Nvidia vGPU support for Nova. * Documentation updates Documentation highlights include: - More cloud operations - Improvements to the upgrade pages - Tutorial for deploying OpenStack - Pages for vTPM and vGPU - Charmhub information - Guidelines and resources for software and documentation contributions == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on OFTC or in the Juju user forum: https://discourse.charmhub.io/c/juju/ == Thank you == Lots of thanks to the 55 contributors below who squashed 120 bugs, enabled new features, and improved the documentation! Alex Kavanagh Andy Wu Anna Savchenko Aqsa Malik Arif Ali Aurelien Lourot Bartlomiej Poniecki-Klotz Bayani Carbone Billy Olsen Chris MacNaughton Corey Bryant Cornellius Metto David Ames Diko Parvanov Dmitrii Shcherbakov Edin Sarajlic Edward Hope-Morley Erlon R. Felipe Reyes Frode Nordahl Gustavo Sanchez Hemanth Nakkina Hervé Beraud James Lin James Page James Troup James Vaughn Jeff Hillman jiangzhilin Joe Guo Jorge Merlino José Pekkarinen Juan Pablo Liam Young Linda Guo Luciano Lo Giudice Marcin Wilk Martin Kalcok Nicholas Malacarne Nobuto Murata Olivier Dufour-Cuvillier Paul Goins Pedro Castillo Peter Matulis Robert Gildein Rodrigo Barbieri Samuel Walladge Shayan Patel Simon Deziel Tianqi Xiao Yoshi Kadokawa Zeeshan Ali Zhang Hua Dongdong Tao Tiago Pasqualini -- OpenStack Charms Team

1 0

[neutron] Drivers meeting - Friday 6.5.2022 - cancelled
by Lajos Katona 06 May '22

06 May '22

Hi Neutron Drivers! Due to the lack of agenda, let's cancel tomorrow's drivers meeting. See You on the meeting next week. Lajos Katona (lajoskatona)

1 0

Magnum metrics-server not working
by Oliver Weinmann 06 May '22

06 May '22

Hi, Is the metrics-server broken by default in magnum? I tried for several hours to get it running, but running kubectl top nodes fails. Message: failing or missing response from https://10.100.2.4:8443/apis/metrics.k8s.io/v1beta1: Get "https://10.100.2.4:8443/apis/metrics.k8s.io/v1beta1": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) I also googled a lot but only found similar issues for k8s clusters not deployed via magnum. I remembered from my other cluster that I had to enable enable-aggregator-routing=true in kupe-apiserver and --kubelet-insecure-tls for the metrics-server. But this also doesn’t help. Any help would be highly appreciated. Best regards, Oliver

2 3

RE: Data Center Survival in case of Disaster / HW Failure in DC
by CHALANSONNET Stéphane (Acoss) 05 May '22

05 May '22

Hello, First Openstack isnt VMware.Crtiticals applications need to be design with a multiples regions/AZ aware. Best way was two regions , 2 contrôle plane (keystone , Galera cluster on both (not the same) 2 storage system and application spitted on both is the best pratice 😉 You can do also with two AZ but the control plane is share between two AZ (galezra cluster and RabbitMq ) If you are trying to do the same thing as a streched VMware Cluster on a dual-site it's complicated, i you have 3 sites (low latencies <1ms) you can ! 1.In case of any Sudden Hardware failure of one or more controller node OR Compute node OR Storage Node what will be the immediate redundant recovery setup need to be employed ? => You need to splt control plane throught multiples AZ (3 is the best for Galera cluster and RabbitMQ , 2 if you have HA VMware) => Network compute work with keepalived so also need to split them on two AZ/region, you need . Dhcp , Metadata services are also redundancy on multiples network node => compute : HA OpenStack (like VMware HA) seems to work since Wallaby with Masakari . Actually you need to do the job by yourself if you need to failover instances. The storage is also the bggest problem . You need a streched storage that work with Cinder : Ceph can do the job but you also need three site (quorum on monitor need 2 node alives).Netapp solution seems to work well (trident NFS) 2. In case H/W failure our recovery need to as soon as possible. For example less than30 Minutes after the first failure occurs. Galera Cluster and RabbitMq need to be check first With two sites 30mn is really a big challenge, with 3 site it should good ! 3. Is there setup options like a hot standby or similar setups or what we need to employ ? 2 AZ , 2 storage system and application spitted on both is the best pratice 😉 4. To meet all RTO (< 30 Minutes down time ) and RPO(from the exact point of crash all applications and data must be consistent) . Regards, Stéphane Chalansonnet -----Message d'origine----- De : openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Envoyé : jeudi 5 mai 2022 11:56 À : openstack-discuss(a)lists.openstack.org Objet : openstack-discuss Digest, Vol 43, Issue 12 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss or, via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Data Center Survival in case of Disaster / HW Failure in DC (KK CHN) 2. [nova][placement] Incomplete Consumers return negative value after upgrade (Jan Wasilewski) 3. Re: [all][tc][Release Management] Improvements in project governance (Slawek Kaplonski) ---------------------------------------------------------------------- Message: 1 Date: Thu, 5 May 2022 14:46:11 +0530 From: KK CHN <kkchn.in(a)gmail.com> To: openstack-discuss(a)lists.openstack.org Subject: Data Center Survival in case of Disaster / HW Failure in DC Message-ID: <CAKgGyB_UmDG+TknDaYLGAuyOnxY8ipSF3qC4tS90T0zHzu6fZg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" List, We are having an old cloud setup with OpenStack Ussuri usng Debian OS, (Qemu KVM ). I know its very old and we can't upgrade to to new versions right now. The Deployment is as follows. A. 3 Controller in (cum compute nodes . VMs are running on controllers too..) in HA mode. B. 6 separate Compute nodes C. 3 separate Storage node with Ceph RBD Question is 1. In case of any Sudden Hardware failure of one or more controller node OR Compute node OR Storage Node what will be the immediate redundant recovery setup need to be employed ? 2. In case H/W failure our recovery need to as soon as possible. For example less than30 Minutes after the first failure occurs. 3. Is there setup options like a hot standby or similar setups or what we need to employ ? 4. To meet all RTO (< 30 Minutes down time ) and RPO(from the exact point of crash all applications and data must be consistent) . 5. Please share your thoughts for reliable crash/fault resistance configuration options in DC. We have a remote DR setup right now in a remote location. Also I would like to know if there is a recommended way to make the remote DR site Automatically up and run ? OR How to automate the service from DR site to meet exact RTO and RPO Any thoughts most welcom. Regards, Krish -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> ------------------------------ Message: 2 Date: Thu, 5 May 2022 11:31:16 +0200 From: Jan Wasilewski <finarffin(a)gmail.com> To: openstack-discuss(a)lists.openstack.org Subject: [nova][placement] Incomplete Consumers return negative value after upgrade Message-ID: <CAN4DDNgG=i8tGpPQW2PUXVUp72T9r4CWDdxmfRg-bX8T1eE5AA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, after an upgrade from Stein to Train, I hit an issue with negative value during upgrade check for placement: # placement-status upgrade check+------------------------------------------------------------------+| Upgrade Check Results |+------------------------------------------------------------------+| Check: Missing Root Provider IDs || Result: Success || Details: None |+------------------------------------------------------------------+| Check: Incomplete Consumers || Result: Warning || Details: There are -20136 incomplete consumers table records for || existing allocations. Run the "placement-manage db || online_data_migrations" command. |+------------------------------------------------------------------+ Seems that negative value is a result that I get such values from tables consumer and allocations: mysql> select count(id), consumer_id from allocations group by consumer_id;...1035 rows in set (0.00 sec) mysql> select count(*) from consumers;+----------+| count(*) |+----------+| 21171 |+----------+1 row in set (0.04 sec) Unfortunately such warning cannot be solved by execution of suggested command( placement-manage db online_data_migrations) as it seems it adds records to consumers table - not to allocations, which looks like to be a problem here. I was following recommendations from this discussion: http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018536… but unfortunately it doesn't solve the issue(even not changing a negative value). I'm just wondering if I skipped something important and you can suggest some (obvious?) solution. Thank you in advance for your time and help. Best regards, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> ------------------------------ Message: 3 Date: Thu, 05 May 2022 11:55:32 +0200 From: Slawek Kaplonski <skaplons(a)redhat.com> To: openstack-discuss(a)lists.openstack.org Cc: El?d Ill?s <elod.illes(a)est.tech> Subject: Re: [all][tc][Release Management] Improvements in project governance Message-ID: <3198538.44csPzL39Z@p1> Content-Type: text/plain; charset="utf-8" Hi, On ?roda, 20 kwietnia 2022 13:19:10 CEST El?d Ill?s wrote: > Hi, > > At the very same time at the PTG we discussed this on the Release > Management session [1] as well. To release deliverables without > significant content is not ideal and this came up in previous > discussions as well. On the other hand unfortunately this is the most > feasible solution from release management team perspective especially > because the team is quite small (new members are welcome! feel free to > join the release management team! :)). > > To change to independent release model is an option for some cases, > but not for every project. (It is less clear for consumers what > version is/should be used for which series; Fixing problems that comes > up in specific stable branches, is not possible; testing the > deliverable against a specific stable branch constraints is not > possiblel; etc.) > > See some other comments inline. > > [1] https://etherpad.opendev.org/p/april2022-ptg-rel-mgt#L44 > > El?d > > On 2022. 04. 19. 18:01, Michael Johnson wrote: > > Comments inline. > > > > Michael > > > > On Tue, Apr 19, 2022 at 6:34 AM Slawek Kaplonski<skaplons(a)redhat.com> wrote: > >> Hi, > >> > >> > >> During the Zed PTG sessions in the TC room we were discussing some ideas how we can improve project governance. > >> > >> One of the topics was related to the projects which don't really have any changes in the cycle. Currently we are forcing to do new release of basically the same code when it comes to the end of the cycle. > >> > >> Can/Should we maybe change that and e.g. instead of forcing new release use last released version of the of the repo for new release too? > > In the past this has created confusion in the community about if a > > project has been dropped/removed from OpenStack. That said, I think > > this is the point of the "independent" release classification. > Yes, exactly as Michael says. > >> If yes, should we then automatically propose change of the release model to the "independent" maybe? > > Personally, I would prefer to send an email to the discuss list > > proposing the switch to independent. Patches can sometimes get > > merged before everyone gets to give input. Especially since the > > patch would be proposed in the "releases" project and may not be on > > the team's dashboards. > The release process catches libraries only (that had no merged > change), so the number is not that huge, sending a mail seems to be a fair option. > > (The process says: "Evaluate any libraries that did not have any > change merged over the cycle to see if it is time to transition them > to the independent release model > <https://releases.openstack.org/reference/release_models.html#openstack-rela…>. > Note: client libraries (and other libraries strongly tied to another > deliverable) should generally follow their parent deliverable release > model, even if they did not have a lot of activity themselves).") > >> What would be the best way how Release Management team can maybe notify TC about such less active projects which don't needs any new release in the cycle? That could be one of the potential conditions to check project's health by the TC team. > > It seems like this would be a straight forward script to write given > > we already have tools to capture the list of changes included in a > > given release. > > There are a couple of good signals already for TC to catch inactive > projects, like the generated patches that are not merged, for example: > > https://review.opendev.org/q/topic:reno-yoga+is:open > https://review.opendev.org/q/topic:create-yoga+is:open > https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:ope > n > > (Note that in the past not merged patches caused issues and discussing > with the TC resulted a suggestion to force-merge them to avoid future > issues) > > >> Another question is related to the projects which aren't really active and are broken during the final release time. We had such problem in the last cycle, see [1] for details. Should we still force pushing fixes for them to be able to release or maybe should we consider deprecation of such projects and not to release it at all? > > In the past we have simply not released projects that are broken and > > don't have people actively working on fixing them. It has been a > > signal to the community that if they value the project they need to > > contribute to it. > > Yes, that's a fair point, too, maybe those broken deliverables should > not be released at all. I'm not sure, but that might cause another > issues for release management tooling, though... > > Besides, during our PTG session we came to the conclusion that we need > another step in our process: > * "propose DNM changes on every repository by RequirementsFreeze (5 > weeks before final release) to check that tests are still passing with > the current set of dependencies" > Hopefully this will catch broken things well in advance. > > >> [1]http://lists.openstack.org/pipermail/openstack-discuss/2022-Marc > >> h/027864.html > >> > >> > >> -- > >> > >> Slawek Kaplonski > >> > >> Principal Software Engineer > >> > >> Red Hat > Thx for all inputs in that topic so far. Here is my summary and conclusion of what was said in that thread: * we shouldn't try automatically switch such "inactive" projects to the independent model, and we should continue bumping versions of such projects every cycle as it makes many things easier, * Release Management team will test projects about 5 weeks before final release - that may help us find broken projects which then can be discussed and eventually marked as deprecated to not release broken code finally, * To check potentially inactive projects TC can: * finish script https://review.opendev.org/c/openstack/governance/+/810037[1] and use stats generate by that script to periodically check projects' health, * check projects with no merged generated patches, like: https://review.opendev.org/q/topic:reno-yoga+is:open[2] https://review.opendev.org/q/topic:create-yoga+is:open[3] https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open[4] Feel free to add/change anything in that summary if I missed or misunderstood anything there or if You have any idea about other improvements we can do in that area. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://review.opendev.org/c/openstack/governance/+/810037 [2] https://review.opendev.org/q/topic:reno-yoga+is:open [3] https://review.opendev.org/q/topic:create-yoga+is:open [4] https://review.opendev.org/q/topic:add-xena-python-jobtemplates+is:open -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220505…> ------------------------------ Subject: Digest Footer _______________________________________________ openstack-discuss mailing list openstack-discuss(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss ------------------------------ End of openstack-discuss Digest, Vol 43, Issue 12 *************************************************

1 0

[all][tc][Release Management] Improvements in project governance
by Slawek Kaplonski 05 May '22

05 May '22

Hi, During the Zed PTG sessions in the TC room we were discussing some ideas how we can improve project governance. One of the topics was related to the projects which don't really have any changes in the cycle. Currently we are forcing to do new release of basically the same code when it comes to the end of the cycle. Can/Should we maybe change that and e.g. instead of forcing new release use last released version of the of the repo for new release too? If yes, should we then automatically propose change of the release model to the "independent" maybe? What would be the best way how Release Management team can maybe notify TC about such less active projects which don't needs any new release in the cycle? That could be one of the potential conditions to check project's health by the TC team. Another question is related to the projects which aren't really active and are broken during the final release time. We had such problem in the last cycle, see [1] for details. Should we still force pushing fixes for them to be able to release or maybe should we consider deprecation of such projects and not to release it at all? [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.ht… -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.ht…

4 4

[Kolla-ansible][xena] how to deploy multiple cinder backends?
by wodel youchi 05 May '22

05 May '22

Hi, I want to deploy multiple cinder backends, ceph SSD pool for high performance VMS, ceph SAS pool for normal VMS and NFS share for small VMS and for cinder backup. Could that be done while deploying or it has to be done after the initial deployment? Could you assist me with some examples, sometimes the documentation is not that obvious to understand. Regards.

2 1

[sdk] creating a blank volume with image properties
by John Ratliff 05 May '22

05 May '22

We're standing up a second openstack cluster to do a leapfrog migration upgrade. We are using the same ceph storage backend. I need to create volumes in the new openstack cluster that use the underlying ceph rbd. Currently, we are creating a volume in the new openstack cluster, deleting the rbd created by openstack, and renaming the original rbd to match the new openstack mapping. This process loses the image properties from the original volumes. We are using virtio-scsi for the disk block device, and want to continue doing that in the new cluster. When we create the server using the new volume in the new openstack cluster, it reverts to using virtio-blk (/dev/vda). What can I do to keep using our image properties in the newly created volume? I thought I could just pass volume_image_metadata as an argument to create_volume(), but it doesn't work. I end up with an image that has no image metadata properties. import openstack openstack.enable_logging(debug=False) conn = openstack.connect(cloud="test") v = conn.create_volume( name="testvol", size=5, wait=True, bootable=True, volume_image_metadata={ "hw_scsi_model": "virtio-scsi", "hw_disk_bus": "scsi", "hw_qemu_guest_agent": "yes", "os_require_quiesce": "yes", "hw_rng_model": "virtio", "image_id": "00000000-0000-0000-0000-000000000000", }, ) What can I do to create this openstack volume while preserving my original volume properties? Since we don't care about the image, I thought about creating a blank image that the volume could be based on with those properties, but I'm looking for suggestions. Thanks. --John

2 1