- openstack-discuss - lists.openstack.org

[tc][all][ptg] "Technical Committee + Leaders interaction" 2023.1 cycle vPTG sessions summary
by Ghanshyam Mann 23 Oct '22

23 Oct '22

Hello Everyone, I am writing the Technical Committee + Leader interaction session discussion summary that happened in the 2023.1 Antelope cycle PTG this week. We continue the interaction session in this PTG also. The main idea here is to interact with community leaders and ask for their feedback on TC. I am happy to see ~30 attendance and had a good amount of discussions. Below are the topics we discussed in this feedback session. Updates from TC: ============= * Conveying current selected Community-wide goals. * Avoid Bare recheck * TC PTG slots: 15-19 UTC on Thursday and Friday * Status on previous PTG interaction sessions' Action items/feedback: ** PTLs/Leaders to start spreading the word and monitor ignorant recheck in their weekly meeting Status: Good progress in this, many projects started monitoring it and slaweq continues contacting the PTL for this. But we still encourage PTLs/Leaders to publish the blog/video of their stories/project updates etc at least once in a cycle. You can check the places where to publish such blogs/videos [1]. ** Recognize the contribution: Status: Not done, we are continuing this AI and will work on it this cycle. ** Bare Recheck: Status: Done. TC is monitoring the bare recheck in the weekly meetings and slaweq reaching out to projects to do the same in their weekly meeting. Feedback on TC activities or anything Community Leaders would like TC to spend more time on: ========================================================================= * Continue the TC weekly summary email which is helpful * TC to build a review process that would happen periodically to check the project status. Basically to ensure the project status as per "Emerging Technology and Inactive projects"[2]. JayF volunteered to work on this to write some documentation or resolution. ** Action Item: 1. JayF to write a resolution on criteria/flag to identify/action on the inactive projects. Renovate translation SIG i18: ====================== Ian and Seongsoo joined the discussion to provide the current state and help needed in i18 SIG. We collected some information on translation usage, language, and content(GUI, doc, log etc). Motoki updated information from the Japan group but still, needs more information from other groups/translation users and agrees to add some queries in the 2023 user survey. Also, Brian will investigate the possibility of migration to weblate tool. * Action Item: 1. rosmaita: draft questions for the survey, get feedback from ian and seongsoo 2. rosmaita: follow up with weblate service to determine whether OpenStack qualifies for gratis service 3. Ian to reach out to contributors/users to know the translation requirements for applicable language. Possibilities to avoid RC time issues with Oslo release: ======================================== After discussing the issue that occurred for Sqlalchemy 2.0 related merge in the zed cycle, we discuss one option to propose the non-client feature freezes to m-2 and get more feedback from Oslo or other non-client lib maintainers. Also, we encourage adding the lib forward testing which tests the integration gate with the master version of lib which can help to find the issues while the code merges itself. As discussed Elod proposed the review to get more feedback[3] and also email it to ML[4]. After getting feedback from Oslo maintainer it seems it is not a good idea to preponed the lib feature freeze. Discussion is going on in ML[4]. Clean up Zuul config errors: ===================== At the end of the session, we discussed the current zuul config error in OpenStack projects. TC is actively working on this and knikolla and other members trying to fix them as much as possible. Please check your projects and fix them, priority is to fix the master and supported branches, not the EM state branches. [1] https://docs.openstack.org/project-team-guide/spread-the-word.html [2] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [3] https://review.opendev.org/c/openstack/releases/+/861900 [4] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030914… -gmann

1 0

Follow up on https://storyboard.openstack.org/#!/story/2010377
by rajiv mucheli 22 Oct '22

22 Oct '22

Hi, Unlike Openstack Yoga, where the setuptools version was set in upper-contstraints.txt. This is not set in Openstack Zed, which uses jammy with python 3.10. I get the below while performing few tests : - [[ -f /failure ]] - echo Wheel failed to build - cat /failure Wheel failed to build thrift===0.16.0 python-nss===1.0.1 We will need to stay with setuptools <58 to fix the 2to3 compiler issue, else anyjson packages adds up to the above list, but thrift is removed when setuptools >63. Regards, Rajiv

2 5

[PTL][TC] library *feature* freeze at Milestone-2
by Elõd Illés 22 Oct '22

22 Oct '22

Hi, During 'TC + Community leaders interaction' [1] a case was discussed, where a late library release caused last minute fire fighting in Zed cycle, and people discussed the possibility to introduce a (non-client) library *feature* freeze at Milestone-2 to avoid similar issues in the future. I've started to propose the possible schedule change [2] (note: it's not ready yet as it does not emphasize that at Milestone-2 we mean *feature* freeze for libraries, not "final library release"). The patch already got some reviews from library maintainers so I'm calling the attention to this change here on the ML. Thanks everyone for the responses in advance, Előd [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030718… [2] https://review.opendev.org/c/openstack/releases/+/861900

4 5

[neutron]: DVR with OVN
by Farhad Sunavala 21 Oct '22

21 Oct '22

Hi, Just want to get a feel with how users are using DVR with OVN especially for a medium sized installation (500 nodes, 3000-4000 VMs)Are you just using it in the default configuration with all the complexities and just take the hit when troubleshooting why a particular path doesn't work as expected? Are you taking precautions such as providing VMs with a separate direct path to the public network in case the main interface connected to DVR fails?See OpenInfra 17th minute of Live Ep. 26 Large Scale Neutron Best Practices @ (340) OpenInfra Live Ep. 26: Large Scale OpenStack: Neutron Scaling Best Practices - YouTube | | | | | | | | | | | OpenInfra Live Ep. 26: Large Scale OpenStack: Neutron Scaling Best Pract... | | | Is DVR with OVN reasonably solid for production environments that makes you comfortable enough to use it in installations with around 5000 VMs? thanks,Fred.

1 0

[tripleo] gate blocker centos 9 content provider - trending fixed
by Marios Andreou 21 Oct '22

21 Oct '22

Hello FYI (few folks asking in irc apologies should have sent sooner) gate blocker on the content provider https://bugs.launchpad.net/tripleo/+bug/1984237/comments/5 thanks chkumar we are trying to get a fix through gate at https://review.opendev.org/c/openstack/tripleo-quickstart/+/856582 please hold your recheck until that merges or use depends-on thank you!

2 1

Track Chair Nominations Close in One Week!
by Helena Spease 21 Oct '22

21 Oct '22

