- openstack-discuss - lists.openstack.org

[neutron] Bug deputy report Feb 25 - Mar 4
by Jakub Libosvar 04 Mar '24

04 Mar '24

Hi, there were only 3 bugs reported. Nothing critical. High —— - [ovn-octavia-provider] OVN LB health checks for IPv6 not working Edit https://bugs.launchpad.net/neutron/+bug/2055876 Assigned to Fernando Low —— - [OVN] "LRP.external_ids" router name is incorrect, we are setting the ID only https://bugs.launchpad.net/neutron/+bug/2055045 Unassigned - [stable-only][OVN] Configure VETH interface MAC address before setting UP the device Edit https://bugs.launchpad.net/neutron/+bug/2055561 Assigned to Rodolfo Patches proposed and merged. May get closed soon.

1 0

[PTLs][release] 2024.1 / Caracal Cycle Highlights
by Herve Beraud 04 Mar '24

04 Mar '24

Hello Everyone! The deadline for cycle highlights is just a few days away, on March 8 [1]. Please be sure to get those in. I look forward to seeing what all you all have accomplished this release! How To Reminder: ------------------------- Simply add them to the deliverables/$RELEASE/$PROJECT.yaml in the openstack/releases repo like this: cycle-highlights: - Introduced new service to use unused host to mine bitcoin. The formatting options for this tag are the same as what you are probably used to with Reno release notes. Also, you can check on the formatting of the output by either running locally: tox -e docs And then checking the resulting doc/build/html/$RELEASE/highlights.html file or the output of the build-openstack-sphinx-docs job under html/$RELEASE/ highlights.html. Thanks [1] https://releases.openstack.org/caracal/schedule.html -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[publiccloud-sig] Reminder - next meeting March 6th - 0800 UTC
by Felix Kronlage-Dammers 04 Mar '24

04 Mar '24

Hi everyone, This Wednesday (March 6th) the next meeting of the public cloud sig is going to happen. We’ll be meeting at 0800 UTC here: https://meetpad.opendev.org/publiccloud-sig Important: this is a different place than previously. I’ve also updated the Wiki page of the Public-Cloud SIG to reflect this. See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG See you Wednesday! felix -- Felix Kronlage-Dammers Product Owner IaaS & Operations Sovereign Cloud Stack Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[cinder] FFE request for HPE XP: supporting HA in 2024.1
by 河合敦史 / KAWAI，ATSUSHI 04 Mar '24

04 Mar '24

Hi, I would like to request FFE in the 2024.1 Caracal cycle for the following patch: https://review.opendev.org/c/openstack/cinder/+/892608 Reason for FFE: This patch is one of the important feature for HPE XP driver because it supports a `storage assisted' High Availability. We added the patch into the feature lists for both 2023.2 Bobcat cycle, but it's been merged yet. Additionally, some bugfix patches have a relation chain to this patch. These includes a bug which issued at a customer site on RHOSP. These patches couldn't be merged until merged this patch. Best regards, Atsushi Kawai

2 2

[oslo][release][requirement] FFE request and RFE request for castellan
by Takashi Kajinami 04 Mar '24

04 Mar '24

Hello, We recently caught that castellan 4.4.0, the latest release for caracal, introduced the backword-incompatible change[1] which breaks the existing usage in nova. While we are resolving the problem by the change in nova[2], we discussed this problem in #openstack-release[3], and we agreed that we should make major bump with the upgrade impact properly documented in a release note to announce the breaking change more clearly. Based on the agreement, I'm now preparing a new castellan 5.0.0 release, with the upgrade note added[4]. I'd like to request approval about this release, and also the subsequent upper constraint change to pull castellan 5.0.0 to 2024.1 release. Please let me know if you have any question/concern/etc. Thank you, Takashi [1] https://review.opendev.org/c/openstack/castellan/+/895502/ [2] https://review.opendev.org/c/openstack/nova/+/896100 The same fix for cinder was merged some time ago. https://review.opendev.org/c/openstack/cinder/+/896121 [3] https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-rele… [4] https://review.opendev.org/c/openstack/castellan/+/910884 https://review.opendev.org/c/openstack/releases/+/910883 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

