- openstack-discuss - lists.openstack.org

[kolla][neutron] VM is getting the wrong IP, can't contact metadata service
by Chris DiLorenzo 21 Feb '22

21 Feb '22

Hello, I am having a weird issue. I am running openstack Victoria with OVN. Generally, everything is working. I created a VM using a fixed port with an IP of 10.210.64.6. There are no issues with this VM. When I create a new VM, I get this route info: [ 29.363664] cloud-init[564]: ci-info: ++++++++++++++++++++++++++++++++Route IPv4 info++++++++++++++++++++++++++++++++ [ 29.368568] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ [ 29.369945] cloud-init[564]: ci-info: | Route | Destination | Gateway | Genmask | Interface | Flags | [ 29.372441] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ [ 29.376434] cloud-init[564]: ci-info: | 0 | 0.0.0.0 | 10.210.64.1 | 0.0.0.0 | ens3 | UG | [ 29.377820] cloud-init[564]: ci-info: | 1 | 10.210.64.0 | 0.0.0.0 | 255.255.255.192 | ens3 | U | [ 29.380417] cloud-init[564]: ci-info: | 2 | 169.254.169.254 | 10.210.64.6 | 255.255.255.255 | ens3 | UGH | [ 29.384448] cloud-init[564]: ci-info: +-------+-----------------+-------------+-----------------+-----------+-------+ The IP is set correctly, but you can see I am getting a gateway of 10.210.64.6 for the metadata ser. ice. This is preventing the VM from reaching the service so the SSH key is not being added preventing me from logging in. As far as I can tell, there are no error and every VM I build is getting this .6 IP for this route. Thanks, Chris

3 4

[kolla-ansible][manila]Permission denied when using cephfs nfs
by Boxiang Zhu 21 Feb '22

21 Feb '22

Hi all, I have met an issue when I use manila with cephfs nfs backend. Environment Information: - OS: ubuntu 18.04 - OpenStack Version: Train - Kolla-ansible Version: 9.3.2 I used kolla-ansible to deploy my OpenStack environment AIO. Here is the info of my globals.yml as followed: --- kolla_base_distro: "ubuntu" kolla_install_type: "source" openstack_release: "train" kolla_internal_vip_address: "172.16.150.67" network_interface: "ens3" neutron_external_interface: "ens4" enable_haproxy: "no" enable_ceph: "yes" enable_ceph_mds: "yes" enable_ceph_rgw: "yes" enable_ceph_nfs: "yes" enable_cinder: "yes" enable_manila: "yes" enable_manila_backend_cephfs_nfs: "yes" enable_ceph_rgw_keystone: "yes" ceph_osd_store_type: "filestore" I try to use cephfs nfs backend for manila. All containers are running and the services of manila is good. +----+------------------+-------------------+------+---------+-------+----------------------------+ | Id | Binary | Host | Zone | Status | State | Updated_at | +----+------------------+-------------------+------+---------+-------+----------------------------+ | 1 | manila-data | manila | nova | enabled | up | 2022-02-16T03:25:34.000000 | | 2 | manila-scheduler | manila | nova | enabled | up | 2022-02-16T03:25:35.000000 | | 3 | manila-share | manila@cephfsnfs1 | nova | enabled | up | 2022-02-16T03:25:40.000000 | +----+------------------+-------------------+------+---------+-------+----------------------------+ Here is my share type: +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ | ID | Name | visibility | is_default | required_extra_specs | optional_extra_specs | Description | +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ | 265a6637-0322-4c4a-9185-f30f01b96d12 | default_share_type | public | - | driver_handles_share_servers : False | | None | +--------------------------------------+--------------------+------------+------------+-------------------------------------+----------------------+-------------+ When I create a share, error information appears in manila-share.log file: 2022-02-16 09:30:04.615 20 INFO manila.share.manager [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share status 2022-02-16 09:30:04.616 20 DEBUG manila.share.driver [req-b57991af-5355-4202-8543-dc7ff914d919 - - - - -] Updating share stats. _update_share_stats /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/driver.py:1232 2022-02-16 09:30:54.675 20 DEBUG manila.share.drivers.cephfs.driver [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] create_share CEPHFSNFS1 name=449a52a4-f19c-4d1b-b437-7dc2443e040c size=1 share_group_id=None create_share /var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py:262 2022-02-16 09:30:54.682 20 INFO ceph_volume_client [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] create_volume: /volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c2022-02-16 09:30:54.927 20 ERROR manila.share.manager [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] Share instance 449a52a4-f19c-4d1b-b437-7dc2443e040c failed on creation.: cephfs.OSError: error in mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission denied [Errno 13] 2022-02-16 09:30:54.929 20 WARNING manila.share.manager [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] Share instance information in exception can not be written to db because it contains {} and it is not a dictionary.: cephfs.OSError: error in mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission denied [Errno 13] 2022-02-16 09:30:54.955 20 INFO manila.message.api [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] Creating message record for request_id = req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server [req-d2c8ef2a-d3ce-483b-9e39-e5a3d857d72b eaf0e30a92694889aa46ac5a1d4b7a47 37025e7c9ae447c8975e9ef3a4e5d0ff - - -] Exception during message handling: cephfs.OSError: error in mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission denied [Errno 13] 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 656, in _mkdir_p 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server self.fs.stat(subpath) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "cephfs.pyx", line 1257, in cephfs.LibCephFS.stat 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server cephfs.ObjectNotFound: error in stat: volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: No such file or directory [Errno 2] 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server During handling of the above exception, another exception occurred: 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, in _process_incoming 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 274, in dispatch 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", line 187, in wrapped 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server return f(self, *args, **kwargs) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/utils.py", line 568, in wrapper 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server return func(self, *args, **kwargs) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", line 1790, in create_share_instance 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server exception=e) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server self.force_reraise() 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server six.reraise(self.type_, self.value, self.tb) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/six.py", line 693, in reraise 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server raise value 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py", line 1753, in create_share_instance 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server context, share_instance, share_server=share_server) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/cephfs/driver.py", line 272, in create_share 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server mode=self._cephfs_volume_mode) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 677, in create_volume 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server self._mkdir_p(path, mode) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/ceph_volume_client.py", line 658, in _mkdir_p 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server self.fs.mkdir(subpath, mode) 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server File "cephfs.pyx", line 887, in cephfs.LibCephFS.mkdir 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server cephfs.OSError: error in mkdir volumes/_nogroup/449a52a4-f19c-4d1b-b437-7dc2443e040c: Permission denied [Errno 13] 2022-02-16 09:30:54.971 20 ERROR oslo_messaging.rpc.server

3 4

[neutron] Bug deputy - week of 14.02.2022
by Slawek Kaplonski 21 Feb '22

21 Feb '22