Hey everyone! Track Chair nominations <https://openinfrafoundation.formstack.com/forms/trackchairnominations2023> for the 2023 OpenInfra Summit in Vancouver (June 13-15, 2023) are closing soon! Please submit your nominations before they close on October 28, 2022 Track Chairs for each Track will help build the Summit schedule, and are made up of individuals working in open infrastructure. Responsibilities include: - Help the Summit team put together the best possible content based on your subject matter expertise - Promote the individual Tracks within your networks - Review the submissions and Community voting results in your particular Track - Determine if there are any major content gaps in your Track, and if so, potentially solicit additional speakers directly to submit - Ensure diversity of speakers and companies represented in your Track - Avoid vendor sales pitches, focusing more on real-world user stories and technical, in-the-trenches experiences 2023 Summit Tracks: - 5G/NFV & Edge - AI/Machine Learning/HPC - CI/CD - Container Infrastructure - Getting Started - Hardware Enablement - Open Development - Private & Hybrid Cloud - Public Cloud - Security - Hands On Workshops Full track descriptions are available here <https://openinfra.dev/summit/vancouver-2023/summit-tracks/>. If you’re interested in nominating yourself or someone else to be a member of the Summit Track Chairs for a specific Track, please fill out the nomination form <https://openinfrafoundation.formstack.com/forms/trackchairnominations2023>. Nominations will close on October 28th, 2022. Track Chairs selections will occur before we close the Call for Presentations (CFP) so that the Chairs can host office hours to consult on submissions, and help promote the event. CFP will be opening in November, registration <https://openinfrasummit2023.eventbrite.com/> and sponsorship <http://openinfra.dev/summit/vancouver-2023/summit-sponsor/> information are already available. Please email speakersupport(a)openinfra.dev with any questions or feedback. Cheers, Helena Spease

1 0

[ptl][release][stable][EM] Extended Maintenance - Wallaby
by Elõd Illés 21 Oct '22

21 Oct '22

Hi, In less than a two weeks Wallaby is planned to transition to Extended Maintenance phase [1] (planned date: November 2nd, 2022). The release patches for the transition have been generated [2], these patches mark the latest release in stable/wallaby with wallaby-em. PTLs and release liaisons are encouraged to approve them as soon as possible, by latest before the transition date. After the transition stable/wallaby will be still open for bug fixes, but there won't be any official releases. Note: if a team wants to do a final release before the transition, then it can be done, but be careful to not release fixes that could break things to avoid broken releases as *final* stable Wallaby release. Thanks, Előd irc: elodilles @ #openstack-releases [1] https://releases.openstack.org/ [2] https://review.opendev.org/q/topic:wallaby-em

1 0

Seeking help for Keystone Error while assign_role_to_user for a Project in Openstack SDK
by Ayush Jaiswal 21 Oct '22

21 Oct '22

Hi Team, I am using the Openstack SDK in my django rest api project where I have to create a new project and assign various users with different roles to that project in openstack. However, while adding a user to a project I am getting the following error. [image: image.png] Complete details of the steps I followed that resulted in this error are in the text file attached with this email. Kindly help me resolve this issue. Your support is highly appreciated. -- Thanks and Regards, Ayush Jaiswal

1 0

[victoria] Loose network on all instance.
by Albert Shih 21 Oct '22

21 Oct '22

Hi, I've a small openstack installation running Victoria on Ubuntu 20 LTS. After a update (not upgrade) of Ubuntu, I loose all network on all my instance. On a instance console I got : [[0;32m OK [0m] Started [0;1;39mifup for ens3[0m. Starting [0;1;39mRaise network interfaces[0m... [[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (1min 4s / 6min 2s) M[K[[0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (1min 4s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (1min 5s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (1min 5s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for Raise ne��ork interfaces (1min 6s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m] A start job is running for Raise ne��ork interfaces (1min 6s / 6min 2s) M[K[ [0;31m*[0m] A start job is running for Raise ne��ork interfaces (1min 7s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m] A start job is running for Raise ne��ork interfaces (1min 7s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for Raise ne��ork interfaces (1min 8s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (1min 8s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (1min 9s / 6min 2s) M[K[[0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (1min 9s / 6min 2s) M[K[[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��rk interfaces (1min 10s / 6min 2s) M[K[[0m[0;31m* [0m] A start job is running for Raise ne��rk interfaces (1min 10s / 6min 2s) M[K[[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��rk interfaces (1min 11s / 6min 2s) M[K[[0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��rk interfaces (1min 11s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��rk interfaces (1min 12s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��rk interfaces (1min 12s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for Raise ne��rk interfaces (1min 13s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m] A start job is running for Raise ne��rk interfaces (1min 13s / 6min 2s) M[K[ [0;31m*[0m] A start job is running for Raise ne��rk interfaces (1min 14s / 6min 2s) ...... ...... M[K[ [0;31m*[0;1;31m*[0m] A start job is running for Raise ne��rk interfaces (2min 59s / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m*[0m] A start job is running for Raise network interfaces (3min / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise network interfaces (3min / 6min 2s) M[K[ [0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (3min 1s / 6min 2s) M[K[[0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (3min 1s / 6min 2s) M[K[[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (3min 2s / 6min 2s) M[K[[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (3min 2s / 6min 2s) M[K[[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (3min 3s / 6min 2s) M[K[[0;31m*[0;1;31m*[0m[0;31m* [0m] A start job is running for Raise ne��ork interfaces (3min 3s / 6min 2s) M[K[[0;32m OK [0m] Finished [0;1;39mRaise network interfaces[0m. [K[[0;32m OK [0m] Reached target [0;1;39mNetwork[0m. Starting [0;1;39mInitial cloud-ini�� (metadata service crawler)[0m... [ 186.709234] cloud-init[514]: Cloud-init v. 20.4.1 running 'init' at Thu, 20 Oct 2022 20:12:41 +0000. Up 186.69 seconds. [ 186.727021] cloud-init[514]: ci-info: ++++++++++++++++++++++++++++++++++++Net device info+++++++++++++++++++++++++++++++++++++ [ 186.728928] cloud-init[514]: ci-info: +--------+------+------------------------------+-----------+-------+-------------------+ [ 186.730709] cloud-init[514]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address | [ 186.732694] cloud-init[514]: ci-info: +--------+------+------------------------------+-----------+-------+-------------------+ [ 186.734765] cloud-init[514]: ci-info: | ens3 | True | fe80::f816:3eff:fec3:2e6c/64 | . | link | fa:16:3e:c3:2e:6c | [ 186.736681] cloud-init[514]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . | [ 186.738473] cloud-init[514]: ci-info: | lo | True | ::1/128 | . | host | . | [ 186.740246] cloud-init[514]: ci-info: +--------+------+------------------------------+-----------+-------+-------------------+ [ 186.741723] cloud-init[514]: ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++ [ 186.742306] cloud-init[514]: ci-info: +-------+-------------+---------+-----------+-------+ [ 186.742881] cloud-init[514]: ci-info: | Route | Destination | Gateway | Interface | Flags | [ 186.743460] cloud-init[514]: ci-info: +-------+-------------+---------+-----------+-------+ [ 186.744075] cloud-init[514]: ci-info: | 1 | fe80::/64 | :: | ens3 | U | [ 186.744681] cloud-init[514]: ci-info: | 3 | local | :: | ens3 | U | [ 186.745255] cloud-init[514]: ci-info: | 4 | multicast | :: | ens3 | U | [ 186.745833] cloud-init[514]: ci-info: +-------+-------------+---------+-----------+-------+ in the log of neutron-linuxbridge-agent.log it seem everything should work : 2022-10-20 20:17:54.967 59611 INFO neutron.plugins.ml2.drivers.agent._common_agent [req-9e6b23d3-1e0e-4c48-8f0e-30d761233188 - - - - -] Port tap4f68bcf1-4d updated. Details: {'device': 'tap4f68bcf1-4d', 'network_id': '9223f9ff-7ab0-4268-9b7f-3b5966625c65', 'port_id': '4f68bcf1-4d32-4ad3-a0df-0415f7170c5d', 'mac_address': 'fa:16:3e:c3:2e:6c', 'admin_state_up': True, 'network_type': 'flat', 'segmentation_id': None, 'physical_network': 'provider', 'mtu': 1500, 'fixed_ips': [{'subnet_id': '12cdcc06-bbf0-48f2-b303-bdfab460c696', 'ip_address': '145.238.137.52'}], 'device_owner': 'compute:nova', 'allowed_address_pairs': [], 'port_security_enabled': True, 'qos_policy_id': None, 'network_qos_policy_id': None, 'profile': {}, 'propagate_uplink_status': False} But I'm unable to ping any instance. Any idea ? Regards -- Albert SHIH 🦫 Observatoire de Paris France Heure locale/Local time: jeu. 20 oct. 2022 22:47:15 CEST

