- openstack-discuss - lists.openstack.org

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 02 Dec '22

02 Dec '22

Hello Neutrinos: Due to the lack of agenda, *today's meeting is cancelled*. I have one topic [1] I would like to discuss but I'll wait until I test the code and I'm sure the feature is working. Once this is done, I'll ask you to review it and vote for this RFE. Have a good weekend! [1]https://bugs.launchpad.net/neutron/+bug/1998202

1 0

[openstack-ansible] Removing support for Calico Network driver
by Dmitriy Rabotyagov 02 Dec '22

02 Dec '22

Hi everyone, Due to lack of maintainers of Calico driver support in OpenStack-Ansible we have decided to remove support for this driver. Eventually, CI was failing for Calico jobs for the last few cycles and we haven't seen any interest in further support of the feature. Patches for Calico removal are already proposed: https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/866123 https://review.opendev.org/c/openstack/openstack-ansible/+/866119 If you're interested in this driver and want to step in for fixing CI and supporting the feature, please let us know either by replying to this email or by voting accordingly for the mentioned patches. In case no negative feedback will be received we will merge them by the end of the next week, December 9 2022.

1 0

[Magnum] ls /etc/cni/net.d/ is emty
by Nguyễn Hữu Khôi 01 Dec '22

01 Dec '22

Hello guys. I use Magnum on Xena and I custom k8s cluster by labels. But My cluster is not ready and there is nothing in /etc/cni/net.d/ and my cluster said: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized And this is my labels kube_tag=v1.21.8-rancher1,container_runtime=containerd,containerd_version=1.6.10,containerd_tarball_sha256=507f47716d7b932e58aa1dc7e2b3f2b8779ee9a2988aa46ad58e09e2e47063d8,calico_tag=v3.21.2,hyperkube_prefix= docker.io/rancher/ Note: I use Fedora Core OS 31 for images. Thank you. Nguyen Huu Khoi

2 3

[kolla-ansible][Yoga][Magnum] How to delete a cluster containing errors
by wodel youchi 30 Nov '22

30 Nov '22

Hi, I have a magnum cluster stack which contains errors in its constituents, some of the VMs (minions) that belong to that cluster do longer exist. When I try to delete the stack it fails, and I get DELETE aborted (Task delete from ResourceGroup "kube_minions" [fddb3056-9b00-4665-b0d6-c3d3f176814b] Stack "testcluter01-puf45b6dxmrn" [d10af7f2-6ecd-442b-b1f9-140b79e58d13] Timed out) Is there a way to force the deletion to proceed even with those errors? Regards.

3 6

[cinder] Bug report from 11-23-2022 to 11-30-2022
by Sofia Enriquez 30 Nov '22

30 Nov '22

No meeting today due to Antelope Midcycle-1 (R-18). This is a bug report from 11-23-2022 to 11-30-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1998083 "volume_attachement entries are not getting deleted from DB." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1997980 "rbd: 'error updating features for image' when enabling multi-attach." Fix proposed to master. Low - https://bugs.launchpad.net/cinder/+bug/1997876 "Ceph backup: Improve error message when creating an incremental backup of a non-RBD volume." Unassigned. Cheers, Sofia -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[cinder] 2023.1 R-16 virtual mid cycle on 30th November (today)
by Rajat Dhasmana 30 Nov '22

30 Nov '22

Hello Argonauts, The first 2023.1 (Antelope) mid cycle R-16 will be held on 30th November (today) with the following details: Date: 30th November 2022 Time: 1400-1600 UTC Meeting link: https://bluejeans.com/556681290 Etherpad: https://etherpad.opendev.org/p/cinder-antelope-midcycles Thanks and regards Rajat Dhasmana

1 0

[neutron][releases] Proposing to EOL Train networking-ovn
by Rodolfo Alonso Hernandez 30 Nov '22

30 Nov '22

