March 2024 - openstack-discuss - lists.openstack.org

[neutron][horizon] disable permission to release floating ip for non-admin users
by Satish Patel 08 Mar '24

08 Mar '24

Folks, I want to disable permission or the horizon button or whatever best way to not allow end users to "Release floating IP" because I want them to stick with assigned IP and not releasing them because of some regulatory process. Not sure what is the best way to have this level of control. I found neutron policy delete_floatingip: but is this the correct way to implement this policy? OR Does Horizon have some level of ACL to remove buttons or disable it? Looking for advice or clues. Thanks!

3 2

[nova][telemetry][watcher][requirements] RFE requests for client libraries
by Elõd Illés 08 Mar '24

08 Mar '24

Hi Requirements team, During today's Release Management weekly meeting we discussed 3 extra client library releases that we would like to ask for Requirements Freeze Exception for: - python-aodhclient [1] 3.5.1 - python-novaclient [2] 18.6.0 - python-watcherclient [3] 4.4.0 contents: [1] python-aodhclient (from comment on the release patch): "Indeed, c10ea92f050b9c53d398eb4570feab2cc442bed7<https://review.opendev.org/#/q/c10ea92f050b9c53d398eb4570feab2cc442bed7> from Dr. Harbott indicated install issues due to the lingering oslo.db cap, 80c9d8608a2f4d04999937800cc30bbf9fc482e0<https://review.opendev.org/#/q/80c9d8608a2f4d04999937800cc30bbf9fc482e0> flagged that there was issue on release notes building that we had missed. And as we had to get those in we also improved testing (not affecting the lib) 31fec512e3ba3c596866c234eefc7a33506c8ef7<https://review.opendev.org/#/q/31fec512e3ba3c596866c234eefc7a33506c8ef7>." c10ea92 Remove oslo.db test cap 31fec51 Add functional tests for prometheus type alarms 80c9d86 Fix releasenotes build of yoga moved to unmaintained [2] python-novaclient: 533d5df5 Bump microversion to 2.96 [3] python-watcherclient 9aace80 Update python classifier in setup.cfg 63d305c Remove untested lower-constraints.txt Thanks, Előd Illés irc: elodilles @ #openstack-release

1 0

[kolla][ptg] Reminder about 2024.2 PTG dates and call for ideas
by Michał Nasiadka 08 Mar '24

08 Mar '24

Hello Koalas, I’ve set up a Dalmatian/2024.2 PTG etherpad - https://etherpad.opendev.org/p/kolla-dalmatian-ptg If you have any ideas for improvements in Kolla/Kolla-Ansible/ansible-collection-kolla or Kayobe - feel free to add that somewhere under line 89. The PTGbot registered meeting slots are: 8-12 April 2024: • Monday - 13.00 - 17.00 UTC (general, Kolla and Kolla-Ansible) • Tuesday - 13.00 - 17.00 UTC (Kolla-Ansible) • Thursday - 13.00 - 15.00 UTC (Kayobe) See you then! Michal

1 0

[heat][monasca][sahara][senlin] Features dependent on inactive projects
by Takashi Kajinami 08 Mar '24

08 Mar '24

Hello, As you know, some of the OpenStack projects were marked inactive during this cycle. There are still on-going discussions but from my view these are very likely excluded from the upcoming 2024.1 release and it's unclear yet if any of these projects will be kept. Currently heat provides features integrated with some of the inactive projects (Monasca, Sahara and Senlin), and we have to decide how we deal with these features[1]. The main concern is that we can't maintain the features for the inactive projects, and IMO we should retire these features if these inactive projects are abandoned or are no longer maintained in the consistent way with the other active projects. Based on the current situation, I'd propose the following steps for upcoming cycles. - Deprecate the features dependent on inactive projects in 2023.2 release - Note that we have to remove these features directly during this cycle in case any problems related to these project block the upcoming heat release. - Remove these features in 2024.1 release unless we are sure that these projects are kept maintained as active projects in the openstack namespace, with following the global release cycle. Please let me know if you have any concern about the proposed plan. If I hear no objections then I'll propose patches for deprecation. Thank you, Takashi Kajinami irc: tkajinam [1] I've submitted a series of patches to remove these features and these would give a clear view about the features affected. https://review.opendev.org/q/topic:%22inactive-project-removal%22+project:o…

3 6

[release] Release countdown for week R-3, Mar 11-15
by Elõd Illés 08 Mar '24

08 Mar '24

Development Focus ----------------- The Release Candidate (RC) deadline is next Thursday, March 14th, 2024. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/2024.1 branch will be cut. This branch will track the 2024.1 Caracal release. Once stable/2024.1 has been created, the master branch will be ready to switch to 2024.2 Dalmatian development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing 2024.1 Caracal plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/2024.1 branch before a new release candidate can be proposed. Actions ------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from the master branch. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/2024.1 branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from the master branch (which will technically then be 2024.2 Dalmatian) to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any 2024.1 Caracal release so far. Finally, now is a good time to finalize release highlights. Release highlights help shape the messaging around the release and make sure that your work is properly represented. Upcoming Deadlines & Dates -------------------------- RC1 deadline: March 14th, 2024 (R-3 week) Final RC deadline: March 28th, 2024 (R-1 week) Final 2024.1 Caracal release: April 3rd, 2024 Dalmatian PTG: April 8-12, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[tacker][FFE] Mgmt driver sample for deploying Cilium
by Yasufumi Ogawa 08 Mar '24

