January 2021 - openstack-discuss - lists.openstack.org

[all] CI test result table in the new gerrit review UI
by Balázs Gibizer 26 Jan '21

26 Jan '21

Hi, I understand that adapting the old CI test result table to the new gerrit review UI is not a simple task. As a temporary measure I hacked together a tampermonkey user script[1] that does a limited version of the CI table injection from the browser side. I tested it with recent chrome and firefox. Let me know if you have problems with it and I'll try to help. Also feel free to adapt it to your own needs. Cheers, gibi [1] https://gist.github.com/gibizer/717e0cb5b0da0d60d5ecf1e18c0c171a

15 34

[tact-sig][dev][infra][qa] OpenStack TaCT SIG 2021 Request for Help
by Jeremy Stanley 26 Jan '21

26 Jan '21

The tl;dr on this is that we need more volunteers to review CI job configuration and project creation requests for OpenStack, and if your proposed config changes are waiting longer to get reviewed than you like, consider that a not so gentle reminder that you bear some of the responsibility. Please read on and reach out if you'd like to help. Our community infrastructure, these days known as the OpenDev Collaboratory, is first and foremost a group effort for projects and their contributors to join forces in collectively maintaining the services and automation on which they rely. This has always been a bit of a "Tragedy of the Commons" situation, where it's all too easy for users of the commons to feel like it's someone else's job to maintain things. Unfortunately, when everyone feels this way, everyone also gets to suffer through the result. What we need is not just for people to avoid throwing trash on the ground when they visit the park, but for them to bring a trash bag (or bin liner, depending on your continent) along and collect a bit of rubbish they see along the way, even if it isn't theirs. The people who take some time out of their day to pick up after others in OpenStack are colloquially referred to as the Testing and Collaboration Tools Special Interest Group (TaCT SIG). Folks come and go over time, and lately we've had more going than coming, so could really use some new volunteers. Consider this a request that people who have (or are willing to invest in gaining) an understanding of things like our job configuration and project creation process make themselves known and pitch in on reviews. We're happy to fast-track approval rights for anyone who shows they can reliably evaluate these changes. Now down to the nitty-gritty details... if you're inclined to help, first and foremost let me or other TaCT SIG reviewers know so we can make sure to prioritize your input. Then take a look at open reviews in particular for the openstack/project-config and openstack/openstack-zuul-jobs repositories. Beyond that, checking through changes for opendev/base-jobs and zuul/zuul-jobs would also be great as they tend to get intertwined with OpenStack's job changes anyway. Not skipping changes which are failing CI results is really helpful too, since change authors often don't understand what the failure result is trying to tell them to fix. Further, answering job-related questions in IRC or on mailing lists helps spread out that load for the rest of us as well. The quickest way to get started is to join the #openstack-infra channel on the Freenode IRC network, and the #opendev and #opendev-meeting channels too if you like. You may want to set up a highlight in your IRC client for the string "config-core" which is what we've standardized on to try and bring things to the attention of the configuration core reviewers. When there are changes you've looked over and you think are probably ready to merge, let us know (#openstack-infra for OpenStack-related changes, non-OpenStack-specific things in #opendev). Mention config-core when you do so, to get our attention. If you have questions, I'm happy to answer them. You can reply on-list or in private to this message, or ask in #openstack-infra on IRC (I'm "fungi" in there if you need me). -- Jeremy Stanley, your humble OpenStack TaCT SIG chair

1 0

Trove Image Create Error
by Ammad Syed 26 Jan '21

26 Jan '21