2 1

[designate] [release] Proposing to EOL Designate stable branches Queens, Rocky, Stein, and Train
by Michael Johnson 20 Oct '22

20 Oct '22

Today at the Designate PTG session we discussed the number of stable branches (10) we are carrying for Designate and the lack of interest in maintaining them. For example, there has not been a patch merged on the Queens branch for over two years. Based on the discussion, and lack of patches merged to the older branches, I am proposing we move the Queens, Rocky, Stein, and Train stable branches from extended maintenance to end-of-life status. The definition of this process is part of the project team guide[1]. I plan to propose patches for the required changes next week. If you would like to maintain one of these branches, please respond to this email and post a patch to the branch to resolve any existing issues on the older branches. Michael [1] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l…

1 0

[i18n] questions for the user survey
by Brian Rosmaita 20 Oct '22

20 Oct '22

Hello people interested in internationalization, At the PTG this week, the i18n SIG drafted some questions for the 2023 OpenStack User Survey. Please look them over and leave any comments on the etherpad: https://etherpad.opendev.org/p/oct2022-ptg-openstack-i18n-user-survey-quest… We need to get these to the Foundation quickly, so please leave your comments before 1200 UTC on Monday 24 October.

1 0

[glance] Slow image download when using glanceclient
by Lucio Seki 20 Oct '22

20 Oct '22

Hi glance experts, I'm using the following code to download a glance image: ``` from glanceapi import client ... glance = client.Client(GLANCE_API_VERSION, session=sess) ... with open(path, 'wb') as image_file: data = glance.images.data(image_id) for chunk in tqdm(data, unit='B', unit_scale=True, unit_divisor=1024): image_file.write(chunk) ``` And I get a speed around 3kB/s. It would take months to download an image. I'm using python3-glanceclient==3.6.0. I even tried: ``` for chunk in tqdm(data, unit='B', unit_scale=True, unit_divisor=1024): pass ``` to see if the bottleneck was the disk I/O, but didn't get any faster. In the same environment, when I use the glance CLI instead: ``` glance image-download --file $path $image_id ``` I get hundreds of MB/s download speed, and it finishes in a few minutes. Is there anything I can do to improve the glanceclient performance? I'm considering using subprocess.Popen(['glance', 'image-download', ...]) if nothing helps... Regards, Lucio

3 6

[all][tc] 2023.1 Antelope TC-PTG Planning
by Ghanshyam Mann 20 Oct '22

20 Oct '22

Hello Everyone, As you already know that the 2023.1 cycle virtual PTG will be held between Oct 17th - 21[1]. I have started the preparation for the Technical Committee PTG sessions. Please do the following: 1. Fill the below poll as per your availability. - https://framadate.org/yi8LNQaph5wrirks 2. Add the topics you would like to discuss to the below etherpad. - https://etherpad.opendev.org/p/tc-2023-1-ptg NOTE: this is not limited to TC members only; I would like all community members to fill the doodle poll and, add the topics you would like or want TC members to discuss in PTG. [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030041.… -gmann

2 4

[PTG][nova][neutron] Nova-Neutron cross-team meetings
by Rodolfo Alonso Hernandez 20 Oct '22

20 Oct '22

Hello all: The Nova-Neutron cross-team sessions today, starting at 13UTC, will be on Nova channel "bexar". In any case, I'll send an update in our IRC channel and I'll keep "mitaka" session open to redirect people to "bexar". Regards.

1 0

[dev][infra][tact-sig] Updating Zuul's default-ansible-version to 6
by Jeremy Stanley 19 Oct '22

19 Oct '22

Just a heads up for folks not following the OpenDev Collaboratory's service-announce mailing list... now that Zed is officially released, we'll be increasing the default Ansible version for Zuul jobs from 5 to 6 in preparation for Zuul to drop Ansible 5 support in coming weeks. See the full announcement here: https://lists.opendev.org/pipermail/service-announce/2022-October/000046.ht… -- Jeremy Stanley

2 1

[horizon] Cancelling Two Weekly Meeting
by vishal manchanda 19 Oct '22

19 Oct '22

Hello Team, As discussed in Yesterday's PTG meeting, there will be no horizon weekly meeting for today and next week. The next horizon weekly meeting will be on 2nd November. Thanks & Regards, Vishal Manchanda

1 0

DC DR Setup Queries
by KK CHN 19 Oct '22

19 Oct '22

