August 2021 - openstack-discuss - lists.openstack.org

[tc][all] Please Help On Collecting Pain Points
by Rico Lin 16 Aug '21

16 Aug '21

Dear all As a proposal for pre-select goals for Yoga [1]. We need to figure out the possibility. *I would like to ask each project team, SIG, and pop-up if you can kindly provide the major pain point you have (and better to be fixable by bugs/features).* *What you can help with is added in pain point information in [2].* *Information like pain point topic, description, and ideas on how to targeting them.* *Why this is important?* I think this data allows us to see clearly if we can have goals like `eliminate pain points`. *What's after this?* If we can make sure this can be a goal material, we might be able to have this as a goal and allow project teams to focus on one of their most important issues. As an alternative, we might be able to collect from user side with a user survey, but that's more like a really long-term plan for this. [1] https://etherpad.opendev.org/p/y-series-goals [2] https://etherpad.opendev.org/p/pain-point-elimination *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

3 4

[all] SQLAlchemy 2.0 and coming ORM apocalypse
by Stephen Finucane 16 Aug '21

16 Aug '21

tl;dr: If you haven't already started looking at SQLAlchemy 2.0 compatibility and/or are still using sqlalchemy-migrate, you probably have work to do. As you can guess from $subject, there's a new major version of SQLAlchemy in the pipeline. The good news: it cleans up a lot of cruft and makes a lot of things such as session management more explicit and verbose, with the idea being that this should avoid a lot of gotchas and foot-gun moments. The bad news: the changes are pretty extensive, and virtually anyone that uses SQLAlchemy, which is to say every (?) OpenStack service out there, will likely have to make changes. This change will likely have a couple of impacts for users: # Breaking changes in oslo.db The oslo devs have been steadily working through the many errors that oslo.db is currently emitting when SQLAlchemy 2.0 deprecation warnings are turned on. The patches (which is not yet complete) to address these can be found here [1]. As a result of these changes, a number of oslo.db APIs are likely to start performing slightly differently, and many more may be deprecated and eventually removed. An example of the kind of change you can expect to see can be found in this glance patch [2]. We will work to minimize these changes but some will be unavoidable once sqlalchemy 2.0 actually arrives. # Breaking changes in your own project If oslo.db seeing breaking changes because of SQLAlchemy 2.0, you can be sure that you're going to see some too. Fortunately, there are ways you can get ahead of this. Turning SADeprecationWarning warnings into errors for your own module, as we've done for oslo.db [3][4] seems a sensible pattern to weed out these issues. As an aside, enabling warnings as errors seems to be a generally good idea in a unit test environment. It's usually a lot easier to address these things as they pop up that when things are finally removed and stuff explodes. To each their own though, of course. # The long prophesied death of sqlalchemy-migrate The lack of maintenance on sqlalchemy-migrate has already been well documented [5], however, SQLAlchemy 2.0 is likely to be the thing that finally puts the nail in sqlalchemy-migrate's coffin. I've been working on migrating the last few laggards still using sqlalchemy-migrate and have successfully removed all traces of it from glance (thanks, glance-core!), while the nova and cinder patches are making reasonable progress (though I do wish it was faster). The only remaining "core" project to be migrated is keystone. This proved a little too complicated for me to do in the limited time I have to work on these things, and I'm in the middle of a role change in my day job so my time to work on upstream OpenStack will be decreasing much further going forward (though not to zero, I'm hoping). Fortunately, there's quite a bit of prior art available now that people can follow when migrating stuff [6]. Related to the oslo.db changes: everything related to sqlalchemy-migrate in oslo.db should be deprecated by the next oslo.db release, and I suspect we'll be pretty aggressive in pruning these. Based on codesearch.o.o, this will have impacts for at least keystone and cinder. # A chance to evaluate all things DB One positive out of this is that the changes necessary may be broad enough to take the opportunity to re-evaluate decisions made regarding your DB layer. We've been doing this in nova, moving lots of things about to clear up the distinction between the main and API DBs and to reduce lots of tech debt that had built up in 'nova.db'. Consider using the opportunity to do the if possible. --- Hopefully this has been useful. If you have questions about any of the above, please reach out and I'll do my best to answer them. Cheers, Stephen [1] https://review.opendev.org/q/topic:%2522sqlalchemy-20%2522+(status:open+OR+… [2] https://review.opendev.org/c/openstack/glance/+/804406 [3] https://github.com/openstack/oslo.db/commit/40bce5a2baf75dc87dd591e0f71a00f… [4] https://github.com/openstack/oslo.db/commit/4c1eb966c08d29214c1905e74965f41… [5] http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020672… [6] https://review.opendev.org/q/topic:%22bp%252Fremove-sqlalchemy-migrate%22+(…

4 4

[wallaby][neutron] OVN Geneve multiple tunnels
by Ammad Syed 16 Aug '21

16 Aug '21

Hi, I am using neutron with ovn geneve. Currently I have two nic ports and I have bonded them in active passive bond in linux and assigned an IP address on vlan tagged interface for overlay network. Is it possible that I can use two or more IP addresses for overlay tunnels between compute hosts ? I am planning to assign an IP on each NIC so that I can have redundancy as well as a pair of tunnel with more throughput between compute hosts ? Ammad

