- openstack-discuss - lists.openstack.org

about magnum capi for production
by Nguyễn Hữu Khôi 08 Feb '24

08 Feb '24

Hello guys. Could you share with me some experience about using Magnum CAPI in production? https://github.com/vexxhost/magnum-cluster-api Thank you so much. Nguyen Huu Khoi

6 44

Cinder Bug Report 2024-02-07
by Jon Bernard 07 Feb '24

07 Feb '24

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> Undecided - Service cinder-backup failed when Swift with TLS enabled <https://bugs.launchpad.net/cinder/+bug/2051985> - Status: In Progress - hpe xp: wrong copyrights in test scripts <https://bugs.launchpad.net/cinder/+bug/2052409> - Status: In Progress - GRUB menu format error <https://bugs.launchpad.net/cinder/+bug/2052414> - Status: New Thanks, -- Jon

1 0

[cinder][vendors] Third party CI compliance check
by Rajat Dhasmana 07 Feb '24

07 Feb '24

Hello Vendors, This is related to the original discussion on the ML thread[1]. We have noticed that a lot of the drivers don't have their CI reported on a patch in 2024. Based on the last CI report that I checked[2], the number comes out to be 32 though it's not an accurate measure of the inactivity in the project. The following cases are possible: 1. The driver that doesn't have active CI reporting is already marked unsupported 2. The driver is supported but CI is not actively maintained 3. The CI information is not accurate in the wiki page If it's case 2, vendors should look into their CI and fix it else the driver will be marked unsupported in the current or upcoming release. If it's case 3, make sure to have updated CI info in the wiki page. Let's take an example of the HPE driver. The last seen status is shown as: last seen: 2016-08-09 but the driver is actively reporting on patches. The issue here is either: 1. The CI name in the volume driver is not pointing to the correct wiki page[3] 2. The wiki page does not have correct information about CI[4] Vendors should look into updating their CI related information before the midcycle-2, which is going to be held on 14th Feb, 2024 from 1400-1600 UTC[5]. Since we only have the cireport[2] as the source of truth, we will be looking at the vendor drivers that don't have a recent last seen date and start marking them unsupported during the midcycle-2. Any query is welcome on this thread or during the midcycle-2 topic discussion. [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] http://cinderstats.ivehearditbothways.com/cireport.txt [3] https://opendev.org/openstack/cinder/src/branch/master/cinder/volume/driver… [4] https://wiki.openstack.org/wiki/ThirdPartySystems/HPE_Storage_CI [5] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… Thanks Rajat Dhasmana

3 2

[all] SLURP support survey
by Mark Goddard 07 Feb '24

07 Feb '24

Hi, The Kolla project is planning to support SLURP upgrades [1] in the Caracal release cycle, allowing users to upgrade from Antelope to Caracal. There are two areas in which I'd like to request information from the various project teams. # 1. SLURP support We understand that for various reasons there can be a gap between TC resolutions and implementation across projects. Using some rudimentary grepping through various codebases I found that many projects have added the grenade-skip-level job (or a variation of it) to their CI pipelines, and a few mention SLURP in their release notes. There's little mention of it in documentation at this stage. AFAICT the following projects have SLURP upgrade jobs: Cinder, Glance, Ironic, Manila, Neutron, Nova, Octavia While I could not find a SLURP job in these: Barbican, Bifrost, Blazar, Cloudkitty, Designate, Heat, Horizon, Keystone, Magnum, Placement Question: Does your project explicitly support SLURP upgrades? Do you have or are you planning to add testing and documentation for SLURP upgrades? # 2. Rolling SLURP upgrades The TC resolution [1] states that rolling upgrades are optional for SLURP releases. This could affect the upgrade procedure required in Kolla Ansible. Nova mentions in its Antelope release notes that it supports rolling SLURP upgrades, but I could not find any information from other projects. It would be helpful if this was documented for each project. Question: Does your project support or plan to support rolling upgrades? If changes to the upgrade procedure for SLURP are required, are they documented? Thank you in advance for your responses. Apologies if I have missed any obvious source of information on this. Regards, Mark [1] https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…

7 7

[largescale-sig] Next meeting: February 7, 9utc
by Thierry Carrez 07 Feb '24