Re: openstack-discuss Digest, Vol 64, Issue 122
by BEDDA Fadhel 02 Mar '24

02 Mar '24

help: su -s /bin/bash keystone -c "keystone-manage db_sync" error : Exception ignored in: <function _removeHandlerRef at 0x7f33d74bc3a0> Traceback (most recent call last): File "/usr/lib/python3.10/logging/__init__.py", line 846, in _removeHandlerRef File "/usr/lib/python3.10/logging/__init__.py", line 226, in _acquireLock File "/usr/lib/python3.10/threading.py", line 164, in acquire File "/usr/lib/python3/dist-packages/eventlet/green/thread.py", line 34, in get_ident AttributeError: 'NoneType' object has no attribute 'getcurrent' Thanks Le ven. 1 mars 2024 à 11:17, <openstack-discuss-request(a)lists.openstack.org> a écrit : > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > Today's Topics: > > 1. [all][ptls][release] Action needed to move forward Unmaintained > branch policy > (Jay Faulkner) > 2. Re: [blazar] Proposing Mark Powers and Matt Crees as core reviewers > (Pierre Riteau) > 3. [oslo] Removing feature branches of oslo.messaging > (Takashi Kajinami) > 4. Re: [all][ptls][release] Action needed to move forward Unmaintained > branch policy > (Dmitriy Rabotyagov) > 5. Re: Need Help to setup Bumblebee VDI project (Andy Botting) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 29 Feb 2024 14:18:36 -0800 > From: Jay Faulkner <jay(a)gr-oss.io> > Subject: [all][ptls][release] Action needed to move forward > Unmaintained branch policy > To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > Message-ID: > < > CA+sTGNekJcbP3-ePYjq90ghSiYO-QiNB1dSd0XbVtjV6nktstQ(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="0000000000009bb91406128ca449" > > Hi all, > > If you are a PTL of a project, a release liason, or a person generally > interested in older OpenStack branches, please make sure you take a look at > the topic here: https://review.opendev.org/q/topic:%22vwx-unmaintained%22 > and vote appropriately on projects you care about. > > More information can be found in the commit message for the patches > themselves. > > A lot of folks have done work behind the scenes to enable this transition; > please help us by doing your part and getting these reviews done in a > timely manner is one way we can show gratitude to the releases team and > others who have worked to make this transition possible. > > Thanks, > Jay Faulkner > OpenStack TC Chair >

1 0

Need Help to setup Bumblebee VDI project
by Artemio Mendoza 01 Mar '24

01 Mar '24

Hello, I'm trying to set up the Bumblebee (https://github.com/NeCTAR-RC/bumblebee) project on my local computer to test. So I installed docker and tried setup by following the readme. But I'm really new in OpenStack (only tried to run OpenStack through devstack) so I would appreciate it if I could have a very detailed guide. So please share any idea, online video link, or guide document. anything is good to me. Looking forward to hearing from you. Thanks, Artemio Mendoza

3 4

[manila] Feature Freeze Exceptions
by Carlos Silva 01 Mar '24

01 Mar '24

Hello, Zorillas! During this week's IRC meeting we talked about the features we are working on and that need a feature freeze exception, and three contributors shared changes that need some more time to get to completion: 1. Human Readable Export locations: https://review.opendev.org/c/openstack/manila/+/908897 - Core + API https://review.opendev.org/c/openstack/python-manilaclient/+/908909 - CLI https://review.opendev.org/c/openstack/manila/+/908907 - NetApp driver implementation This change relates to an RFE created by operators a couple of cycles ago, and it will enhance the usability for Manila users while mounting shares. The author of this change has been responding to all comments and actively working with the reviewers to implement the suggested modifications. The author mentioned that he would need more time to fix the review comments. 2. Share backups for NetApp driver: https://review.opendev.org/c/openstack/manila/+/910595 - Changes to the backup base driver https://review.opendev.org/c/openstack/manila/+/909115 - NetApp Backup driver The generic approach for share backups was implemented in the previous cycle and NetApp is working on a driver-specific implementation for backups. The author has also been actively working with the reviewers providing updates, but more time would be needed for more review rounds. 3. Deferred deletion: https://review.opendev.org/c/openstack/manila/+/907051 This is also a feature we have been designing for a while, and it will be useful when the backend takes a lot of time to delete shares. Manila will be able to release the quotas and track the shares deletion in the background. The author worked on review comments very fast and addressed the issues pointed by the reviews, but we still need some more review rounds. I would like to grant a feature freeze exception for the three features mentioned and we should aim to merge them by the end of the next week (march 8th). Thank you, carloss