2 1

[release] Release countdown for week R-7, Aug 16 - Aug 20
by Herve Beraud 16 Aug '21

16 Aug '21

Development Focus ----------------- We are entering the last weeks of the Xena development cycle. From now until the final release, we'll send a countdown email like this every week. It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. Please plan accordingly to avoid any last minute rushes to get key functionality in. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on September 19. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/xena branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… A quick reminder of the upcoming freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (August 19th). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (September 2nd) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, September 2nd. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (Sep 13 - Sep 17). * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (Sep 27 - Oct 01). As we are getting to the point of creating stable/xena branches, this would be a good point for teams to review membership in their xena-stable-maint groups. Once the stable/xena branches are cut for a repo, the ability to approve any necessary backports into those branches for xena will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Finally, now is also a good time to start planning what highlights you want for your deliverables in the cycle highlights. The deadline to submit an initial version for those is set to Feature freeze (September 2nd). Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024105.h… Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… knelson [at] openstack.org/diablo_rojo on IRC is available if you need help selecting or writing your highlights Upcoming Deadlines & Dates -------------------------- Non-client library freeze: Aug 19 (R-7 week) Client library freeze: Sep 02 (R-5 week) Xena-3 milestone: Sep 02 (R-5 week) -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud

1 0

[rocky][cinder][lvm] VM LVM leakage to packstack host OS
by Alan Davis 16 Aug '21

16 Aug '21

All, I have an issue with LVM on a rocky packstack installation where the LVM constructs inside the VMs running on the server "leak" into the host OS LVM configuration. Here's the listing of the errors from the OS: [root@stack2 log(keystone_apg-project)]# pvs WARNING: Device for PV ILdbcY-VFCm-fnH6-Y3jc-pdWZ-fnl8-PH3TPe not found or rejected by a filter. WARNING: Device for PV yZy8Xk-foKT-ovjV-0EZv-VxEM-GqiP-WH7k53 not found or rejected by a filter. Couldn't find device with uuid ILdbcY-VFCm-fnH6-Y3jc-pdWZ-fnl8-PH3TPe. Couldn't find device with uuid yZy8Xk-foKT-ovjV-0EZv-VxEM-GqiP-WH7k53. PV VG Fmt Attr PSize PFree /dev/md0 cinder-volumes lvm2 a-- <9.10t 4.87t /dev/sdaa pub_vg lvm2 a-- <250.00g 0 /dev/sdac apg-git-encrypted_vg lvm2 a-- <30.00g 0 /dev/sdah encrypted_vg lvm2 a-- <60.00g <60.00g /dev/sdb2 centos_stack2 lvm2 a-- 74.00g 0 [unknown] encrypted_vg lvm2 a-m <60.00g 0 [unknown] encrypted_vg lvm2 a-m <100.00g <100.00g Here are the current cinder.conf lines that seem relevant: # Type of LVM volumes to deploy; (default, thin, or auto). Auto defaults to # thin if thin is supported. (string value) # Possible values: # default - <No description provided> # thin - <No description provided> # auto - <No description provided> lvm_type = default # LVM conf file to use for the LVM driver in Cinder; this setting is ignored if # the specified file does not exist (You can also specify 'None' to not use a # conf file even if one exists). (string value) #lvm_conf_file = /etc/cinder/lvm.conf # Suppress leaked file descriptor warnings in LVM commands. (boolean value) #lvm_suppress_fd_warnings = false I think there are several things going on here : duplicate VG names causing LVM to see UUID/name conflicts and "leakage" of LVM data that cinder should be managing to the OS level. What do I need to change in my configuration to fix this and avoid problems in the future? Thanks -- Alan Davis Principal System Administrator Apogee Research LLC Office : 571.384.8941 x26 Cell : 410.701.0518

2 1

Need a help to recover Openstack
by open infra 15 Aug '21

15 Aug '21

Hi, Openstack was failed and noticed that mariadb-server-1 pod is failing. openstack mariadb-server-0 0/1 Running openstack mariadb-server-1 0/1 CrashLoopBackOff I managed to get logs of each pod. mariadb-server-0 log: https://paste.opendev.org/show/808070/ and https://paste.opendev.org/show/808071/ mariadb-server-1 log: https://paste.opendev.org/show/808067/ I highly appreciate if I can get a hint or steps to resolve this issue. OpenStack is deployed on STX. Regards, Danishka

3 4