Hello: The transition of this branch to EM was done 1,5 years ago [1]. During this time the maintenance of Train networking-ovn has continued. However, due to the lack of time and personal resources, we can't properly maintain it. That leads to problems like [1]. The ML2/OVN driver was successfully merged in the Neutron repository in Ussury. We continue the development and improvement of this ML2 mechanism driver. A patch to mark this branch as EOL will be pushed in two weeks. If you have any inconvenience, please let me know in this mail chain or in IRC (ralonsoh, #openstack-neutron channel). You can also contact any Neutron core reviewer in the IRC channel. Regards. [1]https://review.opendev.org/c/openstack/releases/+/790760 [2]https://bugs.launchpad.net/neutron/+bug/1997262

1 0

Re: Unable to access Internet from an instance and accessing instance using floating-point IPs from external network
by Eugen Block 30 Nov '22

30 Nov '22

So you did modify the default security-group, ports 8000 and 8080 are not open by default. Anyway, can you please clarify what doesn't work exactly? Does the instance have an IP in the public network but the router is not pingeable (but that is not necessarily an issue) and you can't access it via which protocols? Does SSH work? Is the access blocked by a http_proxy? Zitat von vincent lee <vincentlee676(a)gmail.com>: > To add on to my previous email, I have attached an image of my security > group as shown below. > > Best regards, > Vincent > > On Tue, Nov 22, 2022 at 3:58 AM Eugen Block <eblock(a)nde.ag> wrote: > >> Just one more thing to check, did you edit the security-group rules to >> allow access to the outside world? >> >> Zitat von Adivya Singh <adivya1.singh(a)gmail.com>: >> >> > it should be missing a default route most of the time. >> > or check IP tables on router namespace the DNAT and SNAT are working >> > properly >> > >> > >> > >> > On Tue, Nov 22, 2022 at 9:40 AM Tobias McNulty <tobias(a)caktusgroup.com> >> > wrote: >> > >> >> On Mon, Nov 21, 2022 at 7:39 PM vincent lee <vincentlee676(a)gmail.com> >> >> wrote: >> >> >> >>> After reviewing the post you shared, I believe that we have the correct >> >>> subnet. Besides, we did not modify anything related to the cloud-init >> for >> >>> openstack. >> >>> >> >> >> >> I didn't either. But I found it's a good test of the network! If you are >> >> using an image that doesn't rely on it you might not notice (but I >> >> would not recommend that). >> >> >> >> >> >>> After launching the instances, we are able to ping between the >> instances >> >>> of the same subnet. However, we are not able to receive any internet >> >>> connection within those instances. From the instance, we are able to >> ping >> >>> the router IP addresses 10.42.0.56 and 10.0.0.1. >> >>> >> >> >> >> To make sure I understand: >> >> - 10.42.0.56 is the IP of the router external to OpenStack that provides >> >> internet access >> >> - This router is tested and working for devices outside of OpenStack >> >> - OpenStack compute instances can ping this router >> >> - OpenStack compute instances cannot reach the internet >> >> >> >> If that is correct, it does not sound like an OpenStack issue >> necessarily, >> >> but perhaps a missing default route on your compute instances. I would >> >> check that DHCP is enabled on the internal subnet and that it's >> providing >> >> everything necessary for an internet connection to the instances. >> >> >> >> Tobias >> >> >> >> >> >> >> >> >> >> >> > > -- > thanks you. > vincentleezihong > 2garnet > form2

1 0

[all][tc] Technical Committee next weekly meeting on 2022 Nov 30 at 1600 UTC
by Ghanshyam Mann 30 Nov '22

30 Nov '22

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2022 Nov 30, at 1600 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Tuesday, Nov 29 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[Kolla-ansible][Neutron] VMs not getting public IPs if attached directly to public subnet
by wodel youchi 30 Nov '22

30 Nov '22