1 0

[release][ironic][swift] cycle-with-intermediary deliverables without any release
by Elõd Illés 01 Mar '24

01 Mar '24

Hi, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the 2024.1 Caracal cycle: [swift] swift [ironic] bifrost ironic-prometheus-exporter ironic-python-agent-builder ironic-ui networking-baremetal networking-generic-switch Those should be released ASAP, and in all cases before March 14th, so that we have a release to include in the final 2024.1 Caracal release. Előd Illés irc: elodilles @ #openstack-release

2 1

[oslo] Removing feature branches of oslo.messaging
by Takashi Kajinami 01 Mar '24

01 Mar '24

Hello, # I already discussed this with a few people but am sending this email # mostly for records. Currently we have a few feature branches in oslo.messaging but it seems these are not actually used now. feature/amqp-dispatch-router : the feature was already merged into master feature/nats-driver : this branch contains no meaningful change feature/pika : the feature was already merged into master feature/zmq : the feature was already merged into master I'd propose deleting these useless branches. Note that currently the nats-driver branch is causing config error in zuul, which was triggered by TripleO's retirement, and my quick attempt revealed that, as I expected, CI in that branch is badly broken. Please let me know if you have any concern. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 2

[release] Release countdown for week R-4, March 04-08
by Herve Beraud 01 Mar '24

01 Mar '24

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the 2024.1/Caracal deliverables can be proposed, well ahead of the final 2024.1/Caracal release date. General Information ------------------- We are still finishing up processing a few release requests, but the 2024.1/Caracal release requirements are now frozen. If new library releases are needed to fix release-critical bugs in 2024.1/Caracal, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in 2024.1/Caracal that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By March 25, 2024 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/2024.1 branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for 2024.1/Caracal changes should be added there to make sure the consumers of your release notes see them. Upcoming Deadlines & Dates -------------------------- Cycle Highlights Due: March 7th, 2024 (R-4 week) RC1 deadline: week of March 11, 2024 (R-3 week) Final RC deadline: week of March 25, 2024 (R-1 week) Final 2024.1/Caracal release: April 3, 2024 Dalmatian PTG: April 8-12, 2024 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[TC][openapi] Request for new projects under the OpenStack hat
by gtema 01 Mar '24

01 Mar '24

Hi TC representatives, Some time ago I was communicating about my POC on generating OpenAPI schemas from the source code of services. I continued working on that and have now few projects (that I was developing on GitHub to make life easier) that I would like to bring under the OpenStack hood (and place them under the SDK team). I have also figured out that Nova is now reviewing spec on starting using supporting this (thanks Stephen) and Neutron folks expressed also interest. === codegenerator https://gtema.github.io/openstack-codegenerator/ This project is responsible for generation of the OpenAPI specs and generate other (currently user-facing) code ouf of them === openstack-openapi https://gtema.github.io/openstack-openapi/ This repo hosts rendered specs and provides analogue to the os-api-ref Sphinx extension that renders them into the html (what you see under the link is a mix of Swagger and os-api-ref style). I was not really effectively working on that rendering lately, the repo right now is more or less a storage for the specs themselves with a first sketch of sphinx extension of rendering and basic OpenAPI flavoring doc. === openstack-rs https://gtema.github.io/openstack/ This is a Rust monorepo project with few items: - SDK for OpenStack out of the rendered OpenAPI specs - experimental CLI following very different approach compared to the python- openstackclient. It is compiled into single binary (what helps those not willing to pull whole python with all deps and the insanity we experience lately or those who build docker containers with only OSC inside to bypass the mentioned hell) and purely auto-generated from the specs - [future] openstack-tui (similar to k9s for Kubernetes) Here it is all really oriented only on the user facing tooling. I am very convinced in this project and will continue working on it independent on the outcome. Any objections/ideas/comments? Should I just go and create 3 project-config changes pending the approval? ====== Since I am on this topic anyway I would also like to address another related question. While working for OpenTelekomCloud we developed HashiVault plugin for managing OpenStack credentials as secrets (I had a talk on that in Vancouver). We tried to bring this to OpenDev but were unsure under which namespace. Pretty shortly a Hashi license issue started circling around and after few back and forth iterations we were not sure what to do with that project at all. Anyway the plugin itself is Apache-2 and working. It should be possible to also use it with OpenBAO (as a fork of Vault), but it was not tested so far. I am now not with Telekom anymore, but people there are still willing to contribute it under the OpenStack. Do you have any opinions on that? Is there interest in getting this under the OpenDev and if yes then which namespace (openstack or X)? ======= Thanks, Artem