List, We are having a client DC running on HP( HP simplivity) HCI servers, With VMware ( Vsphere 7.0) only few VMs running on it. (11 VMs maximum all Linux VMs). The DR site also having the same HCI setup another location. ( The VMs are replicated to DR site with HP simplivity). We are planning to use Openstack for both DC and DR solutions with Wallaby or Xena version with KVM as hypervisor to replace the proprietary S/W and H/W vendor locking. The requirement is to Setup a Stable DC- DR solution. Totally confused How to setup a best Dc- DR solution for this purpose. The DR setup can be possible / advisable with Zero down time ?( or manual DR site uping with downtime of hours ) ? What are the available/suggested DC-DR replication mechanisms for high degree of application data protection and service availability? Kindly advise.. Thanks in advance, Krish

2 2

[cloudkitty] Another core team cleanup
by Pierre Riteau 18 Oct '22

18 Oct '22

Hello, Almost exactly two years since the last core team cleanup [1], it's probably time to have another one. I don't think we have heard from these contributors in the last couple of years: Justin Ferrieu jferrieu(a)objectif-libre.com Luis Ramirez luis.ramirez(a)opencloud.es Luka Peschke mail(a)lukapeschke.com Maxime Cottret maxime.cottret(a)gmail.com Stéphane Albert sheeprine(a)nullplace.com Jeremy Liu liuj285(a)chinaunicom.cn Is everyone okay with removing cloudkitty-core membership for these users? Cheers, Pierre Riteau (priteau) [1] https://lists.openstack.org/pipermail/openstack-discuss/2020-October/017751…

2 3

[ovn][neutron] RE: OVN BGP Agent query
by Ihtisham ul Haq 18 Oct '22

18 Oct '22

Hi Luis and Daniel, Please see inline response. > From: Daniel Alvarez Sanchez <dalvarez(a)redhat.com> > Sent: 29 September 2022 11:37 > Subject: Re: OVN BGP Agent query > > Hi Ihtisham and Luis, > > On Thu, Sep 29, 2022 at 7:42 AM Luis Tomas Bolivar <ltomasbo(a)redhat.com> wrote: > > Some comments and questions inline > > > > On Tue, Sep 27, 2022 at 1:39 PM Ihtisham ul haq <ihtisham.uh(a)hotmail.com> wrote: > > > Hi Luis, > > > > > > Thanks for your work on the OVN BGP Agent. We are planning > > > to use it in our OVN deployment, but have a question regarding it. > > > > Great to hear! Can you share a bit more info about this environment? like > > openstack version, target workload, etc. We plan to use this with Yoga version. Our workload consist of enterprise users with VMs running on Openstack and connected to their enterprise network via transfer network(to which the customer neutron router is attached to). And we also have public workload but with the ovn-bgp we only want to we want to advertise the former. > > > > > The way our current setup with ML2/OVS works is that our customer VM IP routes > > > are announced via the router IP(of the that customer) to the leaf switch instead of > > > the IP of the host where the neutron BGP agent runs. And then even if the > > > router fails over, the IP of the router stays the same and thus the BGP route > > > doesn't need to be updated. > > > > Is this with Neutron Dynamic Routing? When you say Router IP, do you mean the virtual neutron router and its IP associated with the provider network? What type of IPs are you announcing with BGP? IPs on provider network or on tenant networks (or both)? Yes, that's with Neutron DR agent, and I meant virtual neutron router with IP from the provider network. We announce IPs of our tenant network via the virtual routers external address. > > If the router fails over, the route needs to be updated, doesn't it? Same IP, but exposed in the new location of the router? Correct. > The route to the tenant network doesn't change, ie. > 192.168.0.0 via 172.24.4.100 (this route remains the same regardless of where 172.24.4.100 is). > If there's L2 in the 172.24.4.0 network, the new location of 172.24.4.100 will be learnt via GARP announcement. In our case, this won't happen as we don't have L2 so we expose directly connected routes to overcome this "limitation". Right, in our case we have a stretched L2 transfer network(mentioned above) to which our gateway nodes and customer routers are connected to, so we can advertise the IPs from the tenant network via the virtual router external IP and thus the location of the router isn't relevant in case of failover as its address will be relearned. > In the case of Neutron Dynamic Routing, there's no assumption that everything is L3 so GARPs are needed to learn the new location. > > > > We see that the routes are announced by the ovn-bgp-agent via the host IP(GTW) in our > > > switch peers. If that's the case then how do you make sure that during failover > > > of a router, the BGP routes gets updated with the new host IP(where the router > > > failed over to)? > > > > The local FRR running at each node is in charge of exposing the IPs. For the IPs on the provider network, the traffic is directly exposed where the VMs are, without having to go through the virtual router, so a router failover won't change the route. > > In the case of VMs on tenant networks, the traffic is exposed on the node where the virtual router gateway port is associated (I suppose this is what you refer to with router IP). In the case of a failover the agent is in charge of making FRR to withdraw the exposed routes on the old node, and re-advertise them on the new router IP location > > > > > Can we accomplish the same route advertisement as our ML2/OVS setup, using the ovn-bgp-agent? > > I think this is technically possible, and perhaps you want to contribute that functionality or even help integrating the agent as a driver of Neutron Dynamic Routing? Sounds good, our plan currently is to add this to the ovn-bgp-agent, so we can announce our tenant routes via virtual routers external address on a stretched L2 network, to make it work with our use case. -- Ihtisham ul Haq Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>.

3 5

[kolla] Monasca removal, Kafka and Zookeeper deprecation/removal
by Michał Nasiadka 18 Oct '22

18 Oct '22

Hello, As Kolla/Kolla-Ansible projects are implementing switch to OpenSearch - it became obvious to remove Elasticsearch (which is EOL in Kolla-provided version) and orchestrate a direct upgrade into OpenSearch. Part of this work is removal of elasticsearch and log stash Kolla container images and elasticsearch role in Kolla-Ansible. Since Monasca is relying on Elasticsearch and Logstash - and there are no contributors willing to make it work with OpenSearch inside Kolla/Kolla-Ansible - we decided to drop Monasca support in Zed release (especially that the CI jobs have been long failing). One of the Monasca dependencies is Kafka (and ZooKeeper) - is there anybody using it outside of Monasca deployment in Kolla/Kolla-Ansible? If in 4 weeks there will be no answers to this question - we will also remove Kafka and ZooKeeper container images in Kolla (and their respective roles in Kolla-Ansible). Thanks Michal

1 0

[cinder] cancelling this week's meeting (19 Oct)
by Rajat Dhasmana 18 Oct '22

18 Oct '22

Hello Argonauts, Since we've PTG this week, we will not be conducting the weekly meeting on 19th Oct 2022 but everyone is recommended to attend the PTG instead[1]. See you all at the PTG! [1] https://etherpad.opendev.org/p/antelope-ptg-cinder Thanks and regards Rajat Dhasmana

1 0

[kolla] Weekly meeting 20th Oct 2022
by Michał Nasiadka 18 Oct '22