Hi, I am creating a trove image with default parameters. ./trovestack build-image ubuntu bionic true ubuntu I am having below error . Please advise. 2021-01-26 13:19:24.905 | Installing collected packages: wheel, setuptools, pip 2021-01-26 13:19:25.292 | Attempting uninstall: pip 2021-01-26 13:19:25.293 | Found existing installation: pip 9.0.1 2021-01-26 13:19:25.294 | Uninstalling pip-9.0.1: 2021-01-26 13:19:25.309 | Successfully uninstalled pip-9.0.1 2021-01-26 13:19:26.231 | Successfully installed pip-21.0 setuptools-52.0.0 wheel-0.36.2 2021-01-26 13:19:26.761 | + python2 /tmp/get-pip.py -U --force-reinstall 2021-01-26 13:19:27.367 | Traceback (most recent call last): 2021-01-26 13:19:27.367 | File "/tmp/get-pip.py", line 24226, in <module> 2021-01-26 13:19:27.371 | main() 2021-01-26 13:19:27.371 | File "/tmp/get-pip.py", line 199, in main 2021-01-26 13:19:27.372 | bootstrap(tmpdir=tmpdir) 2021-01-26 13:19:27.372 | File "/tmp/get-pip.py", line 82, in bootstrap 2021-01-26 13:19:27.372 | from pip._internal.cli.main import main as pip_entry_point 2021-01-26 13:19:27.372 | File "/tmp/tmpxnphbN/pip.zip/pip/_internal/cli/main.py", line 60 2021-01-26 13:19:27.372 | sys.stderr.write(f"ERROR: {exc}") 2021-01-26 13:19:27.372 | ^ 2021-01-26 13:19:27.372 | SyntaxError: invalid syntax 2021-01-26 13:19:27.396 | ++ /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:run_in_target:59 : check_break after-error run_in_target bash 2021-01-26 13:19:27.409 | ++ /usr/lib/python3/dist-packages/diskimage_builder/lib/common-functions:check_break:143 : echo '' 2021-01-26 13:19:27.410 | ++ /usr/lib/python3/dist-packages/diskimage_builder/lib/common-functions:check_break:143 : egrep -e '(,|^)after-error(,|$)' -q 2021-01-26 13:19:27.428 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:run_in_target:1 : trap_cleanup 2021-01-26 13:19:27.439 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:trap_cleanup:36 : exitval=1 2021-01-26 13:19:27.447 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:trap_cleanup:37 : cleanup 2021-01-26 13:19:27.457 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:cleanup:42 : unmount_image -- Regards, Syed Ammad Ali

2 1

[ironic] Having a regular review jam - Lets figure out a day/time?
by Julia Kreger 26 Jan '21

26 Jan '21

Greetings my fellow bringiners of irony! Yesterday, during our virtual midcycle meeting[0], we discussed having review jams in order to help facilitate working through some of the large volumes of patches. An example of a case where this will be necessary being the Secure RBAC work. As agreed yesterday, I've created a poll[1] to try and identify the best day of the week and time of day for us to have this get together to review patch chains, spread context of the changes, and discuss further. If you can, please reply to the poll in the next week and from there I'll go ahead and get something on a calendar. In all likelihood, I may actually send calendar invites for this, if that is acceptable for folks. Thanks everyone, and have a wonderful week! -Julia [0]: https://etherpad.opendev.org/p/ironic-wallaby-midcycle [1]: https://doodle.com/poll/mdv6vpw6qdfzteg2

1 0

[tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none
by Marios Andreou 26 Jan '21

26 Jan '21

Hi TripleO, you may have seen the thread started by Herve at [1] around the deadline for making a victoria release for os-refresh-config, os-collect-config and tripleo-ipsec. This message is to ask if anyone is still using these? In particular would anyone mind if we stopped making tagged releases, as discussed at [2]. Would someone mind if there was no stable/victoria branch for these repos? For the os-refresh/collect-config I suspect the answer is NO - at least, we aren't using these any more in the 'normal' tripleo deployment for a good while now, since we switched to config download by default. We haven't even created an ussuri branch for these [3] and no one has shouted about that (or at least not loud enough I haven't heard anything). For tripleo-ipsec it *looks* like we're still using it in the sense that we carry the template and pass the parameters in tripleo-heat-templates [4]. However we aren't running that in any CI job as far as I can see, and we haven't created any branches there since Rocky. So is anyone using tripleo-ipsec? Depending on the answers here and as discussed at [2] I will move to make these as unreleased (release-management: none in openstack/governance reference/projects.yaml) and remove the release file altogether. For now however and given the deadline of this week for a victoria release I am proposing that we move forward with [2] and cut the victoria branch for these. thanks for reading and please speak up if any of the above are important to you! thanks, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019730.… [2] https://review.opendev.org/c/openstack/releases/+/769915/1/deliverables/vic… [3] https://pastebin.com/raw/KJ0JxKPx [4] https://opendev.org/openstack/tripleo-heat-templates/src/commit/9fd709019fd…

5 8

[cinder] this week's meeting in video+IRC
by Brian Rosmaita 26 Jan '21

26 Jan '21

Quick reminder that this week's Cinder team meeting on Wednesday 27 January, being the final meeting of the month, will be held in both videoconference and IRC at the regularly scheduled time of 1400 UTC. Here's a quick reminder of the video meeting rules we've agreed to: * Everyone will keep IRC open during the meeting. * We'll take notes in IRC to leave a record similar to what we have for our regular IRC meetings. * Some people are more comfortable communicating in written English. So at any point, any attendee may request that the discussion of the current topic be conducted entirely in IRC. connection info: https://bluejeans.com/3228528973 cheers, brian

1 0

[tc] weekly update
by Mohammed Naser 26 Jan '21

26 Jan '21

Hi everyone, Here's an update on what happened in the OpenStack TC this week. You can get more information by checking for changes in the openstack/governance repository. # Patches ## Open Reviews - [manila] add assert:supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/770859 - Define Xena release testing runtime https://review.opendev.org/c/openstack/governance/+/770860 - Setting Ke Chen as Watcher's PTL https://review.opendev.org/c/openstack/governance/+/770913 - Cool-down cycle goal https://review.opendev.org/c/openstack/governance/+/770616 - Drop openSUSE from commonly tested distro list https://review.opendev.org/c/openstack/governance/+/770855 - Define 2021 upstream investment opportunities https://review.opendev.org/c/openstack/governance/+/771707 - js-openstack-lib does not make releases https://review.opendev.org/c/openstack/governance/+/771789 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Move openstack-tempest-skiplist to release-management: none https://review.opendev.org/c/openstack/governance/+/771488 - monasca-log-api & monasca-ceilometer does not make releases https://review.opendev.org/c/openstack/governance/+/771785 - Remove Karbor project team https://review.opendev.org/c/openstack/governance/+/767056 - WIP NO MERGE Move os-*-config to Heat project governance https://review.opendev.org/c/openstack/governance/+/770285 ## Abandoned Reviews - Add QA in 2021 upstream investment opportunities https://review.opendev.org/c/openstack/governance/+/771708 - Add RBAC work in 2021 upstream investment opportunities https://review.opendev.org/c/openstack/governance/+/771709 # Other Reminders - Our next [TC] Weekly meeting is scheduled for January 28th at 1500 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, January 27th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[kolla] Keycloak "More than one user" error
by Braden, Albert 26 Jan '21

26 Jan '21

We're running Train on Centos 7, and using Keycloak for auth. After I setup Keycloak, create a user in Keycloak, and then login to Horizon via Keycloak, a user is created in Keystone: | ccb276f4f507fd9f271d629d2ad896d2c97e04f81336cd8c1332f4b2df115ca2 | test | If I try to address that user by name, I get an error: (openstack) [root@chrnc-area51-build-01 our-ok-kolla-ansible]# os user show test More than one user exists with the name 'test'. I can address it by id. When I list users, I only see one "test" user." (openstack) [root@chrnc-area51-build-01 our-ok-kolla-ansible]# os user show ccb276f4f507fd9f271d629d2ad896d2c97e04f81336cd8c1332f4b2df115ca2 +---------------------+------------------------------------------------------------------+ | Field | Value | +---------------------+------------------------------------------------------------------+ | domain_id | 4678301ef9a24d54bcd2e87a8fbc6872 | | email | test(a)example.com | If I create a second user in Keycloak and login the same way, this doesn't happen: (openstack) [root@chrnc-area51-build-01 our-ok-kolla-ansible]# os user show test2 +---------------------+------------------------------------------------------------------+ | Field | Value | +---------------------+------------------------------------------------------------------+ | domain_id | 4678301ef9a24d54bcd2e87a8fbc6872 | | email | test2(a)example.com | These 2 users look identical in the database: user: | ccb276f4f507fd9f271d629d2ad896d2c97e04f81336cd8c1332f4b2df115ca2 | {"email": "test(a)example.com"} | 1 | NULL | 2021-01-22 18:33:20 | NULL | 4678301ef9a24d54bcd2e87a8fbc6872 | | f4287b6082b8f36048d052eaa3d35facb94e5eff598d59d2aee68252ddb13339 | {"email": "test2(a)example.com"} | 1 | NULL | 2021-01-22 21:01:54 | NULL | 4678301ef9a24d54bcd2e87a8fbc6872 | federated_user: | 6 | ccb276f4f507fd9f271d629d2ad896d2c97e04f81336cd8c1332f4b2df115ca2 | keycloak | openid | test | test | | 9 | f4287b6082b8f36048d052eaa3d35facb94e5eff598d59d2aee68252ddb13339 | keycloak | openid | test2 | test2 | Where should I be looking for the cause of this error? I apologize for the nonsense below. So far I have not been able to stop it from being attached to my external emails. I'm working on it. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

2 2

Re: [nova][dev] Revisiting qemu emulation where guest arch != host arch
by Apsey, Christopher 26 Jan '21

26 Jan '21

Resurrecting this old thread… The first bits of work for this are starting to be submitted for review: https://review.opendev.org/c/openstack/nova/+/772156 The developer is going to go through the rest of the tcg guest supported architectures in QEMU and add them in (he only has aarch64 done right now) which will require a bit of time/testing, but we hope to have it ready to go for potential inclusion in wallaby. Any comments from nova team on approach/implementation are welcome. Chris Apsey GEORGIA CYBER CENTER From: Sean Mooney <smooney(a)redhat.com> Sent: Wednesday, July 15, 2020 10:37 AM To: Apsey, Christopher <CAPSEY(a)augusta.edu>; openstack-discuss(a)lists.openstack.org Cc: Belmiro Moreira <moreira.belmiro.email.lists(a)gmail.com> Subject: [EXTERNAL] Re: [nova][dev] Revisiting qemu emulation where guest arch != host arch CAUTION: EXTERNAL SENDER This email originated from an external source. Please exercise caution before opening attachments, clicking links, replying, or providing information to the sender. If you believe it to be fraudulent, contact the AU Cybersecurity Hotline at 72-CYBER (2-9237 / 706-722-9237) or 72CYBER(a)augusta.edu<mailto:72CYBER@augusta.edu> On Wed, 2020-07-15 at 14:17 +0000, Apsey, Christopher wrote: > All, > > A few years ago I asked a question[1] about why nova, when given a hw_architecture property from glance for an image, > would not end up using the correct qemu-system-xx binary when starting the guest process on a compute node if that > compute nodes architecture did not match the proposed guest architecture. As an example, if we had all x86 hosts, but > wanted to run an emulated ppc guest, we should be able to do that given that at least one compute node had qemu- > system-ppc already installed and libvirt was successfully reporting that as a supported architecture to nova. It > seemed like a heavy lift at the time, so it was put on the back burner. > > I am now in a position to fund a contract developer to make this happen, so the question is: would this be a useful > blueprint that would potentially be accepted? this came up during the ptg and the over all felling was it should really work already and if it does not its a bug. so yes i fa blueprint was filed to support emulation based on the image hw_architecture property i dont think you will get objection altough we proably will want to allso have schduler support for this and report it to placemnt or have a whigher of some kind to make it a compelte solution. i.e. enhance the virt driver to report all the achitecure it support via traits and add a weigher to prefer native execution over emulation. so placement can tell use where it can run and the weigher can say where it will run best. see line 467 https://etherpad.opendev.org/p/nova-victoria-ptg<https://protect-us.mimecast.com/s/2eFkClYVvJcywrxruqA7hQ> > Most of the time when people want to run an emulated guest they would just nest it inside of an already running > guest of the native architecture, but that severely limits observability and the task of managing any more than a > handful of instances in this manner quickly becomes a tangled nightmare of networking, etc. I see real benefit in > allowing this scenario to run natively so all of the tooling that exists for fleet management 'just works'. This > would also be a significant differentiator for OpenStack as a whole. > > Thoughts? > > [1] > http://lists.openstack.org/pipermail/openstack-operators/2018-August/015653…<https://protect-us.mimecast.com/s/_HyfCmZV2KiZoxzxiQsIGH> > > Chris Apsey > Director | Georgia Cyber Range > GEORGIA CYBER CENTER > > 100 Grace Hopper Lane | Augusta, Georgia | 30901 > https://www.gacybercenter.org<https://protect-us.mimecast.com/s/n5XeCn5VYLTzZEvEFEjrF-> >

1 0

[neutron] bug deputy report for week of 2021-01-18
by Bence Romsics 25 Jan '21

25 Jan '21

Hi Neutron Team, Last week's new bugs: High: * https://bugs.launchpad.net/neutron/+bug/1912359 [OVN] Add support for WSGI mod Lack of feature parity in OVN * https://bugs.launchpad.net/neutron/+bug/1912369 [FT] "test_gateway_chassis_rebalance" failing because lrp is not bound Rare gate failure, assigned to Rodolfo. * https://bugs.launchpad.net/neutron/+bug/1912450 flows on br-int wasn't been deleted completely Fix in progress: https://review.opendev.org/c/openstack/neutron/+/771903 * https://bugs.launchpad.net/neutron/+bug/1912779 [ovn-octavia-provider]: batch update fails when members to remove is empty Fix in progress: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/771971 Medium: * https://bugs.launchpad.net/neutron/+bug/1912320 TestTimer breaks VPNaaS functional tests Fix merged: https://review.opendev.org/c/openstack/neutron/+/771436 * https://bugs.launchpad.net/neutron/+bug/1912596 neutron-server report 500 error when update floating ip port forwarding Fix in progress: https://review.opendev.org/c/openstack/neutron/+/771776 * https://bugs.launchpad.net/neutron/+bug/1912651 ovs flows are not readded when ovsdb-server/ovs-vswitchd are restarted. Unassigned Low: * https://bugs.launchpad.net/neutron/+bug/1912948 Missing option for OSP16.2 OVN migration RFE: * https://bugs.launchpad.net/neutron/+bug/1912460 [RFE] [QoS] add qos rule type packet per second (pps) * https://bugs.launchpad.net/neutron/+bug/1912672 [RFE] Enable set quota per floating-ips pool. Incomplete: * https://bugs.launchpad.net/neutron/+bug/1912379 Neutron causes systemd to hang on Linux guests with SELinux disabled * https://bugs.launchpad.net/neutron/+bug/1912513 Port creation fails with error IP already allocated but the IP is available Cheers, Bence

1 0