Hi, We have an HCI deployment with 3 controllers and 9 compute/storage nodes. Two of the controllers have the role of neutron server. The platform uses two bonded interfaces : bond1 : is used for : *neutron_external_interface* bond0 : with many vlans on top of it to segregate the rest of the networks : - bond0 : vlan natif used for nodes deployment (dhcp, tftp, pxeboot) - bond0.10 : vlan 10 ceph public - bond0.20 : vlan 20 ceph cluster - bond0.30 : vlan 30 API - bond0.40 : vlan 40 tunnel * - bond0.50 : vlan 50 Public network, here are the public IPs of the 03 controllers, the public horizon VIP interface is created here.* In our configuration we have *"enable_neutron_provider_networks = yes"*, which means that an instance can have a public IP directly without using a virtual-router + NAT. But it does not work. If we create and instance with a private network, then we attach to it a floating IP, the VM is reachable from the Internet, but if we attach the VM directly to the public network, it does not get an IP address from the public pool, we think it's a dhcp problem but we could not find the source, we think it's the *Vlan part.* The controllers are in Vlan 50, if we create a virtual-router it gets its public IP without any problem. But if we are not mistaken, if an instance is plugged directly into the public network, it uses bond1 to send its dhcp requests, but since this interface is not in vlan 50, the requests don't get to the controllers, is this right? If yes, is there a solution? can we use bond1.50 as an interface for kolla's *neutron_external_interface * instead? Regards.

3 3

[OVB - openstack-virtual-baremetal] - Douglas Viroel and Chandan Kumar as core
by Harald Jensas 29 Nov '22

29 Nov '22

Hi, After discussions with Douglas, Chandan and Ronelle Landy I would like to suggest adding Douglas and Chandan to the OVB core team. The repository have very little activity, i.e there is not a lot of review history to base the decision on. I did work with both individuals when onboarding new clouds to run TripleO CI jobs utilizing OVB, they have a good understanding of how the thing works. If there are no objections, I will add them to them as core reviewers next week. Regards, Harald

3 3

[openstack-ansible] Designate: role seems trying to update DNS server pools before syncing database
by Taltavull Jean-François 29 Nov '22

29 Nov '22

Hello, During the first run, the playbook 'os-designate-install.yml' fails and the 'designate-manage pool update' command produces the log line below: 'Nov 25 11:50:06 pp3controller1a-designate-container-53d945bb designate-manage[2287]: 2022-11-25 11:50:06.518 2287 CRITICAL designate [designate-manage - - - - -] Unhandled error: oslo_messaging.rpc.client.RemoteError: Remote error: ProgrammingError (pymysql.err.ProgrammingError) (1146, "Table 'designate.pools' doesn't exist")' Looking at the 'os_designate' role code shows that the handler ` Perform Designate pools update` is flushed before tables are created in the 'designate' database. O.S.: Ubuntu 20.04 OpenStack release: Wallaby OSA tag: 23.2.0 Regards, Jean-Francois

2 4

[neutron] neutron-db-manage multiple heads
by Eugen Block 29 Nov '22

29 Nov '22

Hi *, I'd like to ask you for advice on how to clean up my neutron db. At some point (which I don't know exactly, probably train) my neutron database got inconsistent, apparently one of the upgrades did not go as planned. The interesting thing is that the database still works, I just upgraded from ussuri to victoria where that issue popped up again during 'neutron-db-manage upgrade --expand', I'll add the information at the end of this email. Apparently, I have multiple heads, and one of them is from train, it seems as if I never ran --contract (or it failed and I didn't notice). Just some additional information what I did with this database: this cloud started out as a test environment with a single control node and then became a production environment. About two and a half years ago we decided to reinstall this cloud with version ussuri and import the databases. I had a virtual machine in which I upgraded the database dump from production to the latest versions at that time. That all worked quite well, I only didn't notice that something was missing. Now that I finished the U --> V upgrade I want to fix this inconsistency, I just have no idea how to do it. As I'm not sure how all the neutron-db-manage commands work exactly I'd like to ask for some guidance. For example, could the "stamp" command possibly help? Or how else can I get rid of the train head and/or how to get the train revision to "contract" so I can finish the upgrade and contract the victoria revision? I can paste the whole neutron-db history if necessary (neutron-db-manage history), please let me know what information would be required to get to the bottom of this. Any help is greatly appreciated! Thanks! Eugen ---snip--- controller01:~ # neutron-db-manage upgrade --expand [...] alembic.script.revision.MultipleHeads: Multiple heads are present for given argument 'expand@head'; 633d74ebbc4b, I38991de2b4 controller01:~ # neutron-db-manage current --verbose Running current for neutron ... INFO [alembic.runtime.migration] Context impl MySQLImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. Current revision(s) for mysql+pymysql://neutron:XXXXX@controller.fqdn/neutron: Rev: bebe95aae4d4 (head) Parent: b5344a66e818 Branch names: contract Path: /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/ussuri/contract/bebe95aae4d4_.py Rev: 633d74ebbc4b (head) Parent: 6c9eb0469914 Branch names: expand Path: /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/expand/633d74ebbc4b_.py Rev: I38991de2b4 (head) Parent: 49d8622c5221 Branch names: expand Path: /usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/victoria/expand/I38991de2b4_source_and_destination_ip_prefix_neutron_metering_rule.py OK ---snip---