18 Oct '22

Hello, Since this is PTG week - this week meeting is cancelled. Best regards, Michal

1 0

[tacker] Cancelling IRC meeting on Oct 18
by Yasufumi Ogawa 18 Oct '22

18 Oct '22

Hi team, Since we're going to have the vPTG session, I'd like to cancel IRC meeting today. Thanks, Yasufumi

1 0

[keystone] Cancelling weekly meeting for 10/18/22
by Dave Wilde 17 Oct '22

17 Oct '22

Cancelling due to the PTG

1 0

[ptls][tc] 2022 OpenStack User Survey Project Question Responses
by Allison Price 17 Oct '22

17 Oct '22

Hi everyone, Please find attached the responses to the project questions from the 2022 OpenStack User Survey. Based on feedback last year, I included additional, non-identifiable information that will hopefully help provident deployment context for the responses to your questions. If you need a reminder of your project question, you can review the OpenStack User Survey [1]. During the PTG, I would encourage you and your teams to review the responses and decide if you would like to make any changes to your question for the 2023 OpenStack User Survey. It is live now, but we can make changes ahead of significant promotion. Please reach out to me directly with any changes. If you have any questions on how to read the results, please let me know. Have a great week at the PTG! Cheers, Allison [1] https://www.openstack.org/usersurvey

2 4

[kolla][ptg] Meetings on Tuesday 18th Oct
by Michał Nasiadka 17 Oct '22

17 Oct '22

Hello Koalas, Due to exhaustion of topics - we’re meeting tomorrow only on the Kolla Operator Hour at 16 UTC. Kolla Operator Hour Etherpad: https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-kolla Best regards, Michal Nasiadka

1 0

[manila] Cancelling two weekly meetings
by Carlos Silva 17 Oct '22

17 Oct '22

Hello, Zorillas! As agreed in the previous week, we will be cancelling the next two weekly meetings: from this week (Oct 20th) and next week (Oct 27th). The next weekly meeting for Manila will be on Nov 3rd. Thank you, carloss

1 0

[release] Release countdown for week R-22, Oct 17 - 21
by Előd Illés 17 Oct '22

17 Oct '22

Hi, Welcome back to the release countdown emails! These will be sent at major points in the 2023.1 Antelope development cycle, which should conclude with a final release on March 22nd, 2023. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2023.1 Antelope development cycle, assessing 2023.1 Antelope community goals and approving 2023.1 Antelope specs. General Information ------------------- 2023.1 Antelope is a 24 weeks long development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/antelope/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the Zed release are continued in 2023.1 Antelope with a similar release model. Upcoming Deadlines & Dates -------------------------- Virtual PTG: October 17-21, 2022 Antelope-1 milestone: November 17th, 2022 Előd Illés irc: elodilles @ #openstack-release

1 0

[openstack-helm] No Weekly IRC Meeting - PTG
by Gage Hugo 17 Oct '22

17 Oct '22

Hey team, This week is the PTG so the weekly IRC meeting is cancelled. We will be meeting for an hour at the same time slot for our PTG session: https://ptg.opendev.org/ptg.html

1 0

[0SSN-0090] Best practices when configuring Glance with COW backends
by Brian Rosmaita 17 Oct '22

17 Oct '22

Best practices when configuring Glance with COW backends --- ### Summary ### When deploying Glance in a popular configuration where Glance shares a common storage backend with Nova and/or Cinder, it is possible to open some known attack vectors by which malicious data modification can occur. This note reviews the known issues and suggests a Glance deployment configuration that can mitigate such attacks. ### Affected Services / Software ### Glance, all supported releases (Queens through Zed) ### Discussion ### This note applies to you if you are operating an end-user-facing glance-api service with the 'show_multiple_locations' option set to True (the default value is False) or if your end-user-facing glance-api has the 'show_image_direct_url' option set to True (default value is False). Our recommendation is that the image "locations" and "direct_url" fields [0] *never* be displayed to end users in a cloud. This can be accomplished by running two glance-api services: - A "user-facing" glance-api that is accessible to end users and which appears in users' service catalogs. - An "internal-only-facing" glance-api that is accessible only to those services that require access to the 'direct_url' or image location fields, and which is protected by firewalls from access by end users. (Nova, Cinder, and Ironic all have configuration options to specify the Glance API endpoint each service uses [1].) This dual glance-api deployment was suggested in "Known Issues" in Glance release notes in the Rocky [2] through Ussuri releases, but it seems that the idea has not received sufficient attention. Hence this security note. The attack vector that becomes available when image locations are exposed to end users was originally outlined in OSSN-0065 [3], though that note was not clear about the attack surface or mitigation, and contained some forward-looking statements that were not fulfilled. The attack vector is: [A] malicious user could create an image in Glance, set an additional location on that image pointing to an altered image, then delete the original location, so that consumers of the original image would unwittingly be using the malicious image. Note, however, that this attack vector cannot change the original image's checksum, and it is limited to images that are owned by the attacker. OSSN-0065 suggests that this is only an issue when users do not checksum their image data. It neglects the fact that in some popular deployment configurations in which Nova creates a root disk snapshot, data is never uploaded to Glance, but instead a snapshot is created directly in the backend and Nova creates a Glance image record with "size" 0 and an empty "os_hash_value" [4], making it impossible to compare the hash of downloaded image data to the value maintained by Glance. Further, when Nova is configured to use the same storage for ephemeral disks that is used as a Glance image store, Nova efficiently creates a server root disk directly in the backend without checksumming the image data. This is an intentional design choice to optimize storage space and host resources, but an implication is that even if the image record has a recorded hash, it is not being checked at the point of image consumption. Similarly, when using a shared backend, or a cinder glance_store, Cinder will efficiently clone a volume created from an image directly in the backend without checksumming the image data. Again, this is done intentionally in order to optimize resources, but it is important to be aware of the security tradeoff being made by this configuration. In other words, if the image data is not going to be checked at the point of image consumption, then extra care needs to be taken to ensure the integrity of the data path. OSSN-0065 suggested that the attack vector of substituting image data by modifying the image locations could be addressed by using policies, but that has turned out not to be the case. The only way currently to mitigate this vector is to deploy glance-api in a dual configuration as described above, namely with an internal-only-facing glance-api used by Nova and Cinder (that has show_multiple_locations enabled), and an end-user-facing glance-api (that has show_multiple_locations disabled). So far the focus has been on 'show_multiple_locations'. When that setting is disabled in Glance, it is not possible to manipulate the locations via the OpenStack Images API. Keep in mind, however, that in any Glance/Nova/Cinder configuration where Nova and/or Cinder do copy-on-write directly in the image store, image data transfer takes place outside Glance's image data download path, and hence the os_hash_value is *not* checked. Thus, if the backend store is itself compromised and image data is replaced directly in the backend, the substitution will *not* be detected. This brings us to the 'show_image_direct_url' option, which includes a "direct_url" field in the image-show response that can be used by various OpenStack services to consume images directly from the storage backend. Exposing the 'direct_url' to end users leaks information about the storage backend. What exactly that information consists of depends upon the backend in use and how it is configured, but in general, it is not a good idea to provide hints that could be useful to malicious actors in their attempts to compromise the backend storage by some type of independent exploit. The 'direct_url', being read-only, may appear innocuous, but its use by services is usually to perform some kind of optimized image data access that most likely does not include computing a hash of the image data. We therefore recommend that OpenStack services that require exposure of the 'direct_url' image property be similarly configured to use an internal-only-facing glance-api. It is worth nothing that end users who wish to download an image do not require access to the 'direct_url' image property because they can simply use the image-data-download API call [5]. ### Recommended Actions ### A glance-api service with 'show_multiple_locations' enabled should *never* be exposed directly to end users. This setting should only be enabled on an internal-only-facing glance-api that is used by OpenStack services that require access to image locations. This could be done, for example, by running two glance-api services with different configuration files and using the appropriate configuration options for each service to specify the Image API endpoint to access, and making sure the special internal endpoint is firewalled in such a way that only the appropriate OpenStack services can contact it. Similarly, enabling 'show_image_direct_url' exposes information about the storage backend that could be of use to malicious actors in as yet unknown exploits, so it should likewise only be enabled on an internal-only-facing glance-api. ### Notes / References ### [0] https://docs.openstack.org/api-ref/image/v2/index.html#show-image-schema [1] Nova and Ironic use 'endpoint_override' in the '[glance]' section of the configuration file; Cinder uses 'glance_api_servers' in the '[DEFAULT]' section. [2] OSSN-0065: https://wiki.openstack.org/wiki/OSSN/OSSN-0065 [3] The Glance "multihash" metadata pair of 'os_hash_algo' and 'os_hash_value' were introduced in Rocky to replace the legacy md5 'checksum' field. The python-glanceclient has used multihash checksumming for download verification since version 2.13.0. [4] https://docs.openstack.org/releasenotes/glance/rocky.html#known-issues [5] https://docs.openstack.org/api-ref/image/v2/index.html?#download-binary-ima… ### Contacts / References ### Author: Brian Rosmaita, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0090 Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1990157 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: none