Hi, I was bug deputy last week. It was very quiet week in terms of bugs in Neutron. Here is the summary: ## Critical https://bugs.launchpad.net/neutron/+bug/1961112 - [ovn] overlapping security group rules break neutron-ovn-db-sync-util - fix already proposed long time ago: https://review.opendev.org/c/openstack/neutron/+/801707, ## High https://bugs.launchpad.net/neutron/+bug/1961173 - [fullstack] test_vm_is_accessible_by_local_ip fails sometimes - assigned to Oleg, fix proposed alreadh https://review.opendev.org/c/openstack/neutron/+/829659 ## Medium https://bugs.launchpad.net/neutron/+bug/1961013 - [stable][ovn] frequent OVN DB leader changes increase rate of Neutron API errors - assigned to Frode, it's about backport feature from master to stable branches, ## Low https://bugs.launchpad.net/neutron/+bug/1961184 - [OVN] Virtual ports are always DOWN - assigned to Rodolfo, ## Whishlist (RFEs) https://bugs.launchpad.net/neutron/+bug/1960850 - [RFE][OVN] Support DNS subdomains at a network level - I think it's properly described and needs to be discussed during the drivers meeting now, https://bugs.launchpad.net/neutron/+bug/1961011 - [RFE][L3][OVS] use controller (ovs-agent) send (packet-out) RA to (VMs) ports - I think it's properly described and needs to be discussed during the drivers meeting now, -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

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

18 Feb '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on 17th. Most of the meeting discussions are summarized below (Completed or in-progress activities section). Meeting full logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-02-17-15.00.log.html * Next week's meeting is on 24th Feb Thursday 15:00 UTC, feel free to add the topic on the agenda[1] by 23rd Feb. 2. What we completed this week: ========================= * Z cycle release name [2] 3. Activities In progress: ================== TC Tracker for Yoga cycle ------------------------------ * This etherpad includes the Yoga cycle targets/working items for TC[3]. 2 out of 9 items are completed. Open Reviews ----------------- * Six open reviews for ongoing activities[4]. Release identification and release name ----------------------------------------------- As Zed is the last release for the current alphabet release name iteration. TC discussed the future release name ideas. Belmiro has proposed the idea of adding "<year>.<release count>" number to each release. The proposal is up for review[5] Switch Keystone back to PTL model ------------------------------------------- Keystone team proposed to move Keystone from DPL to PTL model[6] with Douglas Mendizábal as PTL. Dropping tags framework ------------------------------ yoctozepto has updated part1 of dropping the tag framework[7] which is ready for review. Elod us updating the release scripts to remove the tag ref. Z release cycle Technical Election --------------------------------------- The nomination for PTL and TC elections is closed and there is no voting required. TC Campaigning period is open until 22nd Feb[8]. We will be closing the election on 22nd Feb. There are total 17 projects that missed the nomination, I have created the etherpad to work on the leaderless projects[9]. There is already late candidacy for 8 projects and 9 projects still need leaders. Please add your name if you would like to lead those projects. TC position on release cadence ------------------------------------- No other updates from last week, Dan's proposal is under review[10]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[11]. Project updates ------------------- * Retire js-openstack-lib (waiting on Adjutant to have new PTL/maintainer) [12] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027242… [3] https://etherpad.opendev.org/p/tc-yoga-tracker [4] https://review.opendev.org/q/projects:openstack/governance+status:open [5] https://review.opendev.org/c/openstack/governance/+/829563 [6] https://review.opendev.org/c/openstack/governance/+/829037 [7] https://review.opendev.org/c/openstack/governance/+/822900 [8] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027311… [9] https://etherpad.opendev.org/p/zed-leaderless [10] https://review.opendev.org/c/openstack/governance/+/828777 [11] https://etherpad.opendev.org/p/zuul-config-error-openstack [12] https://review.opendev.org/c/openstack/governance/+/798540 [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[release] Release countdown for week R-5, Feb 21-25
by Előd Illés 18 Feb '22

18 Feb '22

Development Focus ----------------- We are getting close to the end of the Yogacycle! Next week on February 24th, 2022is the Yoga-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the Zedcycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on February 24th, 2022. Only bugfix releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/yogabranching request with the review. As an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… February 24th, 2022is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also the deadline for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Yoga-3 milestone (feature freeze): February 24th, 2022(R-5 week) RC1 deadline: March 10th, 2022(R-3 week) Final RC deadline: March 24th, 2022(R-1 week) Final Yogarelease: March 30th, 2022 Next PTG: April 4 - 8, 2022 (virtual) ElődIllés irc: elodilles

1 0

Masquerading VM works 99%
by Derek O keeffe 17 Feb '22

17 Feb '22

Hi all, We have an openstack cluster with one controller and 4 computes (Victoria) we have set it up using vlan provider networks with linuxbridge agent, distributed routing & ml2 (I am only partly on the networking so there could be more to that which I can find out if needed) So I was tasked with creating two Instances, one (lets call it the external vm) with an external interface 10.55.9.67 and internal interface 192.168.1.2. A second instance (lets call it the internal vm) would then be placed on the 192.168.1.0 network. I configured masquerading on the "external vm" and tried to ping the outside world from the "internal" vm as per something like this https://kifarunix.com/configure-ubuntu-20-04-as-linux-router/?unapproved=49… Both VM's were instantiated on the same compute host (I've tried it with them on separate hosts as well). I can see the ping leave using tcpdumps along the way and it makes it all the way back to the internal interface on the external machine. It just fails on the last hop to the internal machine. I've tried everything in my power to find why this won't work so I would be grateful for any advice at all. I have added the below to show how I followed the ping manually and where it went and when it failed. Thank you in advance. Following the ping from source to destination and back:Generated on the private VMsent to the internal interface on the external vmsent to the external interface on the external vmsent to the tap interface on the computesent to the physical nic on the computesent to the nic on the network device out to the internet received on nic on the network devicefrom the internet received on physical nic on the computereceived on tap interface on compute received on external interface on the external vmreceived on the internal interface on the external vmNEVER gets to last step on the internal vm Regards,Derek

4 6

[cinder] festival of XS reviews 18 February 2022
by Brian Rosmaita 17 Feb '22

17 Feb '22

Hello Argonauts, Apologies for the lateness of this reminder, but hopefully everyone has already used the handy ICS file [0] to have this event on their personal calendars. The most recent edition of the Cinder Festival of XS Reviews will be held tomorrow (Friday 18 February). who: Everyone! what: The Cinder Festival of XS Reviews when: Friday 18 February 2022 from 1400-1600 UTC where: https://meetpad.opendev.org/cinder-festival-of-reviews etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews See you there! brian [0] http://eavesdrop.openstack.org/calendars/cinder-festival-of-reviews.ics

1 0

[neutron] Drivers meeting - Friday 18.2.2022 - cancelled
by Lajos Katona 17 Feb '22

17 Feb '22