08 Mar '24

Hi, I'd like to request FFE in this cycle for the update for introducing a sample of management driver for deploying Cilium with K8s VIM as I proposed at the previous IRC meeting. Please let me know if you have any comment although there was nothing opposite then. https://review.opendev.org/c/openstack/tacker/+/911639 Thanks, Yasufumi

1 0

[neutron] Is the vxlan(overlay) network a Provider network or a self-service network
by 韩光宇 08 Mar '24

08 Mar '24

Hi, In neutron install doc[1], I got the concept of Provider network and Self-service network. And I got that: - Provider network bridges virtual networks to physical networks and relies on physical network infrastructure for layer-3 (routing) services - Self-service network routes virtual networks to physical networks using Network Address Translation (NAT) So I understand: Flat/Vlan network are Provide network and vxlan/gre network are Self-service network. But, in openstack cmd, I found that all network types are classified as provider network types. ``` openstack network create --help ... --provider-network-type <provider-network-type> The physical mechanism by which the virtual network is implemented. For example: flat, geneve, gre, local, vlan, vxlan. ``` I am confused, why do vxlan and gre appear in the **provider network type**? According to the installation doc[1], overlay networks should not all be self-service networks Or is the provider network in cmd not the same as the provider network in the installation document, the provider network here is only different from the tenant network? Can someone help me distinguish between these concepts, or suggest questions that I can read: why vxlan is provider network I will appreciate for any help. Best wishes, Han Guangyu [1] https://docs.openstack.org/neutron/latest/install/controller-install-obs.ht…

2 1

[magnum] Speaker Requested for OpenInfra Day Türkiye
by Allison Price 07 Mar '24

07 Mar '24

Hi Magnum community, The organizers of OpenInfra Day Türkiye have reached out mentioning that Magnum has garnered great interest in Türkiye and would like to offer a keynote to any contributor who can provide an overview, new features and the roadmap of the project. The event is May 20 at Boğaziçi University in Istanbul. More information is available here: https://openinfraturkiye.org.tr/ Please let me know if you have any questions. If you represent another OpenStack project and are interested in providing an update, please feel free to reach out. Cheers, Allison Allison Price VP of Marketing & Community OpenInfra Foundation <https://openinfra.dev/> p: +1-214-686-6821

1 0

[cinder][glance][nova][telemetry][monasca][oslo][vmware] Can we deprecate(and remove) VMWare support ?
by Takashi Kajinami 07 Mar '24

07 Mar '24

Hi all, As you might know, some of the OpenStack projects currently support usage of VMWare component. However recently the VMware virt driver in nova was marked experimental in 2023.2 release [1] and it has been discussed that the driver will be removed in 2023.2 release[2], after deprecation is backported to 2023.1. (Please someone from nova team correct me if I'm wrong) So my current question is; Does it make sense to deprecate all of the features to support VMWare component ? My understanding is that these features were added to be used along with VMWare virt driver in nova, but once the virt driver is removed this use case is voided. I'll list up the features within the discussion scope below. nova: VMWare virt driver (this is already experimental by [1]) cinder: VMware Storage Driver (vmdk) glance: VMWare Datastore (I proposed deprecating this in [3][4]) ceilometer: VMWare virt driver (this was deprecated by [5]) os-brick: VmdkConnector monasca-agent: vcenter collector (*1) oslo.vmware: the whole project NOTE: These features are found based on dependency on oslo.vmware but there can be a few not listed here. Outside of OpenStack's governance, there are two projects dependent on oslo.vmware, networking-vsphere and vmware-nsx but both of these look inactive. Because of SLURP, we have to complete deprecation during in 2024.1 release so that we can drop the feature right after 2024.1. If we fail then we have to maintain these features until 2025.1 (the features already deprecated can be removed earlier, though). So I'd like to get feedback and decision before deadline for 2024.1 Thank you, Takashi (*1) Monasca is now inactive so I doubt anyone would work on this topic before it is retired. [1] https://review.opendev.org/c/openstack/nova/+/863911 [2] https://review.opendev.org/c/openstack/nova/+/897017 [3] https://review.opendev.org/c/openstack/glance_store/+/893696 [4] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] https://review.opendev.org/c/openstack/ceilometer/+/894540

6 21

[oslo][requirements] RFE for new tooz release
by Takashi Kajinami 07 Mar '24

07 Mar '24

Hello, We have identified a regression[1] in tooz 6.0.0, which is the latest version in 2024.1 u-c. I have identified its cause and prepared the bug fix[2] and the follow up change to fix CI coverage[3]. I'll create 6.0.1 release once both of these two land. I'm sending this email to get early approval to bump tooz version in caracal requirements. The bug is at least known to be blocking kolla, but would affect any deployment which is using redis sentinel as tooz backend. Thank you, Takashi [1] https://bugs.launchpad.net/python-tooz/+bug/2056429 [2] https://review.opendev.org/c/openstack/tooz/+/911648 [3] https://review.opendev.org/c/openstack/tooz/+/911682 [4] https://review.opendev.org/c/openstack/releases/+/911711 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0