1 0

[swift] upgrade newton to train in containers
by Marcel 17 Oct '22

17 Oct '22

I'm planning an upgrade for our newton based swift cluster (OOO vm based) to a (kolla image based containers) train cluster So far I have tested the upgrade for the proxies, account_servers and container servers and it looks promising. I have in a test environment: - switched to the new proxies with the old ring files and it looks like everything works normally - Added the new (train) account and container servers to the rings and it looks like all is fine - Removed the old account and container servers, still fine - tested fall back, also fine My question actually is: Did the account and container database format change between newton and train in such a way that I might run into troubles trying the upgrade as tested above in ways that I did not yet foresee? Thanks Marcel

1 0

[Neutron] Bug Deputy Report Oct 10 - 17
by Jakub Libosvar 17 Oct '22

17 Oct '22

Hi all, I was the bug deputy last week, here is the report. Nothing that requires immediate attention. Medium ------ - [ovn-octavia-provider] Detach OVN-LB LS from the LR breaks OVN-LB connectivity https://bugs.launchpad.net/neutron/+bug/1992363 assigned to Luis Fix proposed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/860781 - [scale] Setting a gateway on router is killing database https://bugs.launchpad.net/neutron/+bug/1992950 Assigned to Arnaud Morin Fix proposed: https://review.opendev.org/c/openstack/neutron/+/861322 - Disable in-band flow management in the ovs bridges https://bugs.launchpad.net/neutron/+bug/1992953 Assigned to Slawek Fix proposed: https://review.opendev.org/c/openstack/neutron/+/861351 Wishlist ------- - fip will loss when it migrate between dvr-sant agent and dvr_no_external in Rocky https://bugs.launchpad.net/neutron/+bug/1992542 The reported bug uses unsupported configuration dvr_snat agent mode on the compute nodes. Cheers Kuba

1 0

[kolla][ptg] Using Meetpad instead of Zoom
by Michał Nasiadka 17 Oct '22

17 Oct '22

Hello, If you’re planning on joining the Kolla PTG - please use Meetpad - https://meetpad.opendev.org/kolla-antelope-ptg Sorry for last minute changes Best regards, Michal

1 0

[ptg][nova][placement] Nova/Placement at the PTG, howto
by Sylvain Bauza 17 Oct '22

17 Oct '22

Hey stackers, Got some questions about how/when joining the Nova community at the PTG during this week, so I'll provide you a howto ;) *What is the main document for the Nova PTG ?* This : https://etherpad.opendev.org/p/nova-antelope-ptg Please, please, don't try to translate this etherpad directly as you'll see. *I'm an operator and I want to tell you how terrible you folks are* There : https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-nova Again, don't try to translate this document or you'll create problems for people who don't know your language. *When do you folks discuss ?* Monday : 14:00-15:00 UTC Ironic/Nova cross-project session Tuesday : 13:00 - 15:00 UTC Operator hours. If you are an operator, please join us ! :-) 15:00 - 17:00 UTC Nova sessions for contributors 15:10 UTC (possibly) : Nova team photo Wednesday : 13:00 - 16:00 UTC Nova sessions for contributors 16:00 - 17:00 Operator hour. If you are an operator, please join us ! :-) Thursday : 13:00 - 15:00 UTC Neutron/Nova cross-project session 15:00 - 17:00 UTC Nova sessions for contributors Friday : 13:00 - 17:00 UTC Nova sessions for contributors *How to join ?* Simple. You can look at https://ptg.opendev.org/ptg.html if you want so you'll see what topic we are currently discussing. If you want to arrive, just click either on "operator-hour" nova tag or "nova-placement" tag and it will automatically open the Google Meet client for joining the Nova meeting. If you also want, you can directly join us by using this link https://www.openstack.org/ptg/rooms/bexar (we'll use the same virtual room for all our sessions) *What if you can't join the whole days ?* No worries ! Just make sure you use an IRC client and just go to the #openstack-nova channel. Once you're there, add your IRC in the etherpad for every topic you'd like to be around and then I'll ping you when we start discussing for those topics you added your nick. *What if I want to add some topic I'd like to discuss ?* Easy peasy. Two possibilities : - you are a contributor and you want to add a new feature in nova. Just add your topic in the main etherpad (link above). Make sure your name is marked in the topic title (like every other topic) and I'll ping you when we start discussing your topic. - you are an operator and you want to discuss wishlists or bugs or whatever else. Good news, we have specific timeslots for you ! See the agenda above, we have *operator hours* that are intended for operators to join and engage on specific deployment and operational topics. Just then look at https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-nova and add your points, we'll discuss them during the operator hours (given above). Hope you'll find your way and you'll appreciate the PTG as much productive as we do. In any case, my IRC nick is bauzas. Don't hesitate to bug me over IRC (#openstack-dev, #openstack-nova or #openinfra-events) or reach me by email (sbauza(a)redhat.com) I'll try to answer you as much as I can. HTH and thanks, -Sylvain