Hi Neutron Drivers! As Friday is recharge day for RedHat, and most probably we will not have a quorum for the voting, let's cancel tomorrow's meeting. See You at the meeting next week. Lajos Katona (lajoskatona)

1 0

[TripleO] Gate blocker - ansible version
by Rafael Castillo 17 Feb '22

17 Feb '22

Hi All, We have an issue affecting multiple centos stream 8 gate jobs related to an ansible version conflict. Details: https://bugs.launchpad.net/tripleo/+bug/1961035 We are currently deciding on the best course of action for unblocking this issue. We will post an update once the gate is clear. Until then, please hold on rechecking. Thank you!

1 1

[TripleO] Sergii Golovatiuk for TripleO core reviewer (upgrades-related)
by Jose Luis Franco Arza 17 Feb '22

17 Feb '22

Hello folks, I would like to propose Sergii Golovatiuk [1][2][3] as a core reviewer on the TripleO repositories related to the upgrades workflow (openstack/tripleo-heat-templates, openstack/tripleo-ansible, openstack/python-tripleoclient, openstack/tripleo-ci, openstack/tripleo-quickstart, openstack/tripleo-quickstart-extras). Sergii has been working in OpenStack for the last 10 years, he is already core-reviewer of the tripleo-upgrade <https://github.com/openstack/tripleo-upgrade>repository in which he is providing with very valuable feedback, as well as helping getting relevant patches merged. His deep knowledge of the different OpenStack projects, as well as his involvement in the upgrades/updates workflows for the last 9 OpenStack releases makes him a great code reviewer, being able to catch several issues during the code review process. I will monitor the thread for a week and if no objections are exposed I will add him to the tripleo-core group. PD: Here comes the +1 from my side. Thanks. Cheers, José Luis [1]: https://review.opendev.org/q/owner:sgolovat%2540redhat.com [2]: https://www.stackalytics.io/?project_type=all&metric=commits&user_id=sgolov… [3]: Position #25 in the most active TripleO contributors list <https://www.stackalytics.io/report/contribution?module=tripleo-group&projec…>

13 13

[Tripleo] Issue in Baremetal Provisioning from Overcloud
by Anirudh Gupta 16 Feb '22

16 Feb '22

Hi Team I am trying to Provision Bare Metal Node from my tripleo Overcloud. For this, while deploying the overcloud, I have followed the *"default flat" *network approach specified in the below link https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15… Just to highlight the changes, I have defined the *ironic-config.yaml* parameter_defaults: ... ... IronicIPXEEnabled: true IronicInspectorSubnets: - ip_range: *172.23.3.100,172.23.3.150* IronicInspectorInterface: 'br-baremetal' Also modified the file *~/templates/network-environment.yaml* parameter_defaults: NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal NeutronFlatNetworks: datacentre,baremetal With this I have Followed all the steps of creating br-baremetal bridge on controller, given in the link below: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/15… - type: ovs_bridge name: br-baremetal use_dhcp: false members: - type: interface name: nic3 Post Deployment, I have also create a flat network on "datacentre" physical network and subnet having the range *172.23.3.200,172.23.3.240 *(as suggested subnet is same as of inspector and range is different) and the router Also created a baremetal node and ran *"openstack baremetal node manage bm1", *the state of which was a success. Observation: On executing "openstack baremetal node *provide* bm1", the machine gets power on and ideally it should take an IP from ironic inspector range and PXE Boot. But nothing of this sort happens and we see an IP from neutron range " *172.23.3.239*" (attached the screenshot) [image: image.png] I have checked overcloud ironic inspector podman logs alongwith the tcpdump. In tcpdump, I can only see dhcp discover request on br-baremetal and nothing happens after that. I have tried to explain my issue in detail, but I would be happy to share more details in case still required. Can someone please help in resolving my issue. Regards Anirudh Gupta

5 20

[all][tc] Technical Committee next weekly meeting on Feb 17th at 1500 UTC
by Ghanshyam Mann 16 Feb '22

16 Feb '22

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

1 1

[kolla-ansible][nova]Problem with distribution of instance on servers
by Franck VEDEL 16 Feb '22

16 Feb '22

Hello, I seem to have a problem that I hadn't seen. I have 3 servers for my openstack, built with Kolla-ansible, I'm in Victoria version. I had simply put the 3 servers in the [compute] part of the multinode file, at first it worked, but for some time all the VMs are placed on server 1. The 3 servers are operational, identical. here are 3 screenshots to show it. (on the images, the instances on servers 2 and 3 are present because it worked correctly, but no more instances are created on these servers now) I tried to understand how the instances are distributed on the servers, but in my case, I don't understand why none are assigned to the 2nd and 3rd server. How to find the problem? It should be nova-scheduler . Do you have to do anything special? Go see if a parameter has a bad value? Thanks in advance if you can help me. Franck VEDEL

4 10

[manila][cinder][glance][nova][devstack][qa] Add fmount to devstack-plugin-ceph core
by Goutham Pacha Ravi 16 Feb '22

16 Feb '22