4 5

[tacker] Gate broken, and a fix patch has been posted
by Ayumu Ueha (Fujitsu) 01 Mar '24

01 Mar '24

Hi Tacker team, As you may know, the following two tacker’s gate jobs are broken since Feb 28. * tacker-functional-devstack-multinode-sol * tacker-functional-devstack-multinode-sol-multi-tenant I have investigated the cause, and posted bug report [1] and fixed patch [2]. Please refer to [1] and [2] for the problem and fix details. To: Yasufumi and Toshiaki, I have already confirmed that the above job is successful. Could you kindly review the patch [2] and merge it if it is no problem. [1] https://bugs.launchpad.net/tacker/+bug/2055431 [2] https://review.opendev.org/c/openstack/tacker/+/910720 Regards, Ayumu

1 0

Patch to ansible module os_subnet
by George Shuklin 01 Mar '24

01 Mar '24

Hello. I wrote a patch for subnet module about a moth ago. Unfortunately, no one looked at it, even after few nags in IRC. Can someone review it, please? https://review.opendev.org/c/openstack/ansible-collections-openstack/+/9073…

1 0

[all][ptls][release] Action needed to move forward Unmaintained branch policy
by Jay Faulkner 01 Mar '24

01 Mar '24

Hi all, If you are a PTL of a project, a release liason, or a person generally interested in older OpenStack branches, please make sure you take a look at the topic here: https://review.opendev.org/q/topic:%22vwx-unmaintained%22 and vote appropriately on projects you care about. More information can be found in the commit message for the patches themselves. A lot of folks have done work behind the scenes to enable this transition; please help us by doing your part and getting these reviews done in a timely manner is one way we can show gratitude to the releases team and others who have worked to make this transition possible. Thanks, Jay Faulkner OpenStack TC Chair

2 1

[blazar] Proposing Mark Powers and Matt Crees as core reviewers
by Pierre Riteau 01 Mar '24

01 Mar '24