1 0

Re: Installing out-of-tree ML2 neutron plugins with kolla-ansible
by Radosław Piliszek 17 Oct '22

17 Oct '22

Hi Aditya, First of all, please remember to always CC the mailing list so that other users can benefit from the answers. Regarding the question at hand - the same documentation (starting from the beginning of the page) describes the kolla-build tool, including the usual way to install it. Remember to install the version for your OpenStack release - the right source of versions is [1]. The kolla-build tool is the tool to build the images. I assume so far you have used the prebuilt ones. This time you will have to build your own because you want to add software inside of them. You might also be interested in deploying your own local registry. The simplest way to do so is via [2] but understand it is not production-ready unless in a strictly isolated network (for other use cases I generally recommend Harbor [3]). [1] https://docs.openstack.org/releasenotes/kolla/ [2] https://docs.openstack.org/kolla-ansible/yoga/user/multinode.html#deploy-a-… [3] https://goharbor.io/ Kind regards, Radek -yoctozepto On Sun, 16 Oct 2022 at 21:43, Aditya Sathish <saditya(a)vt.edu> wrote: > > Hi Radek, > > This was incredibly helpful. However, I couldn't find where the kolla-build.conf file is and should I create my own, where I have to add this. > > Regards, > Aditya. > > On Sun, Oct 16, 2022 at 3:10 PM Radosław Piliszek <radoslaw.piliszek(a)gmail.com> wrote: >> >> I believe you want to first install the plugin in the container image. >> The section on plugins might be of interest to you. [1] >> >> [1] https://docs.openstack.org/kolla/yoga/admin/image-building.html#plugin-func… >> >> Kind regards, >> Radek >> -yoctozepto >> >> On Sun, 16 Oct 2022 at 20:31, Aditya Sathish <saditya(a)vt.edu> wrote: >> > >> > Hello, >> > >> > I am trying to use an out-of-tree ML2 neutron plugin with OpenStack with Kolla-Ansible but I am having a hard time figuring out how to go about it. >> > >> > For example, this is my repository for the plugin: https://github.com/adityasathis/networking-onos. >> > >> > I have made changes to the deployment YML files to allow configuration for this new neutron plugin from the global.yml file. However, I am not able to figure out how to copy over my plugin files and install them on the controller node. >> > >> > I came across the commit: https://opendev.org/openstack/kolla-ansible/commit/418cb52767270d85e28a6f30… which, I think, does what I'm looking to do and so I kept the networking-onos directory (with the setup.py in it) in the /etc/kolla/config/neutron/plugins directory. The deploy script is able to detect the file in the "Checking for ML2 plugins" step however, I'm not able to copy it anywhere in the "Copying ML2 plugin" step. Am I missing something? >> > >> > Regards, >> > Aditya.

3 2

[ptg][cinder] Finalized Schedule
by Rajat Dhasmana 17 Oct '22

17 Oct '22

Hello Everyone, I've finalized the schedule for cinder PTG[1] based on the topics, number of hours of PTG and as per the date and time suited to the authors. Please go through it and let me know if any changes are needed. I've also included a *Courtesy Ping* section with each topic so the people interested in a particular topic will get a ping when it is being discussed. Please include your IRC nick in front of it if you would like to be notified. The schedule includes a Day wise topic list where, except for monday, we've PTG from 1300-1700 UTC (where the last hour acts as a buffer time for extended topic discussions or other planned activities). Following are some of the highlight events of each day, Monday: TC + PTL session: 1500-1700 UTC Tuesday: First day of cinder PTG Operator hour from 1500-1600 UTC Wednesday: Team photo at 1400 UTC (timing could be changed based on the topic duration before it) Thursday: Drivers Day! Friday: Festival of XS reviews (If we've enough time left) [1] https://etherpad.opendev.org/p/zed-ptg-cinder Thanks and regards Rajat Dhasmana

1 1

[TripleO][PTG]TripleO Antelope PTG schedule and other relevant Information
by Rabi Mishra 17 Oct '22

17 Oct '22

Hi All, As you all would already know, 2023.1(Antelope) PTG will start in a few hours from now. TripleO PTG schedule has been published @ https://etherpad.opendev.org/p/oct2022-ptg-tripleo for your reference. We would have sessions spanning across 2 days i.e. 17th Oct(Monday) and 18th Oct(Tuesday) from 13:00-17:00 UTC @https://www.openinfra.dev/ptg/rooms/ocata . Hope to see you there. Some other relevant information: - Please register for the event, if you've not already done so @ https://openinfra-ptg.eventbrite.com - PTG Page https://ptg.opendev.org/ptg.html - PTG Bot: https://opendev.org/openstack/ptgbot -- Regards, Rabi Mishra

1 0

[Glance]Weekly Meeting cancelled for Next 2 Weeks
by Pranali Deore 17 Oct '22

17 Oct '22

Hello, There will be no weekly meeting *this week* due to PTG sessions and *next week of PTG *as well, as most of the team members will not be around during that week. Next meeting will be directly on Nov 3rd. See you in the PTG !! Thanks, Pranali Deore

1 0

[nova][keystone] What happens to key pairs after user is deleted
by Artem Goncharov 17 Oct '22

17 Oct '22

Hi all, From the API perspective it is possible to delete user without deleting its key pairs. Practice showed, however, that keypairs of deleted user still exist and can be queried by API knowing id of the deleted user (at least in devstack and 1 other public cloud). I know it may be tricky if there is still VM provisioned with the key, but deleting user logically means nobody has access to the private key anyway. And since key pairs belong to users and not to projects it is not possible to clean them up in the project cleanup either. Actually from the API pov there is no reasonable way to ever find those (without knowing ID of the deleted user which is logically not known anymore). If there is no cleanup this can in the mid term cause trashing the database (records are small, but still), especially when using “dynamic” users to perform some actions. So far I haven’t tried to grep through code basis of Nova to check what is happening, neither tried to check behavior over time, and decided first to ask here whether somebody knows what should be generally happening here, is it a bug or feature? Thanks, Artem

