- openstack-discuss - lists.openstack.org

[cinder][CI] Can't start zuul service
by xuq.fnstxz＠fujitsu.com 19 Sep '24

19 Sep '24

Hello every one, I'm building a CI system on my ubuntu 22 system. Now I've installed the zuul using 'pip install zuul' and configured it. But after running command 'zuul-scheduler', I saw a lot of errors like following in the log. It seems that there is something error in my config file that prevents access to the repo. > 2024-09-20 13:05:06,010 ERROR zuul.TenantParser: Error processing cat job > Traceback (most recent call last): > File "/home/stack/.local/lib/python3.10/site-packages/zuul/configloader.py", line 2157, in _cacheTenantYAML > self._processCatJob(abide, tenant, loading_errors, job, > File "/home/stack/.local/lib/python3.10/site-packages/zuul/configloader.py", line 2249, in _processCatJob > raise TimeoutError(f"Cat job {job} timed out; consider setting " > TimeoutError: Cat job <zuul.zk.event_queues.JobResultFuture object at 0x7fb770341510> timed out; consider setting merger.git_timeout in zuul.conf Following is my zuul.conf. > [zookeeper] > hosts=ZOOKEEPER_HOST > tls_cert=/cert/client-cert.pem > tls_key=/cert/client-key.pem > tls_ca=/cert/ca-cert.pem > > [database] > # Use variable interpolation to supply the password from the > # docker-compose file. > # https://zuul-ci.org/docs/zuul/latest/configuration.html > dburi=mysql+pymysql://DB_USER:DB_PASS@DB_HOST/ZUUL_DB > > [keystore] > password=secret > > [web] > listen_address=0.0.0.0 > port=9000 > root=http://localhost:9000 > log_config=/etc/zuul/logging.conf > > [webclient] > url=http://localhost:9000 > verify_ssl=false > > [scheduler] > tenant_config=/etc/zuul/main.yaml > log_config=/etc/zuul/logging.conf > [merger] > git_user_email=git_user(a)example.com > git_user_name=git_user > log_config=/etc/zuul/logging.conf > > [executor] > private_key_file=/home/stack/.ssh/id_rsa > default_username=executor_user > trusted_rw_paths=/srv/static/logs > > [connection gerrit] > driver=gerrit > server=review.opendev.org > user=git_user > sshkey=/ssh/id_rsa And the following is the tenant_config file. > - tenant: > name: myCI > source: > gerrit: > untrusted-projects: > - openstack/cinder Could you please tell me what I need to modify or add in the config file? Thanks and Regards, Inori.

1 0

Farewell o/
by Mark Goddard 19 Sep '24

19 Sep '24

Dear OpenStack, Tomorrow will be my final day working at StackHPC before I move to a new role outside of the OpenStack community. My journey with OpenStack began at Cray 10 years ago, trying to coerce a very fresh Ironic project into managing a rack of PCs and resulting in the SNMP power driver [1]. Since then I moved to StackHPC where I've deployed and maintained many OpenStack systems of different sizes, generally with an element of High Performance Computing (HPC). I've been lucky enough to have had the opportunity to get involved in upstream OpenStack development. Over time I grew from contributor to Kolla & Ironic core to Kolla PTL for 5 cycles. I attended several summits and PTGs, and this really helped in working out how to navigate and get more involved in the community. More recently I have been more focussed on downstream than upstream work, but still marvel at the way so many people around the world come together to volunteer their time and effort to build complex software ecosystems. I'd like to thank everyone in this community who has helped me over the years. It really is a special place. To anyone standing on the sidelines wondering how to get more involved - speak up on IRC, join the PTG, triage bugs, review some code. It doesn't need to take up too much of your time. If you're like me you'll feel self-conscious at first, and unsure about the value you're providing. But keep at it, and over time you'll become an important part of the community. All the best, Mark [1] https://review.opendev.org/c/openstack/ironic/+/118404

6 5

[ironic] [neutron] [ptg] DHCP cross-project session?
by Jay Faulkner 19 Sep '24

19 Sep '24

HI all, Myself and CID from the GR-OSS team are planning on, community willing, adding a new, more reliable DHCP backend to both Ironic and Neutron. Right now, that looks like kea, but we are less concerned about the specific project as much as we are about it not being dnsmasq ( https://bugs.launchpad.net/ironic/+bug/2026757 ). Given neither of us are incredibly familiar with the Neutron codebase, we wanted to get buy in and some general implementation advice. As a note; if desired this can happen outside PTG, but this DHCP conversation is a PTG topic for Ironic so I thought this would be a good place to do it. -- Jay Faulkner

5 7

upper-constraints (< $latest) considered harmful
by Stephen Finucane 19 Sep '24

19 Sep '24

o/ I'll jump straight into it. For those of you not in the loop we're currently going through a situation where it looks like OSC will be held back due to a bug that the Nova gates are highlighted. The actual details aren't hugely important, but what is important is the fact that this bug was first included in the OSC 7.0.0 release, which was released on August 6th. For those of you who are better at mental calendar maths than I am (or already looked at your calendar), you'll know this was over 6 weeks ago, well before the various feature freeze deadlines . and you might ask why did we only spot this last week? That would be because the upper-constraint (henceforth referred to as u-c) bump failed [1] due a different issue, meaning u-c kept us pinned at <= 6.6.1 which in turn meant every CI job *except* the ones running in the OSC gate itself kept testing the old release instead of the thing we were supposed to be released as part of Dalmatian. That only changed last week when 7.1.0 was released and the u-c bump for *that* merged [2], at which point people started shouting and hollering. Now, there is one other important consideration to factor into this, namely that, due to a flaw in our tooling, we didn't end up cutting a release branch for OSC alongside the rest of the client-library deliverables. Had we done so, we'd have seen 7.1.0 much earlier than we actually did [3]. That 7.1.0 release fixed the initial issue that prevented us releasing 7.0.0. However, this doesn't change the fact that 7.0.0 came out 6 weeks ago and not once did we get to test it outside of OSC's gate, and what's worse, we (the SDK team) were totally oblivious to the fact). Had it been known, we'd have cut a new release as soon as the fix [4] for that issue had merged (August 12th, which for the record is over 5 weeks ago). This is not the first time this has happened to us with one of our own dependencies. We had a very similar issue in Bobcat (2023.2) where we cut an oslo.db 13.0.0 release very early in that cycle, followed by a number of subsequent releases, only to have none of them end up making their way into u-c due to issues with some services. We then got to the end of the cycle, realized this, and had to do a frenzied mega revert to get us back to a pre-13.x state and allow us to release an oslo.db deliverable for Bobcat. It also happened with Castellan, whose 4.2.0 release sat waiting to merge for 4 months [4] before undergoing a similar mass revert. Adding more fuel to this fire, it's not just a problem with our own dependencies either. In fact, the problem is probably worse there. Need I remind people that it took 5 releases or 2 years, 8 months and change to uncap SQLAlchemy 2.x (a contributing factor in the oslo.db issue, fwiw). We had to struggle to get Sphinx uncapped in Bobcat [5] and fight to not revert that cap. You currently can't build docs for many projects on Fedora hosts since we're capping, among many other things, the Pillow library. The list goes on. Which brings me to my main points, of which there are three. Firstly: * There needs to be a clear time limit for how long a u-c bump can remain unmerged and a plan for what happens if affected projects have not resolved their issues within that time. There will always be exceptions - no one could rightly have asked services to switch to SQLAlchemy 2.x in a fortnight, and libraries can have legit bugs that justify a block - but those exceptions should be well-understood and, as with the bumps themselves, time-limited. A project that needs 4 releases to adapt to a crucial new library version is not a healthy project. secondly: * Caps or u-c bump reverts should similarly be clearly time-limited. We should not be defaulting to e.g re-capping Sphinx because your docs build has started to fail and then leaving that cap in place for months. Cap, fix the issue, and remove the cap asap. and, finally: * A failing u-c bump for an openstack deliverable should be treated with the highest priority 🚨🚨🚨 and should be something that the corresponding team should be made aware of immediately so they can start coordinating a resolution. We should not have u-c patches languishing for weeks, let alone months, only for there to be a last minute panic like this. I have ideas on the above (which basically warrant to more stick/[7]) but, perhaps fortunately, this isn't something I can decide on my own. Nor, should I add, is it something I expect the understaffed and oversubscribed release team to be able to do themselves. Instead, I think it's something that the TC and community as a whole need to settle on. So as soon as we get Dalmatian out the door, let's do that. Cheers, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/925763 [2] https://review.opendev.org/c/openstack/requirements/+/928948 [3] https://review.opendev.org/c/openstack/releases/+/928838 [4] https://review.opendev.org/c/openstack/requirements/+/883141 [5] https://review.opendev.org/c/openstack/requirements/+/891694 [6] https://review.opendev.org/c/openstack/requirements/+/927102 [7] https://y.yarn.co/dbdc0d5b-04e6-4c39-9cd3-44c3be3729ab.mp4

7 6

[debian] Dalmatian release validated from the Debian point of view
by Thomas Goirand 19 Sep '24

19 Sep '24

Hi, This is probably a breaking record from my side: I've finished packaging even with all project not being tagged for RC1 ! :) Indeed, I have just finished running tempest on a new Dalmatian release today. Result is: no new tempest failure, so hopefully, no regression. Feel free to start consuming the Debian package of OpenStack for Dalmatian the usual way (for example with extrepo on Bookworm): extrepo enable openstack_dalmatian apt-get update I'll be uploading Dalmatian to Unstable in the next following days. This OpenStack release will be the one in Debian 13, aka Trixie. This will run under Python 3.13, so I'm getting ready to fix Python 3.13 bugs as soon as I can, both upstream and in Debian. Cheers, Thomas Goirand (zigo)

2 1

[networking-mlnx] Project Health
by William Szumski 19 Sep '24

19 Sep '24

Hi all, I've noticed that there hasn't been any stable releases of networking-mlnx since stable/zed and was just wondering if this project still has any active maintainers. I would be interested in helping to keep this project going, so please give me a shout if you require any assistance. Thanks for all your hard work, Will

3 2

OpenStack Cinder - Volume-ID in cinder DB
by Harsh Ailani 19 Sep '24

19 Sep '24

Hello contributors, I am working on clone operation for a volumegroup and in that the volume ID auto-generated by OpenStack is not the one with which the clone volumes are being created on my IBM storage backend. This is as per design that IBM Storage backend will take the source-volume ID in the source-volumegroup and add a suffix to it while cloning. Now since there is a mismatch in the IDs between cinder and storage backend, because of which I am unable to perform any volume operations on this cloned volume. So, I was wondering if I can change the volume ID in cinder DB? I know that it’s a unique key and there is a limit of 36 characters for this field in cinder DB, but since I cannot change the volume in storage backend, I wanted to check if there is a way I can alter the volume ID in cinder DB? Kindly share your thoughts/suggestions on this matter. Thanks and Regards, Harsh Ailani

1 0

[Glance] Cancelling Weekly Meeting (Sept 19)
by Pranali Deore 18 Sep '24

18 Sep '24

Hi All, Cancelling today's glance meeting since there is nothing much on agenda & I will also not be around as I've Dr. appointment around the same time. Thanks & Regards, Pranali Deore

1 0

[all][elections][tc][ptl] 2025.1 Epoxy: Technical Committee & PTL Election Conclusion & Results
by Ian Y. Choi 18 Sep '24

18 Sep '24

Thank you to the electorate, to all those who supported and to all candidates who put their name forward for Technical Committee (TC) & Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability. Thank you to all those who make this process possible. 1. Please join me in congratulating the 4 newly elected members of the Technical Committee (TC). Ghanshyam Mann (gmann) Jens Harbott (frickler) Sylvain Bauza (bauzas) Doug Goldstein (cardoe) Full results: https://civs1.civs.us/cgi-bin/results.pl?id=E_079cc0f0dda5010c 2. For the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant: Dale Smith (dalees) * Barbican: Grzegorz Grasza (xek) * Blazar: Pierre Riteau (priteau) * Cinder: Jon Bernard () * Cloudkitty: Rafael Weingartner () * Cyborg: alex song (songwenping) * Designate: Michael Johnson (johnsom) * Glance: Pranali Deore (pdeore) * Heat: Takashi Kajinami (tkajinam) * Horizon: Tatiana Ovchinnikova (tmazur) * Ironic: Riccardo Pittau (rpittau) * Keystone: Dave Wilde (d34dh0r53) * Kolla: Michal Nasiadka (mnasiadka) * Magnum: Jake Yip (jakeyip) * Manila: Carlos Silva (carloss) * Masakari: sam sue () * Monasca: Hasan Acar () * Neutron: Brian Haley (haleyb) * Nova: Sylvain Bauza (bauzas) * Octavia: Gregory Thiemonge (gthiemonge) * OpenStack Charms: James Page (jamespage) * OpenStack Helm: Vladimir Kozhukalov (kozhukalov) * OpenStackAnsible: Dmitriy Rabotyagov (noonedeadpunk) * OpenStackSDK: Artem Goncharov (gtema) * Puppet OpenStack: Takashi Kajinami (tkajinam) * Quality Assurance: Martin Kopec (kopecmartin) * Rally: Andrey Kurilin (andreykurilin) * Skyline: Wenxiang Wu (wu_wenxiang) * Storlets: Takashi Kajinami (tkajinam) * Sunbeam: Guillaume Boutry (gboutry) * Tacker: Yasufumi Ogawa (yasufum) * Telemetry: Erno Kuvaja (jokke_) * Trove: wu chunyang (wuchunyang) * Venus: Eric Zhang () * Vitrage: Dmitriy Rabotyagov (noonedeadpunk) * Zaqar: Hao Wang (wanghao) * Zun: Hongbin Lu () PTL Election: no election required. For remaining projects (without PTL candidates), TC will work on the appointment. Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. Thank you, /Ian, an election official

2 1

[cinder] No meeting today (9/18)
by Jon Bernard 18 Sep '24

18 Sep '24

Hello all, there will be no meeting today (I have a conflict). If there is something that needs attention feel free to raise it in IRC or reach out directly. Thanks, -- Jon

1 0