Pls help newbie :) bare metal new Ansible deployment
by Nicola Ferrari (#554252) 14 Aug '21

14 Aug '21

Dears, I'm new to the list. We're just trying to introduce a demo install of openstack in our network. Our intention was to use 5 machine, already installed with ubuntu-mini 20.04. ostack1 as control node ostack2 -| ostack3 -| AS COMPUTE NODE ostack4 -| ostack5 -| ostack4 - ostack5 also as block storage node, they are connected on a direct storage (sas) where we deployed lvm with a vg named "cinder_volumes". All nodes both are on a /24 network (192.168.32.0/24) behind a router (32.254) and also on a "private" network (10.255.255.0/24) which just interconnect nodes themselves. We inteded to deploy openstack using openstack-ansible, available on github, last stable release. You can see our user_config as attachment. setup-hosts playbook runs with no errors. setup-infrastructure playbook hangs on RUNNING HANDLER [repo_server : reload nginx] **************************************************************************************** FAILED - RETRYING: reload nginx (1 retries left). fatal: [ostack1_repo_container-aabb6a12]: FAILED! => {"attempts": 5, "changed": false, "msg": "Unable to start service nginx: Job for nginx.service failed because the control process exited with error code.\nSee \"systemctl status nginx.service\" and \"journalctl -xe\" for details.\n"} Looking at log I can see that nginx coudn't start due to "Cannot assign requested address: 99" error. I suppose that must be a mistake in the deploy file? Many thanks for your suggestion, and pls, be sorry for my poor english :) Nick

2 2

[cyborg]Cyborg weekly meeting time slot
by 陈克 14 Aug '21

14 Aug '21

Thanks xinran's advice. So that we can have more time to discuss problems at night~ Thanks, Ke Chen

1 0

[all][tc] What's happening in Technical Committee: summary 13th Aug, 21: Reading: 5 min
by Ghanshyam Mann 13 Aug '21

13 Aug '21

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Project Skyline(dashboard) pre-proposal discussion. ** TC discussed the pre-proposal required things for the skyline team need to prepare before the project proposal. Kendall sent it on ML[1]. We will wait for the proposal which will have more implementation details. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - https://meetings.opendev.org/meetings/tc/2021/tc.2021-08-12-15.00.log.html * We will have next week's meeting on Aug 19th, Thursday 15:00 UTC[2]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[3] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Two open reviews for ongoing activities[4]. Combined PTL/TC Election Season for Yoga ---------------------------------------------------- * Yoga cycle election for PTL and TC will be held combined. * The nomination period officially begins August 17, 2021 23:45. * Please read Helena email for more details[5] Murano Project retirement proposal ------------------------------------------ * During a check on project health, we found that Murano is not active anymore. * No code change in Xena cycle last patch merged 4 months ago: https://review.opendev.org/c/openstack/murano/+/783446 * Core team or PTL are not reachable. * In the TC meeting, we decided to start the proposal for its retirement. If you are using it or interested in maintaining it, please respond to mnaser email on openstack-discuss ML[6] Wallaby testing runtime for centos8 vs centos8-stream ----------------------------------------------------------------- * We continue to discuss it in the TC meeting and we agreed: ** Devstack centos8-stream support can be backported to stable/wallaby with the centos8-stream job. ** We will discuss in PTG whether we should update the TC documentation on testing runtime for stable branch or what to do when centos8 is EOL (in Dec 2021). Project updates ------------------- * Retiring js-openstack-lib [7] Yoga release community-wide goal ----------------------------------------- * Please add the possible candidates in this etherpad [8]. * Current status: Proposed "Secure RBAC" to select for Yoga cycle[9]. PTG planning ---------------- * We are collecting the PTG topics in etherpad[10], feel free to add any topic you would like to discuss. Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[11], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. 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[12]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [13] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [14] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024088.h… [2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [3] https://etherpad.opendev.org/p/tc-xena-tracker [4] https://review.opendev.org/q/project:openstack/governance+status:open [5] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024093.h… [6] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024120.h… [7] https://review.opendev.org/c/openstack/governance/+/798540 [8] https://etherpad.opendev.org/p/y-series-goals [9] https://review.opendev.org/c/openstack/governance/+/803783 [10] https://etherpad.opendev.org/p/tc-yoga-ptg [11] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [12] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [13] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [14] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

Octavia
by Chris Lyons 13 Aug '21

13 Aug '21

Octavia group, I created this story to see if I could get some assistance on an Octavia issue I am having with my infra. I did a vanilla install of Openstack Wallaby using the Kolla project with Octavia enabled and auto-configure set. Everything appeared to install fine. When I try to create a load balancer using the horizon console or the cli or through further installs such as cloudfoundry that require a loadbalancer, I get an error from glance about “No image found with tag amphora” even though the image does exist. I hope it is something simple or an oversight on my part. Could I get some ideas or places to look? Story: https://storyboard.openstack.org/#!/story/2009103 Kolla install followed: https://docs.openstack.org/kolla-ansible/latest/reference/networking/octavi… cli output : [root@kolla ~]# openstack image list --tag amphora +--------------------------------------+---------------------+--------+ | ID | Name | Status | +--------------------------------------+---------------------+--------+ | 8f7398e7-7912-43b8-8131-e90f21c91ab4 | amphora | active | | 9bf14389-8521-4fb7-a7db-925f4dea1bf3 | amphora-x64-haproxy | active | +--------------------------------------+---------------------+--------+ [root@kolla ~]# My Infra scripts (relevant): https://github.com/mephmanx/openstack-scripts/blob/32363ef5753fdec381f713c7… I am admin of said infra so if anyone has time or availability (or interest) to log in and take a look I would be happy to provide creds. Thank you for any time that you could provide or offer!

4 11