3 3

[openstack-ansible] Meeting on 18th of October 2022 is being cancelled
by Dmitriy Rabotyagov 17 Oct '22

17 Oct '22

Hello everyone, Due to the PTG week, our regular meeting on Tuesdays will be cancelled on 18.10.2022. At the same time we will have a virtual discussion in Essex room [1]. Hope to see you there instead! [1] https://www.openinfra.dev/ptg/rooms/essex

1 0

[openstack-ansible][ptg] Antelope PTG schedule
by Dmitriy Rabotyagov 17 Oct '22

17 Oct '22

Hi everyone! As you might know, Project Teams Gathering is happening this week as a virtual event and OpenStack-Ansible has its own slots as well. On Tuesday, 18th of October at 14:00 - 17:00 UTC all contributors and interested parties are welcome to join us to discuss future development priorities in Essex room [1]. You can find topics that will be discussed in etherpad [2]. It's also not too late to add something extra there! Also, this year is the first time when Operator Hours were introduced. So if you're operator and have questions or proposals to the team - please join us on Wednesday, 19th of October at 14:00 - 15:00 UTC in Folsom room [3]. We also do have some questions for operators, to understand better how OpenStack-Ansible is being used and where we should focus our efforts. For that pease, use the following Etherpad [4] Hope seeing everyone soon! [1] https://www.openinfra.dev/ptg/rooms/essex [2] https://etherpad.opendev.org/p/osa-antelope-ptg [3] https://www.openinfra.dev/ptg/rooms/folsom [4] https://etherpad.opendev.org/p/osa-antelope-operator-hours

1 0

[neutron] Neutron meetings cancelled this week
by Rodolfo Alonso Hernandez 17 Oct '22

17 Oct '22

Hello: As you may know, this week is the PTG. Any regular Neutron meeting (team meeting, drivers meeting, CI meeting) will be cancelled and resumed next week. Regards.

1 0

[neutron] next CI meeting cancelled
by Slawek Kaplonski 17 Oct '22

17 Oct '22

Hi, Due to the PTG sessions this week, lets cancel Neutron CI meeting. See You on the PTG and on the next CI meeting which will be on Oct 25th. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Outreachy
by fola fomduwir carine 17 Oct '22

17 Oct '22

3 2

[swift][ptg] Ops feedback session - Oct 19 at 13:00 UTC
by Matthew Oliver 17 Oct '22

17 Oct '22

As we've done in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in Diablo (https://www.openinfra.dev/ptg/rooms/diablo) at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, We'd appreciate it if you can offer some feedback on the feedback etherpad ( https://etherpad.opendev.org/p/swift-antelope-ops-feedback) This has always been a highlight at every PTG for us swift devs. Have your say and help make Swift even better! Matt

1 0

[cyborg] Antelope PTG, agenda and schedule
by Alex Song (宋文平) 17 Oct '22

17 Oct '22

Hello Cyborg team: Please check the agenda and schedule for the Antelope PTG: https://etherpad. opendev.org/p/antelope-cyborg-ptg See you! Regards.

1 0

Installing out-of-tree ML2 neutron plugins with kolla-ansible
by Aditya Sathish 16 Oct '22

16 Oct '22

Hello, I am trying to use an out-of-tree ML2 neutron plugin with OpenStack with Kolla-Ansible but I am having a hard time figuring out how to go about it. For example, this is my repository for the plugin: https://github.com/adityasathis/networking-onos. I have made changes to the deployment YML files to allow configuration for this new neutron plugin from the global.yml file. However, I am not able to figure out how to copy over my plugin files and install them on the controller node. I came across the commit: https://opendev.org/openstack/kolla-ansible/commit/418cb52767270d85e28a6f30… which, I think, does what I'm looking to do and so I kept the networking-onos directory (with the setup.py in it) in the /etc/kolla/config/neutron/plugins directory. The deploy script is able to detect the file in the "Checking for ML2 plugins" step however, I'm not able to copy it anywhere in the "Copying ML2 plugin" step. Am I missing something? Regards, Aditya.

2 2

[all][tc][goal][policy] RBAC goal discussion in 2023.1 PTG
by Ghanshyam Mann 15 Oct '22

15 Oct '22

Hello Everyone, I hope you have seen my other email about RBAC goal progress and what are the targets for the 2023.1 cycle[1]. Please plan and discuss the RBAC work on your project and bring your queries to discuss in the TC PTG slot on Thursday 17 UTC. You can add the query in the below etherpad under RBAC goal topic - https://etherpad.opendev.org/p/tc-2023-1-ptg#L71 [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030863… -gmann

1 0

[all][tc][goals] : "Consistent and Secure Default RBAC" goal: Zed Timeline updates
by Ghanshyam Mann 15 Oct '22

15 Oct '22

Hello Everyone, As you know, "Consistent and Secure Default RBAC" is one of the currently selected community-wide goals and we have divided it into multiple milestones (cycle)[1]. OpenStack Zed is released, I am going to summarize the progress of Zed timeline targets. Please note that progress is as per the new direction/targets decided in the Zed cycle which is to implement the project personas and drop the system scope. Gerrit Topic: https://review.opendev.org/q/topic:%2522secure-rbac%2522+(status:open+OR+st… Tracking: https://etherpad.opendev.org/p/rbac-goal-tracking Completed: ========= * Nova * Neutron * Glance * Manila * Ironic (no change needed for the direction change in Zed cycle) * Manager Support ** Completed *** Ironic 2023.1 Release Timeline[2] =================== 1. All services must implement Phase 1 (Implement project personas) 2. Services start implementing Phase 2 (Move service-to-service APIs to service role) 3. Services start implementing Phase 3 (Implement 'Manager' role where applicable) The 1st one is important and all services must implement the project personas (drop system scope if already implemented). Please plan this work for next week PTG and join TC discussion on this goal on THURSDAY: 17-19 UTC for any query from the project side. [1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… -gmann

1 0

[Diversity][PTG] Diversity and Inclusion WG session at PTG and meeting changes
by Amy Marrich 14 Oct '22

14 Oct '22

The Diversity and Inclusion WG will be holding its session on Monday at 14:00UTC in the Folsom room. On the agenda[0] are holding a Diversity Survey for the Foundation in 2023 which includes all projects and Community Leadership Mentorship. We have also moved our regular monthly meetings to the Second Tuesday of the month at 14:00UTC and we have also moved back from video to IRC with the meetings taking place in #openinfra-diversity on OFTC. Amy (spotz) 0 - https://etherpad.opendev.org/p/oct2022-ptg-diversity

1 0