2 10

Re: Unable to access Internet from an instance and accessing instance using floating-point IPs from external network
by Tobias McNulty 29 Nov '22

29 Nov '22

On Mon, Nov 21, 2022 at 7:39 PM vincent lee <vincentlee676(a)gmail.com> wrote: > After reviewing the post you shared, I believe that we have the correct > subnet. Besides, we did not modify anything related to the cloud-init for > openstack. > I didn't either. But I found it's a good test of the network! If you are using an image that doesn't rely on it you might not notice (but I would not recommend that). > After launching the instances, we are able to ping between the instances > of the same subnet. However, we are not able to receive any internet > connection within those instances. From the instance, we are able to ping > the router IP addresses 10.42.0.56 and 10.0.0.1. > To make sure I understand: - 10.42.0.56 is the IP of the router external to OpenStack that provides internet access - This router is tested and working for devices outside of OpenStack - OpenStack compute instances can ping this router - OpenStack compute instances cannot reach the internet If that is correct, it does not sound like an OpenStack issue necessarily, but perhaps a missing default route on your compute instances. I would check that DHCP is enabled on the internal subnet and that it's providing everything necessary for an internet connection to the instances. Tobias

4 3

[all] Cargo Culted Tox install_command overrides
by Clark Boylan 29 Nov '22

29 Nov '22

A subset of tempest jobs recently began to exhibit some interesting behavior. The tox installation was finding the global pip installation instead of pip in the tox virtualenv which led to an attempt to install packages globally which failed. Eventually, I discovered the reason this happened was that virtualenv created a broken venv installation for tox, but this was made far more confusing by two tox settings in tempest's tox.ini: install_command and allowlist_externals. Tempest had overridden install_command to ` pip install {opts} {packages}` and set allowlist_externals to `*`. This allowed tox to find and use global pip without complaint. Tempest has since cleaned these up with this change [0], which should result in nicer error messages in the future if we have similar problems. I have noticed that many projects have cargo culted this configuration, particularly for install_command [1]. The default install_command for tox is `python -m pip install {opts} {packages}` [2]. This is almost equivalent to our overrides except that it uses pip as a module. This is important in this case because we don't install python2 regularly which means there is no `python` command except for in the created virtualenv where `python` == `python3`. The resulting behavior difference here would have been helpful to have when debugging the underlying issue in tempest. All that to say, I would suggest that those who have install_command set similarly to tempest remove this unnecessary configuration. Separately, setting allowlist_externals to `*` allows all global commands to run without complaint or an indication they are being used. Far fewer projects have this problem though [3]. Those that do should consider updating their config to explicitly list the commands they actually need from outside the virtualenv. Neither of these changes is critical, but I wanted people to be aware of this as we seem to have copied it all over the place. [0] https://review.opendev.org/c/openstack/tempest/+/865314 [1] https://codesearch.opendev.org/?q=install_command&i=nope&literal=nope&files… [2] https://tox.wiki/en/latest/config.html#conf-install_command [3] https://codesearch.opendev.org/?q=allowlist_externals%20%3D%20%5C*&i=nope&l…

1 0

[oslo] New driver for oslo.messaging
by 王坤田 28 Nov '22

28 Nov '22