Hello, I would like to nominate two new core reviewers for the Blazar project: - Mark Powers from University of Chicago - Matt Crees from StackHPC Mark Powers has been operating Blazar for several years for the Chameleon project (https://www.chameleoncloud.org) and maintains a fork of Blazar with many changes for this environment. The most useful changes are gradually being contributed upstream. Matt Crees has contributed several useful features to Blazar in the past few releases and helps to maintain the code. The Blazar project will benefit from their expertise and I trust their input as reviewers. Best wishes, Pierre Riteau (priteau)

1 1

[all] Gate issues and memory pressure; can you help?
by Jay Faulkner 29 Feb '24

29 Feb '24

Hi all, As some of you are aware, keeping the OpenStack CI system operating is a massive amount of work, and it's a team effort. Along those lines, we continue to have issues with CI, and memory pressure is a common thread. Recently at a TC meeting[0] we discussed how the gate is using more ram -- now in the form of swap. One additional concern is that this memory usage increase may be reflective of what our users are experiencing -- bugs that we need to fix for the sake of our users. A specific target of concern is oslo.privsep[1], but generally a need for an audit of memory usages of OpenStack services would be of significant value to the community. If you're interested in taking on this work, please reach out here, on the mailing list, or in any relevant #openstack-* channel, such as #openstack-tc. In any event, don't wait for permission! Take action and see if you can make things better, even a little bit. Thanks, Jay Faulkner OpenStack TC Chair 0: https://meetings.opendev.org/meetings/tc/2024/tc.2024-02-20-18.00.log.html 1: https://opendev.org/openstack/oslo.privsep

1 0

[cinder] FFE request for [NetApp] LUN space allocation support in 2024.1
by Borra, Jayaanand 29 Feb '24

29 Feb '24

Hello All, I would like to request FFE in the 2024.1 Caracal cycle for the below patch https://review.opendev.org/c/openstack/cinder/+/893106 Reason for FFE: Addressing review comments Thank you! Jayaanand.

3 2

Openstack Networking queries
by KK CHN 29 Feb '24

29 Feb '24

List, My kolla-ansible OpenStack installation all-in-one on Virtual Machine( Ubuntu 22.04, ) This base VM has three vNICs 1. ens192 with ip 10.170.16.128 from my organization's LAN with internet connectivity 2. ens224 is configured manually with a 10.220.0.51 IP ( from a VLAN for internal testing without internet) 3. ens160 This interface is made up without any IPs ( I don't know why this has to be up without any IP address, but kolla-ansible all-in-one installation document specifies one interface like this required ) Can I do the kolla-ansible deployment with the above 2 vNICs only ( ens192 and ens 224 ?) But ens192 I cannot have without IP addresses as it is my organizational LAN. Other clients in the office use this Segment for daily work . I don't have control on 10.170.16.0/24 but only on10.170.16.128 ip Any serious issues there by using only ens192 and ens224 alone in this case ? ( I can use ens224 ( 10.220.0.0/24 segment as floating IPs as it is in my control as a VLAN) But How can I connect the internet and external world communication to this vLAN 10.220.0.0/24 from 10.170.16.128 IP which has the internet. (to use these vLAN IPs as floating point IPs ) my tenant network can be ( all VMs can be on 10.0.0.0/24) How to provide the internet to this vLAN 10.220.0.0/24 from the available internet connected IP ens192 (10.170.16.128 with internet) I have only control on this IP but not on 10.170.16.0/24 network as it is not under my control. Can I use the following config for bootstrapping and deploying kolla-ansible all-in-one *Correct me what I am missing or what wrong I am doing in this setup ??* (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ grep ^[^#] /etc/kolla/globals.yml --- workaround_ansible_issue_8743: yes config_strategy: "COPY_ALWAYS" kolla_base_distro: "ubuntu" openstack_release: "2023.1" kolla_internal_vip_address: "10.220.0.24" kolla_external_vip_address: "{{ kolla_internal_vip_address }}" kolla_container_engine: docker network_interface: "ens224" neutron_external_interface: "ens160" neutron_plugin_agent: "openvswitch" nova_compute_virt_type: "qemu" (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$

2 1

*[glance] Request for Feature Freeze Exception*
by Abhishek Kekane 29 Feb '24

29 Feb '24

Hi Team, I would like to request FFE for "Using centralized database for cache operations" feature. Patches: https://review.opendev.org/q/topic:%22centralized-cache-db%22 Status: Base functionality is merged Pending: - Devstack patch for defaulting cache_driver to centralized_db - https://review.opendev.org/c/openstack/devstack/+/907110 - Tempest tests for caching images on remote node - https://review.opendev.org/c/openstack/tempest/+/901525 - Grenade patch to change cache-driver to centralized_db on upgrade - https://review.opendev.org/c/openstack/grenade/+/901678 - New tempest job to test centralized db - https://review.opendev.org/c/openstack/glance/+/901429 - New Grenade job to test upgrade scenario - https://review.opendev.org/c/openstack/glance/+/901649 - Make centralized_db driver default in glance - https://review.opendev.org/c/openstack/glance/+/907111 Why miss the deadline: Some useful restructuring during milestone 3 This feature is useful as we just need a single database which reduces the need of maintaining sqlite3 database and also can enhance caching operations by introducing new APIs in future. Kindly consider this feature for the current cycle and assist with reviews and suggestions. Thank you, Abhishek Kekane

3 2

[nova] dry-run migration api
by Pavlo Shchelokovskyy 29 Feb '24

29 Feb '24