Hello, As you're aware, we're looking to adopt cephadm within devstack-plugin-ceph to align with the ceph community's recommendations on day0-day2 handling of ceph [1] in devstack. Francesco Pantano has worked a ton on the integration of ceph with tripleo. He has been our go-to person for deploying and using the new nfs daemon with manila. In light of this, to make reviews more productive, I would like to propose fpantano(a)redhat.com (fmount on launchpad and oftc) to the devstack-plugin-ceph-core group [2]. He's aware of our review policies, and will take care not to break existing testing. Any objections? Thank you, Goutham Pacha Ravi [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026778.… [2] https://review.opendev.org/admin/groups/8e51d8f39e33d932a40f03060b861db57a3…

5 5

[keystone] anyone using OpenID with Keystone?
by Francois 16 Feb '22

16 Feb '22

Hi Keystone users! I am wondering if anyone has experience with keystone openid integration. Initially I was using Keystone LDAP backend (using tripleo KeystoneLDAPDomainEnable and KeystoneLDAPBackendConfigs parameters) and it works! Users are able to log in through Horizon or through the cli, roles can be given per LDAP group, and you can click in Horizon and download a working openrc or clouds.yaml file (minus the root CA that has to be added) to authenticate with the cli (and your password ends as an OS_PASSWORD variable in your environment). I am now trying the Keystone Openid backend (using the enable-federation-openidc.yaml provided by tripleo - https://github.com/openstack/tripleo-heat-templates/blob/master/environment…) with a mapping like this: [{"local":[{"user":{"name":"{0}"},"group":{"domain":{"name":"Default"},"name":"federated_users"}}],"remote":[{"type":"HTTP_OIDC_EMAIL"}]}] The SSO works superb with Horizon, however - logging with the cli seems impractical. I see some doc here: https://docs.ukcloud.com/articles/openstack/ostack-how-use-api-sso.html where you need to provide a secret, I am skeptical I want to do that. The openrc file downloaded from Horizon is not usable as is and needs some tuning. And there is no SSO, and the password still ends up in the environment... - I don't see how I can grant roles to groups anymore. It seems I need an extra mechanism to grant permissions (as I used to do that using LDAP groups). I am wondering if anyone is willing to share their experience dealing with Keystone and OpenID. Thanks! Francois (frigo)

5 5

Openstack HPC Infiniband question
by Satish Patel 16 Feb '22

16 Feb '22

Hi all, I am playing with HPC on openstack cloud deployment and I have a Mellanox infiniband nic card. I have a couple of deployment questions regarding the infiniband network. I am new to ib so excuse me if i ask noob questions. I have configured Mellanox for sriov and created a flavor with the property pci_passthrough:alias='mlx5-sriov-ib:1' to expose VF to my instance. so far so good and i am able to see the ib interface inside my vm and its active. (I am running SM inside infiniband HW switch) root@ib-vm:~# ethtool -i ibs5 driver: mlx5_core[ib_ipoib] version: 5.5-1.0.3 firmware-version: 20.28.1002 (MT_0000000222) expansion-rom-version: bus-info: 0000:00:05.0 supports-statistics: yes supports-test: yes supports-eeprom-access: no supports-register-dump: no supports-priv-flags: yes I didn't configure any ipaddr on the ibs5 interface etc. For testing purposes I have compiled mpirun hello world program to POC my infiniband network between two instances and I am able to successfully run the mpi sample program. Somewhere i read about neutron-mellanox agent to setup IPoIB for segmentation etc but not very sure that how complex it and what are the advantage here over just using simple passthru of SR-IOV Is this the correct way to set up an HPC cluster using openstack or is there a better way to design HPC on openstack?

2 2

[all][elections][tc] TC Election Campaigning Kickoff
by Ghanshyam Mann 16 Feb '22

16 Feb '22

Community Members, The TC Election Campaigning Period has now started [1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms [2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform [2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. Even though there are no runoffs, still it is good to have campaigning discussion. [1] https://governance.openstack.org/election/ [2] https://governance.openstack.org/election/#z-tc-candidates -gmann & The OpenStack Technical Election Officials

1 0

[all][elections][ptl][tc] Combined PTL/TC Zed cycle Election Nominations End
by Ghanshyam Mann 15 Feb '22

15 Feb '22

Hello Everyone, The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 17 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant, Freezer, Heat, Magnum, Masakari, Monasca, Murano, OpenStack_Charms, Openstack_Chef, Senlin, Skyline, Solum, Trove, Venus, Watcher, Zaqar, Zun There are 0 projects that will have elections. -- TC Election Details -- The 5 seats were filled and no runoff is required. Now begins the campaigning period where candidates and electorate may debate their statements. Thank you, [0] https://governance.openstack.org/election/#z-ptl-candidates [1] https://governance.openstack.org/election/#z-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for… -gmann & The OpenStack Technical Election Officials

1 0

Create Image in queue State in XENA Version
by Adivya Singh 15 Feb '22

15 Feb '22

Hi Team, We have lately upgraded to Xena , but when users trying to upload any image, it is always in queue state, i did not see any error regarding any issue with glance configuration file. Any thoughts on this Regards Adivya Singh

2 1

[tooz] [mistral] Tenacity >= 8.0.1 issues (in Debian)
by Thomas Goirand 15 Feb '22

15 Feb '22

Hi, It seems Tenacity has some incompatible changes leading to this: https://bugs.debian.org/1005636 (tooz) https://bugs.debian.org/1005467 (mistral) Note that both Manila and Heat were fixed already for this last version of Tenacity, so these would likely be the only remaining blockers to upgrade to 8.0.1. As Tenacity 8.0.1 is already in Debian Unstable, I'd prefer if we fixed these rather than pinning to a lower version. Can anyone help? Cheers, Thomas Goirand (zigo)

2 2

[cinder] final reviews needed for os-brick yoga release
by Brian Rosmaita 15 Feb '22

15 Feb '22

Hello Argonauts, We are now aiming to release on Tuesday 15 Feb at 20:00 UTC. The list of patches needing review and some comments on their status is here: https://etherpad.opendev.org/p/os-brick-yoga-release We're in mostly good shape, just need a final sprint to close this out. reviewers: please review! patch authors: please keep an eye on your patches and respond quickly and make sure your CI has responded with success thanks, brian

1 1

[election][Requirements] PTL candidacy for Zed
by Matthew Thode 15 Feb '22

15 Feb '22

I would like to announce my candidacy for PTL of the Requirements project for the Zed cycle. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible (stuff like prettytable). 3. Fix some automation of generate contstraints (pkg-resources being added and setuptools being dropped) 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. 5. introduce better python version range support into constraints. I look forward to continue working with you in this cycle, as your PTL or not. Thanks for your time, -- Matthew Thode

1 0

[election][swift] PTL candidacy for Zed
by Timothy Burke 15 Feb '22

15 Feb '22

I intend to continue serving as Swift PTL for the Zed cycle. We have seen Swift scale in spectacular ways. Hard drives have grown from 2-4 terabytes when Swift was started to 10-20T. The idea of a "large cluster" has gone from dozens of petabytes across hundreds of nodes to hundreds of petabytes across thousands of nodes. We will continue to see (and address) new challenges in scaling Swift. We anticipate hitting the bounds of our current ring format. We see operators struggle to balance the prioritization of cluster expansion and data durability. We see the need to improve sharding, so that clients are less impacted by what's going on in the backend. All of these have seen progress in the last cycle, and will continue to be advanced in the next. Just as important as scaling the core storage platform, however, is building up the ecosystem of ancillary services that users have come to expect out of their object storage. When a container grows to have billions of objects, it is impractical to perform thousands of listing requests to analyze its contents; instead, users expect a periodic inventory that's easy to pull into their existing data pipelines. Users should be able to examine their own access logs rather than needing to involve operators. Users want to manage their data movement and retention en masse rather than object-by-object. I look forward to seeing the balance we strike between enhancing the core storage platform and building out the data services surrounding it over the coming years. Tim Burke

1 0

[election][Release_Management] PTL candidacy for Z cycle
by Előd Illés 15 Feb '22

15 Feb '22

Hello OpenStack Community, I would like to announce my candidacy for the PTL role of the Release Management team for the Z cycle. I am core member in the Release Management team since Wallaby, but I followed the team's work even before that, and I also have been the PTL of the team for Yoga cycle for some months now. (Though, from release management perspective this is not a long period, since the most laborous part will only start in the coming weeks ;)) Furthermore, as in the past, beside release management duties, my focus is still on stable maintenance as well, since I am stable-maint-core member, too. The next cycle's challenges will be to prepare our tooling to alphabet roll-over after the Z cycle and to adjust to any other changes in our processes. And of course, parallel to this, to release OpenStack Z :) Thanks for your consideration, Előd Illés (elodilles)

1 0

[nova][placement] Implementation review day on Thursday Fev 17
by Sylvain Bauza 15 Feb '22

15 Feb '22

Hey folks, Last minute item, but we agreed during today's meeting to run a feature review day on Thursday February the 17th. If you're one of the owners of the blueprints that are marked in [1], you're eligible to ensure that this etherpad is up to date based on your last efforts and that you're somehow around either on IRC or asynchronously through Gerrit on that day to answer comments and questions about your patches. Cores, I'd appreciate if you can dedicate this Thursday to feature reviews as we still have a large set of blueprints that aren't merged yet. Thanks, -Sylvain [1] https://etherpad.opendev.org/p/nova-yoga-blueprint-status

1 0

[all][tc] OpenStack next release name is final- "OpenStack Zed"
by Ghanshyam Mann 15 Feb '22

15 Feb '22

Hello Everyone, We have the final name selected for the OpenStack next release name. Its "OpenStack Zed". As per the release name criteria[1], selection of release name has gone through three steps: Step1: Name nomination from community members[2]. Step2: TC voted on the nominated names[3]. Step3: Trademark checks by Foundation on winners from TC votes. In trademark check, “Zed” is finalized as the best bet for this release. Thanks community members for participating in name nomination, TC to vote and Foundation for performing the trademark checks. [1] https://governance.openstack.org/tc/reference/release-naming.html#release-n… [2] https://wiki.openstack.org/wiki/Release_Naming/Z_Proposals [3] https://civs1.civs.us/cgi-bin/results.pl?id=E_693bd8bbe63ca52f -gmann

4 6

[election][Kuryr] PTL candidacy for the Z cycle
by Maysa De Macedo Souza 15 Feb '22

15 Feb '22

Hello OpenStack community, I would like to announce my candidacy for the Z cycle. I have been serving as Kuryr PTL since the Wallaby and I would like to continue doing that. In the Yoga cycle we have achieved the following: * Extended features and improvements: addition of events to Kubernetes resources, reduction on the workload Kuryr puts on Neutron, limiting the number of Neutron Ports creation happening in parallel, continuation on the load-balancer resources reconciliation with k8s Services, and many more. * CI improvements: Made Devstack installations to use CRI-O and improved some tempest tests. For the next cycle, I propose the following goals to Kuryr: * Continue improvements for Kuryr scalability with Neutron, OpenStack resources reconciliation with Kubernetes and Kuryr controller health checks. Thanks for your consideration. Best regards, Maysa Macedo. IRC: maysams

1 0

[election][tc] TC candidacy for Z release
by Slawek Kaplonski 15 Feb '22

15 Feb '22

Hi, I want to propose my candidacy for the Technical Committee. I have been an OpenStack contributor since around 2015. For most of that time I have contributed to the Neutron project where I am core reviewer and member of the Neutron drivers team, which is the subset of the Neutron core team for steering the Neutron project. I also served as the Neutron PTL for 4 cycles. Currently I work for Red Hat as software engineer and OpenStack Neutron developer and I would like to bring that developer’s perspective to the TC. Before I joined Red Hat, I worked in the OVH which is a Public Cloud provider. That gave me experience as an OpenStack operator as well. I have experience with the Neutron CI and I would like to expand it wider, for OpenStack as a whole. In the past I cooperated with TC members to reduce CI resources usage by the Neutron project and we made great improvements there. I understand that this new role will require a lot of learning and I will be very happy to have that opportunity. I’m willing to learn and contribute to the TC as much as possible. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[election][tc] TC candidacy for Z release
by Arne Wiebalck 15 Feb '22

15 Feb '22

Hello Everyone! I would like to declare my candidacy for the Technical Committee. I joined the CERN OpenStack team in 2014, initially to help with the operations of the storage components (Cinder, later Manila), and since 2016 I am looking after the overall operations of our cloud infrastructure service here at CERN. As part of this operational role, I have contributed upstream to several projects [1], recently mostly to Ironic which I help as a core member since about three years. I chair the Bare Metal SIG [2] since its inception, and together with other community members I am trying to establish it as a forum to promote the use of OpenStack for bare metal use cases [3] and to help new users to get started. Presentations at several summits [4] and regular blog posts [5] are examples of how I share the operational challenges and the solutions we apply in our cloud, in the hope these are helpful to other deployers in the same way we profit from them sharing their experiences. The combination of running an in-production OpenStack deployment downstream while interacting with core developers and the overall community upstream is something that I've enjoyed _a lot_ since several years now. I see how real-life input can be essential for upstream projects to move forward, set priorities, or maintain momentum. Equally, interaction with a responsive community where feedback is turned into tangible improvements is a valuable asset for any deployment. This positive experience of being an operator/developer hybrid in the OpenStack community is something I would like to bring to the TC, assisting with the ongoing (but continuous) effort to engage operators and help when global technical issues need to be sorted. I am sure being a member of the TC and helping with its work comes with a learning curve, but I'd be happy to contribute where I can. Thanks for reading and your consideration! Arne Wiebalck IRC (OFTC): arne_wiebalck [1] https://www.stackalytics.io/?metric=commits&release=all&user_id=arne-wiebal… [2] https://etherpad.opendev.org/p/bare-metal-sig [3] https://www.youtube.com/playlist?list=PLKqaoAnDyfgoBFAjUvZGjKXQjogWZBLL_ [4] https://www.openstack.org/videos/search?search=wiebalck [5] https://techblog.web.cern.ch/techblog/

1 0

OpenInfra Live - February 17 at 1500 UTC
by Allison Price 15 Feb '22

15 Feb '22

Hi everyone, This week’s OpenInfra Live episode is brought to you by the OpenInfra Foundation. Organizations like AT&T, CERN, China Mobile, China Telecom, Verizon, Vodafone, and Yahoo have adopted the OpenInfra Standard and run it in production today. Similar to how LAMP stack became the standard for deploying web applications, LOKI helps operators identify successful patterns and combinations of technologies to build production infrastructure. This OpenInfra Live episode will discuss this emerging standard and why organizations have adopted these open source technologies together. Episode: Linux OpenStack Kubernetes Infrastructure: The OpenInfra Standard Date and time: Thursday, February 17 at 9am CT (1500 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=pnYB7eYYiPg <https://www.youtube.com/watch?v=pnYB7eYYiPg> LinkedIn: https://www.linkedin.com/video/event/urn:li:ugcPost:6899060799814418432/ <https://www.linkedin.com/video/event/urn:li:ugcPost:6899060799814418432/> Facebook: https://www.facebook.com/104139126308032/posts/4852599164795314/ <https://www.facebook.com/104139126308032/posts/4852599164795314/> WeChat: recording will be posted on OpenStack WeChat after the live stream Participants: Host: Mark Collier, COO at the OpenInfra Foundation Maria Bracho, Manager Product Management at Red Hat Philip Williams, Product Leader at Canonical Have an idea for a future episode? Share it now at ideas.openinfra.live <https://openinfrafoundation.formstack.com/forms/openinfralive>. Thanks, Allison

1 0

[glance] Zed PTG Planning
by Abhishek Kekane 15 Feb '22

15 Feb '22

Hello Everyone!!! As you are already aware that Zed virtual PTG will be held between April 4th to 8th [1]. Please use below etherpad to add the topics you would like to discuss during PTG. https://etherpad.opendev.org/p/zed-ptg-glance-planning <https://etherpad.opendev.org/p/yoga-ptg-glance-planning> [1] https://openinfra-ptg.eventbrite.com/ Thanks & Best Regards, Abhishek Kekane

1 0

oslo.messaging integration development
by liyang 15 Feb '22

15 Feb '22

Hi everyone, I find Apache Pulsar is very popular in MQ area, especially in clound native area. Is there any body integrate this MQ to oslo.messaging? Said to the truth. RabbitMQ developed in Erlang has very little source code level material, Qpid has very little operation practice in the internet. Kafka only support notification in oslo.messaging. I think the Apache Pulsar is clound native based. It may enforece the big scale in extension about Openstack deployment.

5 9

[election][tc] TC candidacy for Z
by Brian Rosmaita 15 Feb '22

15 Feb '22

Hello Everyone, I am declaring my candidacy for the Technical Committee. I've been involved in OpenStack for a while now (my first commit was into Folsom). I've been a very active member of the community as a core member of the Glance, Cinder, and Searchlight teams. I've attended many PTGs and presented at many Summits. I've also served as PTL for Glance (Ocata through Queens) and Cinder (Ussuri through Yoga). You may have seen my clever irc nick, 'rosmaita', mostly in #openstack-cinder and #openstack-glance, but occasionally making a pest of myself in other channels. The TC is tasked with providing technical leadership for OpenStack as a whole and enforcing the OpenStack ideals (the Four Opens [0], the Guiding Principles [1]). While the TC's primary mission is to provide technical leadership, promoting the ideals calls for a broader membership than just technical people actively developing OpenStack. So I think it's appropriate that TC membership includes operators, distributors, and cultural members of the OpenStack community. But it's also important that the TC include highly technical people who contribute to the projects it oversees [2]. I believe that I'm well-suited to represent that constituency. I don't have an agenda other than to represent active contributors and participate in the TC in a manner consistent with its charter [3]. If you ask people who've worked with me, you'll find that I'm good about making sure discussions are done in the open, and that all parties concerned are listened to. I'll bring these qualities to the TC. Finally, I should probably mention who pays my bills. I'm a Principal Software Engineer at Red Hat. As you're hopefully aware, Red Hat has an "upstream first" philosophy [4], which is pretty evident when you look at code contributions to OpenStack, but which also extends to the company encouraging us, when participating in an open source community, to make decisions based on the needs and goals of the community rather than those of Red Hat. (That sounds very noble, but the idea is that a strong community benefits Red Hat in the long run. My key point here, though, is that I'm empowered to represent the OpenStack community's interest, not Red Hat's, if I'm elected to the TC.) Thanks for reading this far, and thank you for considering my candidacy for the OpenStack Technical Committee. - Brian Rosmaita (rosmaita) [0] https://governance.openstack.org/tc/reference/opens.html [1] https://governance.openstack.org/tc/reference/principles.html [2] I appropriated this line from Dan Smith. [3] https://governance.openstack.org/tc/reference/charter.html [4] https://opensource.com/article/16/12/why-red-hat-takes-upstream-first-appro…

1 0

[manila][election][ptl] PTL Candidacy for Z
by Carlos Silva 15 Feb '22

15 Feb '22

Hello, Zorillas and dear stackers, I would like to submit my candidacy to be the PTL of Manila for the Z cycle. I have been a contributor to OpenStack since the Stein release. It has been an awesome experience. During these years, I had the opportunity to contribute with new features, fixes, reviews and other exciting enhancements for Manila. I can tell you that I've faced thrilling challenges, and I learned a lot with the community that made this journey enjoyable day after day. I'm tremendously happy to see the state Manila is at. I'd like to keep the momentum for the project by continuing to focus in some areas we have been focusing, but also start tackling other issues: - Continue increasing the number of contributors and active reviewers through mentoring and engaging them in the community, teaching the OpenStack way and making it collaboratively as we did in the past cycles, promoting hackatons, bug squashes and collaborative review sessions. - Encouraging the involvement of Manila contributors in important programs/events such as GHC, Outreachy and the other opportunities we've been able to contribute in the past. - Pursue the completion of the Manila implementation on the openstackclient/openstacksdk; - Continue pushing Manila to cover the tech debt areas we identified over the past cycles; - Enforcing maintainers to collaboratively cover the lack of documentation we have on third party CI setups for Manila, helping potential new vendors to quickly setup up their CI systems; - Continue discussing with community and making the necessary enhancements for HA and Edge; Thank you for your consideration! Carlos da Silva IRC: carloss

4 3

[election][cloudkitty] PTL candidacy for Zed
by Rafael Weingärtner 15 Feb '22

15 Feb '22

Hello guys, I would like to self-nominate for the role of PTL of CloudKitty for the Zed release cycle. I am the current PTL for the Xena cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain CloudKitty for their use cases and encourage the addition of new functionalities. Thank you for your support, -- Rafael Weingärtner

1 0

[neutron][ci] Agenda for the CI meeting - Tuesday 15.02.2022
by Slawek Kaplonski 15 Feb '22

15 Feb '22

Hi, Agenda for today's CI meeting is at [1]. Please remember that our today's meeting will be video meeting on [2]. See You there at 1500 UTC today. [1] https://etherpad.opendev.org/p/neutron-ci-meetings [2] https://meetpad.opendev.org/neutron-ci-meetings -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[election][tacker][ptl] PTL candidacy for Z
by Yasufumi Ogawa 14 Feb '22

14 Feb '22

Hi, I'd like to propose my candidacy for Tacker PTL in Z cycle. I have been a PTL from Victoria and made an effort to implement the latest ETSI-NVF standard features to enable operators to deploy their services. In Yoga release, we are going to provide several container supports for deploying CNFs, multi-version APIs for mixed environment of legacy and cutting edge-products provided by several vendors and more. We also had several collaborative sessions with ETSI NFV for accelerating each activity of standardization and deployment of required features. In Z release, I would like to expand our target to VNFs for network acceleration other than proceed to implement VM/container management features which has been introduced in the previous releases. It has became one of the key requirements of the recent commercial use cases such as 5GC. Best regards, Yasufumi (yasufum)

1 0

[manila][ptl] Non-candidacy for the Z cycle
by Goutham Pacha Ravi 14 Feb '22

14 Feb '22

Hey Zorillas and other interested Stackers, I took over as Manila PTL prior to the Ussuri cycle and have had fun running the project for 5 cycles. The itch for change hasn't subsided. So, I'd love to hand off the PTL baton and go back to being a maintainer (or whatever else you'll let my pompous behind claim to be). Despair not though, there's someone that has bright ideas and energy to enhance this role that intends to nominate themselves to lead us through the Zorilla (Zed) cycle! I'm very proud that I had your encouragement and support for the past ~three years. We innovated and incorporated some fun practices that held the community together and grew it over time. We chipped away at tech debt in an organized fashion, created focus teams, added half a dozen core reviewers, mentored 20 (!) interns, squashed bugs, put together hackfests, collaborated on reviews and somehow made the pandemic-caused virtual project team gatherings fun as well. We will do so much more of this with the new PTL and the hyper-charged zorilla spirit :D So I'm very excited. Thank you for your support! -- Goutham Pacha Ravi

2 1

[ironic][election][ptl] PTL Candidacy for Zed Cycle
by Iury Gregory 14 Feb '22

14 Feb '22

Hello, Ironicers and stackers! I would like to submit my candidacy to continue serving as Ironic PTL for the Zed cycle. In the Yoga cycle, we are adding features to facilitate the cloud operator's life (e.g., Ironic now can calculate the default value for any enabled interface based on the `enabled_hardware_type`, verify steps). We fixed bugs related to SW Raid, virtual media deployments, and many others! Let's continue working together so we can take over the world! =) Best regards, Iury Gregory Melo Ferreira IRC: iurygregory -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[elections][ptl][masakari]
by Sam Su (苏正伟) 14 Feb '22

14 Feb '22

Hi all, I write to submit my candidacy for the Masakari PTL position during the Z cycle. I took over as Masakari PTL during the Yoga cycle, and would like to serve the community for another cycle. Right now the biggest challenge of the Masakari project is lack of activity. We have been using Masakari in our cloud environment for years, so I want to continue to make some little improvement as feedback. Best regards for you. -suzhengwei

1 0

[election][Sahara]PTL candidacy for Z
by Juntingqiu Qiujunting (邱军婷) 14 Feb '22

14 Feb '22

Hi all: I write to submit my candidacy for the Sahara PTL position during the Z cycle.I have been PTL for the Yoga cycle, and I would like to serve the community for another cycle. In yoga cycle, we have discuss about the plugins are CDH, MapR, Storm, Spark and Vanilla will be removed from Sahara. I will continue this work on Z cycle. And assist the community to resolve some inappropriate issues in Yoga about Sahara project. At present, the Sahara project is not very active, and welcome my dears to actively participate in the construction of the Sahara project in Z cycle. Finally, expect the Sahara project to develop healthily and stably. Best regards for you. Fossen Qiu (fossenqiu) --------------------------------- Fossen Qiu | 邱军婷 CBRD | 云计算与大数据研发部 T: 18249256272 E: qiujunting(a)inspur.com<mailto:qiujunting@inspur.com> 浪潮云海

1 0

[election][puppet] PTL Candidacy for the "Z" release
by Takashi Kajinami 14 Feb '22

14 Feb '22

Hello, I'd like to announce my candidacy for the PTL role in Puppet OpenStack, for the Z release cycle. I've been involved in the project for a few years. I joined the core reviewers of the project in 2020. My contribution started with adding a few parameters but nowdays I'm covering literally all modules to keep these modules consistent with the latest service implementation, as well as helping release management. I'll list up some important items for the upcoming Z-release, which I'd like to prioritize. - Keep our implementation up to date and clean up old items to keep codes as simple as possible. - Extend support for Secure RBAC. We are adding partial support to enforce Secure RBAC in Keystone during Yoga. - Stabilize support for CentOS 9 Stream, which we are adding for Yoga. - Add support for the new Ubuntu LTS. - Improve scenario/component coverage by CI. Finally, as we are currently a small team, we always welcome new contributors, reviewers or whoever interested in helping the project ! Thank you for your consideration. Thank you, Takashi

1 0

[election][storlets] PTL Candidacy for the "Z" release
by Takashi Kajinami 14 Feb '22

14 Feb '22

Hi All, I'd like to announce my candidacy for PTL of Storlets for the z release cycle, continuing the role from past several cycles. The biggest change we're expecting for this cycle is removal of Python 2 support, following the same in Swift, which was recently announced[1]. We don't expect any challenges at this moment as Storlets has been fully complatble with Python 3 for several cycles, but the remaining work to clean up items left to keep Python 2 support (Python 2 jobs, for example) is our priority. [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026925.… Thank you for your consideration. Thank you, Takashi

1 0

[all][tc] Relmgt team position on release cadence
by Thierry Carrez 14 Feb '22

14 Feb '22

Hi everyone, The (long) document below reflects the current position of the release management team on a popular question: should the OpenStack release cadence be changed? Please note that we only address the release management / stable branch management facet of the problem. There are other dimensions to take into account (governance, feature deprecation, supported distros...) to get a complete view of the debate. Introduction ------------ The subject of how often OpenStack should be released has been regularly debated in the OpenStack community. OpenStack started with a 3-month release cycle, then switched to 6-month release cycle starting with Diablo. It is often thought of a release management decision, but it is actually a much larger topic: a release cadence is a trade-off between pressure to release more often and pressure to release less often, coming in from a lot of different stakeholders. In OpenStack, it is ultimately a Technical Committee decision. But that decision is informed by the position of a number of stakeholders. This document gives historical context and describes the current release management team position. The current trade-off --------------------- The main pressure to release more often is to make features available to users faster. Developers get a faster feedback loop, hardware vendors ensure software is compatible with their latest products, and users get exciting new features. "Release early, release often" is a best practice in our industry -- we should generally aim at releasing as often as possible. But that is counterbalanced by pressure to release less often. From a development perspective, each release cycle comes with some process overhead. On the integrators side, a new release means packaging and validation work. On the users side, it means pressure to upgrade. To justify that cost, there needs to be enough user-visible benefit (like new features) in a given release. For the last 10 years for OpenStack, that balance has been around six months. Six months let us accumulate enough new development that it was worth upgrading to / integrating the new version, while giving enough time to actually do the work. It also aligned well with Foundation events cadence, allowing to synchronize in-person developer meetings date with start of cycles. What changed ------------ The major recent change affecting this trade-off is that the pace of new development in OpenStack slowed down. The rhythm of changes was divided by 3 between 2015 and 2021, reflecting that OpenStack is now a mature and stable solution, where accessing the latest features is no longer a major driver. That reduces some of the pressure for releasing more often. At the same time, we have more users every day, with larger and larger deployments, and keeping those clusters constantly up to date is an operational challenge. That increases the pressure to release less often. In essence, OpenStack is becoming much more like a LTS distribution than a web browser -- something users like moving slow. Over the past years, project teams also increasingly decoupled individual components from the "coordinated release". More and more components opted for an independent or intermediary-released model, where they can put out releases in the middle of a cycle, making new features available to their users. This increasingly opens up the possibility of a longer "coordinated release" which would still allow development teams to follow "release early, release often" best practices. All that recent evolution means it is (again) time to reconsider if the 6-month cadence is what serves our community best, and in particular if a longer release cadence would not suit us better. The release management team position on the debate -------------------------------------------------- While releasing less often would definitely reduce the load on the release management team, most of the team work being automated, we do not think it should be a major factor in motivating the decision. We should not adjust the cadence too often though, as there is a one-time cost in switching our processes. In terms of impact, we expect that a switch to a longer cycle will encourage more project teams to adopt a "with-intermediary" release model (rather than the traditional "with-rc" single release per cycle), which may lead to abandoning the latter, hence simplifying our processes. Longer cycles might also discourage people to commit to PTL or release liaison work. We'd probably need to manage expectations there, and encourage more frequent switches (or create alternate models). If the decision is made to switch to a longer cycle, the release management team recommends to switch to one year directly. That would avoid changing it again anytime soon, and synchronizing on a calendar year is much simpler to follow and communicate. We also recommend announcing the change well in advance. We currently have an opportunity of making the switch when we reach the end of the release naming alphabet, which would also greatly simplify the communications around the change. Finally, it is worth mentioning the impact on the stable branch work. Releasing less often would likely impact the number of stable branches that we keep on maintaining, so that we do not go too much in the past (and hit unmaintained distributions or long-gone dependencies). We currently maintain releases for 18 months before they switch to extended maintenance, which results in between 3 and 4 releases being maintained at the same time. We'd recommend switching to maintaining one-year releases for 24 months, which would result in between 2 and 3 releases being maintained at the same time. Such a change would lead to longer maintenance for our users while reducing backporting work for our developers. -- Thierry Carrez (ttx) On behalf of the OpenStack Release Management team

15 45

[election][tc] Candidacy for TC for Z
by Nikolla, Kristi 14 Feb '22

14 Feb '22

Hi all, I am announcing my candidacy for a position on the OpenStack Technical Committee. I'm a software engineer at the Mass Open Cloud[0], and the New England Research Cloud[1], two initiatives from major universities in the Boston area to create and operate public and open clouds that can federated and replicated. I've been involved with OpenStack for the past 7 years as a user, operator, and developer. This is not my first time running, I have previously served on the Technical Committee[2] and as Keystone PTL for 1 year during the Victoria and Wallaby cycles[3][4]. I am passionate about open source and governance and keeping the community healthy. My focus will be in facilitating the discussions that need to happen, whether they are internal to a team, between project teams, or between OpenStack and other projects. Please allow me once again the honor of representing you, and the opportunity to continue contributing to the community that I owe so much to and want to see flourish. I look forward to hopefully seeing you all very soon! Thank you for your time and consideration, Kristi Nikolla (he/him) [0]. https://massopen.cloud [1]. https://nerc.mghpcc.org [2]. https://opendev.org/openstack/election/raw/branch/master/candidates/victori… [3]. https://opendev.org/openstack/election/raw/branch/master/candidates/victori… [4]. https://opendev.org/openstack/election/raw/branch/master/candidates/wallaby…

1 0

[puppet][tc] Propose changing the release model to cycle-with-rc
by Takashi Kajinami 14 Feb '22

14 Feb '22

Hello, I already discussed this with a few cores last year but I'm raising this topic in ML to make an official decision. Currently Puppet OpenStack is following cycle-with-intermediary and creates a release every milestone. However our code is tightly related to the actual service implementations and having only puppet releases is not very useful. Considering the above point, and effort required to cut off releases per milestone, I'll propose changing our release model to cycle-with-rc , and creating a single release. Because we already created milestone releases for Yoga, I'm thinking of applying the change from next cycle(Z). Please let me know if you have any concerns. Thank you, Takashi

5 5

[blazar][election][ptl] PTL candidacy for Z
by Pierre Riteau 14 Feb '22

14 Feb '22

Hi, I would like to self-nominate for the role of PTL of Blazar for the Z release cycle. I have been PTL since the Stein cycle and I am willing to continue in this role. We have experienced an uptick in contributions during the Yoga cycle, merging some long-awaited features such as a calendar view in the dashboard or initial support for preemptible instances. I would like to keep this momentum going, improving Blazar for its existing users and plugging gaps preventing it from getting adopted by more deployments. Thank you for your support, Pierre Riteau (priteau)

1 0

[election][Designate][ptl] My candidacy for the "Z" release
by Michael Johnson 14 Feb '22

14 Feb '22

Hello OpenStack community, I would like to announce my candidacy for PTL of Designate for the "Z" cycle. I would like to continue to support the Designate team for the "Z" release. We have made good progress improving the Designate tempest tests and documentation, but we have more work to do. The team has also been focusing on cleaning up some of the accumulated technical debt, which I expect will continue into the "Z" cycle. Thank you for your support and your consideration for "Z", Michael Johnson (johnsom)

1 0

Outreachy OpenStack Coordinator change
by Mahati Chamarthy 14 Feb '22

14 Feb '22

Hello all, There has been a change in coordination responsibilities for Outreachy OpenStack <https://www.outreachy.org>. Samuel has decided to step down as a coordinator. I'd like to thank Samuel for his time and efforts to Outreachy. He has helped onboard many new contributors onto the Outreachy Openstack internship program. Thank you Samuel and hope our paths cross again! Good luck. I'd also like to welcome Dmitry Tantsur who kindly offered to coordinate along with me for Outreachy Openstack. Dmitry has been a long time OpenStack contributor and a core committer for the Ironic project. He has already been an Outreachy mentor for multiple rounds. For any queries regarding Outreachy, he can be reached at divius.inside(a)gmail.com (or) on IRC: dtantsur Welcome aboard Dmitry, thank you for stepping up! Best, Mahati

1 0

[neutron] lldpd Errors
by Ammad Syed 14 Feb '22

14 Feb '22

Hello, I am using ovn 21.09 with neutron 19.0. I am continuously seeing below lldpd errors in my journalctl and syslog of compute nodes. Is there anything to worry about? Feb 13 21:17:29 computehost02 lldpd[5025]: MSAP has changed for port tap30b18e08-00, sending a shutdown LLDPDU Feb 13 21:17:29 computehost02 lldpd[5025]: unable to send packet on real device for tap30b18e08-00: No such device or address Feb 13 21:17:29 computehost02 lldpd[5025]: unable to send packet on real device for tap48d8e15e-ee: No such device or address Feb 13 21:17:59 computehost02 lldpd[5025]: unable to send packet on real device for tap48d8e15e-ee: No such device or address Feb 13 21:17:59 computehost02 lldpd[5025]: MSAP has changed for port tap30b18e08-00, sending a shutdown LLDPDU Ammad

3 2