Hello: I want to develop a new driver for oslo.messaging to use rocketmq in openstack environment. I wonder if the community need this new driver？ Best Regards！

4 3

[neutron] Bug deputy report, Nov. 21. - Nov. 27.
by Lajos Katona 28 Nov '22

28 Nov '22

Hi Neutron Team I was the bug deputy in neutron last week, please check my summary. Needs attention ================= * networking-ovn-dsvm-functional-py27 job killed on timeout in stable/train branch (https://bugs.launchpad.net/neutron/+bug/1997262) *Stable only* * [ovn-octavia-provider] Octavia LB stuck in PENDING_UPDATE after creation (https://bugs.launchpad.net/neutron/+bug/1997567 ) *HIGH* * neutron_lib.exceptions.InvalidInput: Invalid input for operation: Segmentation ID should be lower or equal to 4095 ( https://bugs.launchpad.net/neutron/+bug/1997955 ) *Incomplete* * related doc bug: Manual install & Configuration in Neutron incorrect vni_ranges leads to error (https://bugs.launchpad.net/neutron/+bug/1998085 ) *LOW* * Prevent initializing "ovn-router" service if OVN mech driver is not called (https://bugs.launchpad.net/neutron/+bug/1997970 ) *MEDIUM* * [fullstack] Error in "test_logging" ( https://bugs.launchpad.net/neutron/+bug/1997965 ) *High* In Progress ================= * [ovn-octavia-provider] HM not working for FIPs ( https://bugs.launchpad.net/neutron/+bug/1997418 ) * Neutron server doesn't wait for port DHCP provisioning while VM creation ( https://bugs.launchpad.net/neutron/+bug/1997492 ): https://review.opendev.org/c/openstack/neutron/+/865470 * "convert_to_sanitized_mac_address" shoudl accept netaddr.EUI type values ( https://bugs.launchpad.net/neutron/+bug/1997680 ): https://review.opendev.org/c/openstack/neutron-lib/+/865517 * after restart of a ovn-controller the agent is still down ( https://bugs.launchpad.net/neutron/+bug/1997982 ): https://review.opendev.org/c/openstack/neutron/+/865697 Already merged ================ * [DHCP] Error in "call_driver" method ( https://bugs.launchpad.net/neutron/+bug/1997964) https://review.opendev.org/c/openstack/neutron/+/840421

1 0

Does openstack have an official automatic evacuation instance scheme
by 韩光宇 28 Nov '22

28 Nov '22

Hi all, I would like to ask whether the openstack community has an official automatic evacuation instance scheme？ I have a openstack cluster, and all of glance, nova and cinder has used ceph. So I have a basic of instance HA. I want to imply automatic evacuation instance, but I'm a newer in this. Does the community have any related projects or recommended open source solutions? Any help is greatly appreciated! Thanks! Han

2 1

[neutron] Switching the ML2 driver in-place from linuxbridge to OVN for an existing Cloud
by Christian Rohmann 26 Nov '22

26 Nov '22

Hello openstack-discuss and neutron experts, I'd like to ask for your input and discussion on the idea of changing the ML2 driver for an existing cloud, read: changing a tire while still riding the bike. I actually like to find out if it's feasible to switch from the trusted Linuxbridge driver to the more modern SDN stack of OVN - in place. With all existing user networks, subnets, security groups and (running) instances in the database already. And while I know there a push of migrating from OVS to OVN and a clear migration path documented (https://docs.openstack.org/neutron/latest/ovn/migration.html) but they are much more similar in their data plane. And to get this out of the way: I am not asking to do be able to do this without downtime, interruptions, migrations or any active orchestration of the process. I just want to know all the possible options apart from setting up a new cloud and asking folks to migrate all of their things over... 1) Are the data models of the user managed resources abstract (enough) from the ML2 used? So would the composition of a router, a network, some subnets, a few security group and a few instances in a project just result in a different instantiation of packet handling components, but be otherwise transparent to the user? 2) What could be possible migration strategies? While it might be a little early to think about the actual migration steps. But just to consider more than a full cloud shutdown following a cold start with modified neutron config then using the OVN ML2. I know there is more than just the network and getting a virtual layer 2 network. There are DHCP, DNS and the metadata service and last but not least the gateway / router and the security groups. But if using VXLAN for OVN (as Linuxbridge uses currently) could the shift from one implementation to the other potentially be done node by node? Or project by project by changing the network agents over to nodes already running OVN? If not, is there any other hot cut-over approach that would avoid having to shutdown all the instances, but only cause them some network downtime (until the next DHCP renew or similar?) Has anybody ever done something similar or heard about this being done anywhere? Thanks for your time and input, Christian

3 5

[all][tc] What's happening in Technical Committee: summary 2022 Nov 25: Reading: 5 min
by Ghanshyam Mann 25 Nov '22

25 Nov '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ *This week's meeting was cancelled. * Next TC weekly meeting will be on Nov 30 Wed at 16:00 UTC. Feel free to add the topic to the agenda[1] by Nov 29. 2. What we completed this week: ========================= * Nothing specific this week. 3. Activities In progress: ================== TC Tracker for 2023.1 cycle --------------------------------- * Current cycle working items and their progress are present in 2023.1 tracker etherpad[2]. Open Reviews ----------------- * Five open reviews for ongoing activities[3]. Technical Election changes (Extending Nomination and voting period) ---------------------------------------------------------------------------------- As discussed in TC PTG sessions, TC is extending the technical election (PTL as well as the TC election) nomination and voting period from 1 week to 2 weeks. The TC charter change[4] is up for review and the changes will be effective from the 2023.2 cycle technical elections. Renovate translation SIG i18 ---------------------------------- * As the next step, Brian is working on the weblate funding proposal and it will be discussed with the Foundation staff and Board members in Dec 6th board meeting. Adjutant situation (project is not active) ----------------------------------------------- The adjutant project is not active. The last changes merged was on Oct 26, 2021 (more than 1 year back), Gate is broken also. During July this year, TC was marking this project as inactive[5] but Dale smith volunteered as PTL to maintain it. But there is no improvement in the situation yet. TC will be discussing it in the next TC meeting and decide the next step. Project updates ------------------- * Add Skyline repository for OpenStack-Ansible[6] * Add the cinder-infinidat charm to Openstack charms[7] * Add the infinidat-tools subordinate charm to OpenStack charms[8] * Add the manila-infinidat charm to Openstack charms[9] 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[10]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15:00 UTC [11] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-November/03124… [2] https://etherpad.opendev.org/p/tc-2023.1-tracker [3] https://review.opendev.org/q/projects:openstack/governance+status:open [4] https://review.opendev.org/c/openstack/governance/+/865367 [5] https://review.opendev.org/c/openstack/governance/+/849153 [6] https://review.opendev.org/c/openstack/governance/+/863166 [7] https://review.opendev.org/c/openstack/governance/+/863958 [8] https://review.opendev.org/c/openstack/governance/+/864067 [9] https://review.opendev.org/c/openstack/governance/+/864068 [10] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [11] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[all][stable][ptl] Propose to EOL Queens series
by Elõd Illés 25 Nov '22

25 Nov '22

Hi, As more and more teams decide about moving their Queens branches to End of Life, it looks like the time has come to transition the complete Queens stable release for every project. The reasons behind this are the following things: - gates are mostly broken - minimal number of bugfix backports are pushed to these branches - gate job definitions are still using the old, legacy zuul syntax - gate jobs are based on Ubuntu Xenial, which is also beyond its public maintenance window date and hard to maintain - lack of reviews / reviewers on this branch Based on the above, if no objection comes from teams, then I'll start the process of EOL'ing Queens stable series. Please let the community know what you think, or indicate if any of the projects' stable/queens branch should be kept open in Extended Maintenance. Thanks, Előd Illés irc: elodilles @ #openstack-stable / #openstack-release

1 1

[openstackclient] Consistency between OSC commands >>> consistency with legacy clients
by Stephen Finucane 25 Nov '22

25 Nov '22

👋 tl;dr: $subject I reviewed a patch against openstackclient (OSC) today [1] and left a rather lengthy comment that I thought worthy of bringing up to a wider audience. The patch itself doesn't matter so much as what is was trying to achieve, namely modifying an existing OSC command to better match the structure of the equivalent legacy client command. The review provides more detail than I do here but the tl;dr: is that this is a big no-no and OSC will and must maintain consistency between OSC commands over consistency with legacy clients. As I noted in the review, consistency is one of the biggest advantages of OSC over the legacy clients: if you know the name of the resource type you wish to work with, you can pretty accurately guess the command and its structure. This is a thing that operators have consistently said they love about OSC and its one of the key reasons we're trying to get every command to provide full current API implementations in OSC (and SDK). Now I get that the way some of these consistent commands have been implemented has been the cause of contention in the past. I don't imagine it remains any less contentious today. However, these patterns are well-understood, well-known patterns that have for the most part worked just fine for close to a decade now. The kind of patterns I'm thinking about include: * The command to create a new resource should always take the format '<resource> create <human-readable identifer> * The command to modify some property of a resource should always take the format '<resource> set --property=value <name-or-identifier>' * The command to list, fetch or delete resources should always take the format '<resource> list', '<resource> get <name-or-identifier>', and '<resource> delete <name-or-identifier>', respectively. * Boolean options should always take the form of flags with an alternate negative option like '--flag' and '--no-flag', rather than '-- flag=<true|false>' * And a couple of other things that we tend to highlight in reviews. We want to preserve this behavior, lest OSC lose this huge USP and devolve into a muddle mess of different ideas and various individuals'/teams' preferences. I'm more than happy to discuss and debate this stuff with anyone who's interested and we'll continue reviewing each patch on its merit and providing exceptions to these rules where they make sense, but it will remain an ongoing goal and it's something we'd like people to consider when working on OSC itself or any of its plugins. I will now get off my pedestal/ivory tower 🗼 Thanks! Stephen PS: I'm talking here about the command themselves, not their implementations. We do somethings extra in OSC that are user helpful, like allowing users to identify resources by their name in addition to by their UUIDs. We also currently do things that no so user helpful, like crashing and burning if the name lookups fail (I'm thinking about the various Glance-related commands that error out if a project name/ID is passed to a command and the user can't look up that project). These are things we're more than willing to fix and will happily accept patches for :) [1] https://review.opendev.org/c/openstack/python-openstackclient/+/865377

6 13

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 25 Nov '22

25 Nov '22

Hello Neutrinos: Due to the lack of agenda and quorum this week, the Neutron drivers meeting is cancelled today. Have a nice weekend and see you next week!

1 0

[tacker] Tacker's Legacy API deprecation
by Ayumu Ueha (Fujitsu) 25 Nov '22

25 Nov '22

Hi Tacker users, Tacker team is going to mark the Tacker's Legacy APIs [1] (excluding VIM feature) to "deprecated" in Antelope cycle. Please see etherpad [2] about list of target APIs. We follow deprecation guideline [3] of OpenStack, and need to know how many users use Tacker's Legacy API. Please let me know if anyone still uses the Legacy API that will be marked "deprecated" via Rest-API or CLI(python-tackerclient) or GUI(tacker-horizon). If no one is using it, we will obsolete it in C cycle as planned. Thanks. [1] https://docs.openstack.org/api-ref/nfv-orchestration/v1/legacy.html [2] https://etherpad.opendev.org/p/tacker-legacy-deprecation [3] https://docs.openstack.org/project-team-guide/deprecation.html#guidelines Best Regards, Ueha

1 0

[neutron] networking-midonet mantainers
by Rodolfo Alonso Hernandez 25 Nov '22

25 Nov '22

Hello Neutrinos: We have recently found some zuul errors related to networking-midonet. In order to fix them, we have pushed [1]. However, the CI status of this project is not in good shape. This mail is a kind request for maintainers of this project. We need to ensure that the stable branches are still accepting patches and the CI jobs are passing. Thank you in advance. [1] https://review.opendev.org/q/project:openstack%252Fnetworking-midonet+statu…

2 1