Hi all, Recently I've been looking into various load optimizations tooling for OpenStack (like Watcher), and noticed a lacking feature that could make such tooling much more robust and useful. The optimization tooling usually collects some metric about compute hosts and instances that nova may be totally unaware of (e.g. power consumption of a compute node in Watts), and then tries to reshuffle the instances between hypervisors to optimize said metric in some sense. The problem is, the tool has no idea beforehand if nova will actually allow moving this given instance to this given hypervisor. I am talking about resource consumption, resource provider traits, image and aggregate metadata matching, numa placement, server group affinities etc. To know all this for sure, the optimization tool would have to duplicate most of the nova scheduler and good part of placement inside of itself - which is not feasible. This is why AFAIU in Watcher all available strategies mention that they expect "any VM to be migrateable to any hypervisor", which is far from many if not most real life deployments. What I suggest is adding a new API to nova to effectively have a 'migration dry run' - it should return the list of target hosts a given instance may be migrated to, accounting for all the knowledge nova has about the instance and the hypervisors. The list can be already sorted by nova weighers to signal the preferred choice from nova side. AFAIU such a new API would not require any drastic changes in Nova - the most of the code is already there, used during migrations, only that at the last step, instead of choosing the best compute and actually initiating the migration process, the result of filtering and weighing will be returned to the caller in some form. Would there be interest in such an API? If yes, I could start writing and proposing a spec. Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

3 2

Re: Enabling external connectivity to VMs
by Eugen Block 29 Feb '24

29 Feb '24