07 Feb '24

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC, our EU+Asia time. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240207T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

2 2

[Kolla][Octavia] worker unable to connect amphora instance
by Jayesh Chaudhari 07 Feb '24

07 Feb '24

Folks, I have set up kolla-ansible yoga openstack and configured Octavia using VLAN. But when I am trying to create a LB, it is stuck in pending create then eventually failed. And in logs I can see octavia-worker unable to connect to amphora instance. Is there any sanity which I can do to check if my implementation is correct ? Or am I missing something? Please advise. My configuration in global.yml enable_octavia: yes octavia_network_interface: "vlan.2140" octavia_auto_configure: yes octavia_amp_flavor: name: "amphora" is_public: yes vcpus: 2 ram: 1024 disk: 5 octavia_amp_security_groups: mgmt-sec-group: name: "lb-mgmt-sec-grp" rules: - protocol: icmp - protocol: tcp src_port: 22 dst_port: 22 octavia_amp_network: name: lb-mgmt-net provider_network_type: vlan provider_segmentation_id: 2140 provider_physical_network: physnet1 external: false shared: false subnet: name: lb-mgmt-subnet cidr: "10.145.50.128/26" allocation_pool_start: "10.145.50.135" allocation_pool_end: "10.145.50.190" gateway_ip: "10.145.50.129" enable_dhcp: yes octavia_amp_image_tag" "amphora" octavia_loadbalancer_topology: "SINGLE" Thanks, Jayesh

3 8

[tc] Next Technical Committee Meeting Tomorrow, Feb 3, 1800 UTC
by Jay Faulkner 07 Feb '24

07 Feb '24

Hi all, The next scheduled meeting of the Technical Committee is tomorrow. This meeting will be held primarily in Zoom, with minutes kept in IRC. Interested parties can join at https://us06web dot zoom dot us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09 (repair the URL first). The proposed agenda ia: Agenda - Roll call - Follow up on tracked action items - Gate health check - Implementation of Unmaintained branch statuses - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Open Discussion and Reviews

1 1

[openstack-helm] Remove Calico chart
by Vladimir Kozhukalov 07 Feb '24

07 Feb '24

Hi everyone, I would like to suggest removing the calico chart from the openstack-helm-infra repository which does not seem worth it to support any more. Tigera provides great tools for managing Calico deployments (helm chart, operator and even plain kubectl manifest). Also there are plenty of other networking solutions on the market and it looks like users can choose on their own the CNI implementation. There have not been many contributions to this chart for quite some time and we don't use this chart in any test jobs. In the deploy-env role we use the upstream Calico manifest [1]. Having said that, I think that we can remove it immediately even without any depreciation period. Opinions are welcome. [1] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/roles/… -- Best regards, Kozhukalov Vladimir

4 3

Glance image import to AWS S3 fails for files larger than 5GB
by Shrishail K 06 Feb '24

06 Feb '24

Hi Team, I have a use case where I need to replicate images from file store to S3 store. While image creation directly on S3 works fine with large files over 5G. The same fails when attempted via image-import with copy-image method. The failure is due to AWS rejecting a single object upload operation where the object size is over 5GB. What I see from logs is that direct image creation on S3 uses multipart upload when images are large. However, I fail to see the same happening when image import was used to copy an image from file to s3. Is this a known issue? Or Am I missing some configs related to image-import? Openstack version: Antelope Client version: 6.4.0 Thanks, Shrishail

3 14

[puppet] EOL plan of wallaby, xena and yoga
by Takashi Kajinami 06 Feb '24

06 Feb '24

Hello, I'm sending this as an early announcement of my current plan about these old stable branches in Puppet OpenStack project. Because we've not see any interest to backport changes to these stable branches and we have limited capacity to maintain our project, I'd propose transitioning EOL these old stable branches by the following steps. * stable/yoga is transitioned to unmaintained/yoga but we may not work on maintaining it now (which eventually means it's abandoned right after its transition to unmaintained status). We'll move it to EOL at the next cadence, when zed is transitioned to unmaintained). * wallaby and xena will become immediate candidates for EOL so we'll just move the EOL process forward. If you have any concern, then please let me know. We'll formally work on these processes in the release patches. [1] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0