Please don't drop the list from your response. I'm not very familiar with kolla, but if you're able to ping the instance via floating IP it seems okayish. Maybe you need to set neutron_external_interface to ens192 instead? Someone with more kolla experience will probably correct me here, so don't rely on my response. Zitat von KK CHN <kkchn.in(a)gmail.com>: > Hi Eugen, > > I have followed the > https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro… > > But mistakenly I have configured ens160 as neurton_external_interface: > "ens160" as the docs says an interface without IP address needed so I > create a vNIC ens160 without IP and used this without knowing What I am > doing..!!!! > > The issue is tenant VMs don't get Internet. also tenant VMs cant ping > base VM(Ubuntu 22.04 IP 10.220.0.51, or 10.176.16.128 .. ) totally > confused. > > > Could you help me to understand what I am doing wrong here ? > Greetings > Krish. > > *For more info what I have done so far : * Please refer to > the following... > > In the Base VM, I created 3 vNICs. > > 1. ens192 with my Org's dhcp LAN IP 10.176.16.128 which has the internet. > 2. ens224 with 10.220.0.51 IP which is a VLAN IP of (10.220.0.0/24) which > is created for testing purposes internally by N/W guy. This doesn't have > the internet.. > > 3. ens160 up active without IP address. ( Wrongly I specified this as the > e neutron_external_interface in globals.yml) > > > > *I have deployed the openstack..Everything up and running .. * > I am able to create Routers, Network and subnets and able to create > instances(all VMs spawning with 10.0.0.0/24 IPs) > > I created the networks(external with subnet 10.220.0.0/24 with > start=10.220.0.30 to end=10.220.0.50) and internal Network(with subnet > named demo-net 10.0.0.0/24 for tenants) > > I am able to associate the VMs with 10.0.0.0/24 IPs to Floating IPs from > 10.220.0.0/24 > > and from my Base(host) VM(Ubuntu22.04 with ens224 10.220.0.51) I am able > to ping the 10.0.0.28 tenant VM IP through the associated floating IPs as > > $ ip netns ( On base (host) VM) dsplays the router > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ ip netns > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 (id: 1) > > qdhcp-c29f26ac-3594-4c40-bf20-f2d5ba7d6eea (id: 0) > > > $(kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ sudo ip netns exec > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 ping 10.0.0.28 ( the VM > tenant IP address) > PING 10.0.0.28 (10.0.0.28) 56(84) bytes of data. > 64 bytes from 10.0.0.28: icmp_seq=1 ttl=64 time=0.972 ms > > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ sudo ip netns exec > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 ping 10.220.0.44 ( the > Floating IP associated to 10.0.0.28 VM) > PING 10.220.0.44 (10.220.0.44) 56(84) bytes of data. > 64 bytes from 10.220.0.44: icmp_seq=1 ttl=64 time=0.840 ms > 64 bytes from 10.220.0.44: icmp_seq=2 ttl=64 time=0.599 ms > > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ sudo ip netns exec > qrouter-ecc6fe39-a733-4f30-bf67-ac42407227f8 ping 10.220.0.33 ( The router > IP through which connects floating ip 10.220.0.44 and then to tenant VM ip > 10.0.0.28 ) > > PING 10.220.0.33 (10.220.0.33) 56(84) bytes of data. > 64 bytes from 10.220.0.33: icmp_seq=1 ttl=64 time=0.038 ms > > *Hence it works somehow. * But ens224 10.220.0.51 doesn't have > internet on the base VM. But only ens192->10.170.16.128 IP has.. > > How can I provide the internet connectivity of ens192 to ens224 Is this > possible or Am I doing some dump here.? What is the other way / best way > to do this .. > I am beginning my journey with OpensStack but stuck here without much > progress.. > > > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ grep ^[^#] /etc/kolla/globals.yml > --- > workaround_ansible_issue_8743: yes > config_strategy: "COPY_ALWAYS" > kolla_base_distro: "ubuntu" > openstack_release: "2023.1" > kolla_internal_vip_address: "10.220.0.24" > kolla_external_vip_address: "{{ kolla_internal_vip_address }}" > kolla_container_engine: docker > network_interface: "ens224" > neutron_external_interface: "ens160" > neutron_plugin_agent: "openvswitch" > nova_compute_virt_type: "qemu" > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ > > > The following screenshot shown the tenant VM console(tty) where I am able > to ping floating IP(10.220.0.44 and its router ip 10.220.0.33 ) but > neither 10.220.0.51 the base VM ens224 IP nor ens192 10.17.16.128 > > > [image: image.png] > > > > krish > > On Tue, Feb 27, 2024 at 11:09 PM Eugen Block <eblock(a)nde.ag> wrote: > >> Hi, >> >> Check out this page: >> >> >> https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro… >> >> You need some sort of external network to provide connectivity for >> instances. >> >> Zitat von KK CHN <kkchn.in(a)gmail.com>: >> >> > List, >> > >> > I am a bit confused with the OpenStack Networking configuration for >> > Created virtual machines on a (Kolla-ansible all-in-one on an Ubuntu >> > 22.04 VM ) openstack installation. >> > >> > I am able to create virtual machines through the dashboard as well as >> CLI. >> > I have used the default network/cirros images created from init-runonce >> > script. >> > >> > But Real time, how can I configure these new VMs to communicate with Base >> > VM or external world by ping, ssh or make internet connection etc. >> > >> > Base VM is Ubuntu22.04 - with IPs ens192=>10.170.16.128(with Internet), >> > second interface => ens224 => 10.220.0.51 and ens160 up and running >> > without IP address for neutron_external_interface: >> > >> > All the VMs which I created getting IP addresses in series (10.0.0.X). >> > >> > But How to allocate Internet and make external world communication to >> and >> > from these VMs ? >> > >> > >> > Any hints/directions towards this much appreciated. >> > >> > Greetings, >> > Krish >> > >> > >> > If required more inputs here follows the additional information. >> > >> > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ grep ^[^#] >> /etc/kolla/globals.yml >> > --- >> > workaround_ansible_issue_8743: yes >> > config_strategy: "COPY_ALWAYS" >> > kolla_base_distro: "ubuntu" >> > openstack_release: "2023.1" >> > kolla_internal_vip_address: "10.220.0.24" >> > kolla_external_vip_address: "{{ kolla_internal_vip_address }}" >> > kolla_container_engine: docker >> > network_interface: "ens224" >> > neutron_external_interface: "ens160" >> > neutron_plugin_agent: "openvswitch" >> > nova_compute_virt_type: "qemu" >> > (kolla_ansible_venv3) ubuntu@ubuntu-VM:~$ >> > >> > >> > >> > Additional inputs: >> > >> > There are 3 virtual interfaces on the base Ubuntu22.04 Virtual Machine. >> > ens192->10.170.16.128 with internet, ens224->10.220.0.51 , ens160 up >> > without IP >> > >> > 1. First Interface contain IP address from My organizations DHCP lease >> from >> > LAN(10.16.16.0) Which has Internet connectivity. >> > ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP >> group >> > default qlen 1000 link/ether 00:0c:29:33:18:3c brd ff:ff:ff:ff:ff:ff >> > altname enp11s0 >> > inet 10.170.16.128/23 brd 10.170.17.255 scope global dynamic >> noprefixroute >> > ens192 >> > valid_lft 786963sec preferred_lft 786963sec >> > inet6 fe80::cd1a:bc6c:b129:f91f/64 scope link noprefixroute >> > valid_lft forever preferred_lft forever3 >> > >> > >> > 2. Interface I have 10.220.0.51 >> > >> > ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP >> group >> > default qlen 1000 >> > link/ether 00:0c:29:33:18:46 brd ff:ff:ff:ff:ff:ff >> > altname enp19s0 >> > inet 10.220.0.51/24 brd 10.220.0.255 scope global noprefixroute >> ens224 >> > valid_lft forever preferred_lft forever >> > inet 10.220.0.24/32 scope global ens224 >> > valid_lft forever preferred_lft forever >> > inet6 fe80::a8b6:f094:c47:8282/64 scope link noprefixroute >> > valid_lft forever preferred_lft forever >> > >> > 3. ens160 without any IP address which is up and running configured for >> > Kolla neutron_external_interface: "ens160" >> > >> > ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master >> > ovs-system state UP group default qlen 1000 >> > link/ether 00:0c:29:33:18:32 brd ff:ff:ff:ff:ff:ff >> > altname enp3s0 >> > >> > >> > >> > 1. What networks need to be created additionally ? >> > 2. Bridges and bonds required here or not ? >> > >> > 3. To enable these New VMs to talk to external world( ssh, ping, internet >> > connection to all these VMs ) what all the steps need to be performed or >> I >> > left out ? >> >> >> >>

1 0

[oslo][release][requirement] FFE request for oslo.context
by Takashi Kajinami 29 Feb '24

29 Feb '24

Hello, I'd like to request an exception to merge a change[1] to oslo.context and create a new stable/2024.1 release. This change is required to fix the problem which is current blocking us from bumping oslo.messaging to the final 2024.2 release version (14.7.0)[2]. The change is small and has quite limited impact. I've tested the modification locally and confirmed it fixes the heat unit tests. [1] https://review.opendev.org/c/openstack/oslo.context/+/910153 [2] https://review.opendev.org/c/openstack/requirements/+/909906 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 4

[magnum] Dropping default Cluster API driver
by Mohammed Naser 29 Feb '24

29 Feb '24

Hi everyone, It seems that based on a recent post that I saw on the Twitter-sphere[1], it seems that the Magnum team has decided to move forward with setting a default driver for the Cluster API. I don't agree with this. Unfortunately, we don't have much recordings of our PTG conversations, and since the notes on the PTG are pretty light[2], I don't see any details of that. I don't see why we should be merging a native Cluster API driver and not allowing the operators and deployment tools decide which one they want to support. Personally, I think that the Helm driver should be built in a separate repository and then installed by the user as a Python package once they understand what are the backends and their options, as opposed to shipping one out of the box with far less features. We already have successful users which are using our implementation in production that have also posted blogs and shared their experience, we'd be doing them a disservice by now announcing a 'native' built-in driver. Can the decision be changed so that there is no built-in driver, and you must decide to install one yourself? Also, I would be really happy to hear feedback from users of the driver for their comments here. Thanks, Mohmamed [1]: https://www.stackhpc.com/magnum-clusterapi.html [2]: https://etherpad.opendev.org/p/r.5b94a5a9dbf4e3bf8202b5e57cb93770

19 34

[ptl][election][trove] PTL candidacy for 2024.2
by chunyang wu 28 Feb '24

28 Feb '24

Hello everyone: I would like to announce my candidacy for PTL of the Trove project for the 2024.2 cycle. For the Dalmatian cycle, i'd like to focus on the following: * review the coming patches * Add more tempest tests * Add CI tests for the latest datastore(mysql, mariadb, postgresql) version * improve docs thanks wu.chunyang

2 2