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

[osc-placement] placement_api_version in clouds.yaml not recognized
by jayaditya gupta 28 Jan '21

28 Jan '21

Hello it seems during plugin creation placement_api_version is not recognized by the osc-placement plugin. I have looked at other plugins too but can't seem to understand where the clouds.yaml file is loaded or referenced to get the desired value. Story : https://storyboard.openstack.org/#!/story/2008553 Would be helpful if i can get some pointers Thanks

1 0

[tc] weekly meeting
by Mohammed Naser 27 Jan '21

27 Jan '21

Hi everyone, Here’s the agenda for our weekly TC meeting. It will happen tomorrow (Thursday the 28th) at 1500 UTC in #openstack-tc and I will be your chair. If you can’t attend, please put your name in the “Apologies for Absence” section. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting # ACTIVE INITIATIVES * Follow up on past action items * Audit SIG list and chairs (diablo_rojo) - https://etherpad.opendev.org/p/2021-SIG-Updates - http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019994.… * Gate performance and heavy job configs (dansmith) - http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ * Dropping lower-constraints testing from all projects (gmann) - http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.… * Open Reviews - https://review.opendev.org/q/project:openstack/governance+is:open Thank you, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[cinder] s3 backup driver status
by Brian Rosmaita 27 Jan '21

27 Jan '21

(I think there are time zone issues preventing the team working on the driver from attending the cinder weekly meeting, so I'm sending this update to the mailing list.) We discussed the proposed s3 backup driver [0] at today's cinder meeting. The code is looking good and the developers have been responsive to comments and doing quick revisions. The patch has one +2 and looks very close to being approved. One thing that's missing at this point is a comment on the review from one of the developers that they've deployed it with cinder and it works, and under what conditions it's been tested (that is, actually with S3, or only with the swift proxy). So please add such a comment to the review. This will allow us to merge the backup driver while you continue to work on getting the CI running [1]. We haven't required CI on backup drivers previously, so the cinder team has taken the position that lack of CI is not a reason to hold up the backup driver from merging. I want to stress, however, that we are excited that you are working on getting CI for the driver. The CI is looking close to completion as well (the holdup at the moment seems to be a problem with the swift proxy and recent versions of the boto library). The devstack support for this effort [2] is also looking good. [0] https://review.opendev.org/c/openstack/cinder/+/746561 [1] https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/772085 [2] https://review.opendev.org/c/openstack/devstack/+/770171

1 0

[infra][release] delete old EOL'd stable branches
by Előd Illés 27 Jan '21

27 Jan '21

Hi Infra Team! In October there was a discussion at Release Team meeting [1] about what can we do with the old, already EOL'd but not yet deleted branches (this is possible since with the Extended Maintenance process the general/"mass" EOL'ing was stopped and tagging a project branch EOL does not delete the branch anymore). Related to this, I would like to ask two things: 1. I've used the list_eol_stale_branches.sh [2] script to get the list of such not-yet-deleted branches for Ocata [3]. They are all tagged with 'ocata-eol', but stable/ocata branch still exists for them. Could you please delete these? [3] 2. On the Release Team meeting [1] we were hinted that with the newer version of gerrit (that was installed at the end of November) some automation is possible through gerrit API in the future. Can I get some help about where should I start with the automation? Which repository should I look, where can the deletion being triggered ("similarly like branch creation")? Thanks in advance, Előd [1] http://eavesdrop.openstack.org/meetings/releaseteam/2020/releaseteam.2020-1… [2] https://opendev.org/openstack/releases/src/commit/eb381492da3f7c826c35b9f14… [3] http://paste.openstack.org/show/801992/

4 9

[largescale-sig] Next meeting: January 27, 15utc
by Thierry Carrez 27 Jan '21

27 Jan '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-meeting-3 on IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210127T15 Our main topic will be to review progress and blockers on improving the documentation of various stages of our Scaling journey[1]. [1] https://wiki.openstack.org/wiki/Large_Scale_SIG Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Talk to you all later, -- Thierry Carrez

1 1

Secure RBAC work
by Lance Bragstad 27 Jan '21

27 Jan '21

Hey everyone, I wanted to take an opportunity to clarify some work we have been doing upstream, specifically modifying the default policies across projects. These changes are the next phase of an initiative that’s been underway since Queens to fix some long-standing security concerns in OpenStack [0]. For context, we have been gradually improving policy enforcement for years. We started by improving policy formats, registering default policies into code [1], providing better documentation for policy writers, implementing necessary identity concepts in keystone [2], developing support for those concepts in libraries [3][4][5][6][7][8], and consuming all of those changes to provide secure default policies in a way operators can consume and roll out to their users [9][10]. All of this work is in line with some high-level documentation we started writing about three years ago [11][12][13]. There are a handful of services that have implemented the goals that define secure RBAC by default, but a community-wide goal is still out-of-reach. To help with that, the community formed a pop-up team with a focused objective and disbanding criteria [14]. The work we currently have in progress [15] is an attempt to start applying what we have learned from existing implementations to other projects. The hope is that we can complete the work for even more projects in Wallaby. Most deployers looking for this functionality won't be able to use it effectively until all services in their deployment support it. I hope this helps clarify or explain the patches being proposed. As always, I'm happy to elaborate on specific concerns if folks have them. Thanks, Lance [0] https://bugs.launchpad.net/keystone/+bug/968696/ [1] https://governance.openstack.org/tc/goals/selected/queens/policy-in-code.ht… [2] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/… [3] https://review.opendev.org/c/openstack/keystoneauth/+/529665 [4] https://review.opendev.org/c/openstack/python-keystoneclient/+/524415 [5] https://review.opendev.org/c/openstack/oslo.context/+/530509 [6] https://review.opendev.org/c/openstack/keystonemiddleware/+/564072 [7] https://review.opendev.org/c/openstack/oslo.policy/+/578995 [8] https://review.opendev.org/q/topic:%22system-scope%22+(status:open%20OR%20s… [9] https://review.opendev.org/q/status:merged+topic:bp/policy-defaults-refresh… [10] https://review.opendev.org/q/topic:%22implement-default-roles%22+(status:op… [11] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing… [12] https://docs.openstack.org/keystone/latest/admin/service-api-protection.html [13] https://docs.openstack.org/keystone/latest/contributor/services.html#author… [14] https://governance.openstack.org/tc/reference/popup-teams.html#secure-defau… [15] https://review.opendev.org/q/topic:%2522secure-rbac%2522+status:open

6 10

RE: [EXTERNAL] Re: [kolla][keystone] Another keycloak issue
by Braden, Albert 27 Jan '21

27 Jan '21

Another problem I'm encountering with keycloak is that the keycloak users can't login on the command line. I created user test2 via Keycloak and test3 via CLI. They have identical roles on the admin domain: (openstack) [root@chrnc-area51-build-01 ~]# os role assignment list --user test2 +----------------------------------+------------------------------------------------------------------+-------+----------------------------------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +----------------------------------+------------------------------------------------------------------+-------+----------------------------------+--------+--------+-----------+ | 406a5f1cd92d45b5b3d54979235e896c | f4287b6082b8f36048d052eaa3d35facb94e5eff598d59d2aee68252ddb13339 | | 15c32af517334e28a9427809a9fc4805 | | | False | +----------------------------------+------------------------------------------------------------------+-------+----------------------------------+--------+--------+-----------+ (openstack) [root@chrnc-area51-build-01 ~]# os role assignment list --user test3 +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ | 406a5f1cd92d45b5b3d54979235e896c | 06a5f28d061f4d42b3bf64df378338fd | | 15c32af517334e28a9427809a9fc4805 | | | False | +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ I made identical env-setting "rc" files with only the username changed. Test3 logs in successfully but test2 fails: (openstack) [root@chrnc-area51-build-01 ~]# . ./test2-openrc.sh (openstack) [root@chrnc-area51-build-01 ~]# openstack server list The request you have made requires authentication. (HTTP 401) (Request-ID: req-ad7ee855-df98-434a-9afc-89f64a7addd1) (openstack) [root@chrnc-area51-build-01 ~]# . ./test3-openrc.sh (openstack) [root@chrnc-area51-build-01 ~]# openstack server list (openstack) [root@chrnc-area51-build-01 ~]# The only obvious difference is the longer UID for the Keycloak users. Do Keycloak-created users require something different in the env? Do I need to change something in Keycloak, to make the Keycloak users work the same as CLI-created users? Where can I look in the database to find the differences between these two users? RC files: (openstack) [root@chrnc-area51-build-01 ~]# cat test2-openrc.sh # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=test2 export OS_TENANT_NAME=test2 export OS_USERNAME=test2 export OS_PASSWORD=<password> export OS_AUTH_URL=http://192.168.0.10:35357/v3 export OS_INTERFACE=internal export OS_ENDPOINT_TYPE=internalURL export OS_IDENTITY_API_VERSION=3 export OS_REGION_NAME=chrnc-area51-01 export OS_AUTH_PLUGIN=password export OS_CACERT=/etc/kolla/certificates/openstack.area51.dev.chtrse.com.pem (openstack) [root@chrnc-area51-build-01 ~]# cat test3-openrc.sh # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=test export OS_TENANT_NAME=test export OS_USERNAME=test3 export OS_PASSWORD=<password> export OS_AUTH_URL=http://192.168.0.10:35357/v3 export OS_INTERFACE=internal export OS_ENDPOINT_TYPE=internalURL export OS_IDENTITY_API_VERSION=3 export OS_REGION_NAME=chrnc-area51-01 export OS_AUTH_PLUGIN=password export OS_CACERT=/etc/kolla/certificates/openstack.area51.dev.chtrse.com.pem 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.

4 3

[tripleo] Removing tempest container from TripleO
by Chandan Kumar 27 Jan '21

27 Jan '21

Hello, In TripleO CI jobs, we used to run tempest tests using a tempest container via tripleo-quickstart-extras 's validate-tempest role. Nowadays, All the tempest execution is done via openstack-ansible-os_tempest role in TrIpleO CI job which is dependent on tempest rpms. Validate-tempest is also getting removed. Since the tempest container is no longer used and tested in CI. So we are removing it from TripleO. Here is the tripleo-common patch for Removing tempest container build: https://review.opendev.org/c/openstack/tripleo-common/+/771993 Thanks for reading. Thanks, Chandan Kumar

1 0

Trove Image Create Error
by Ammad Syed 27 Jan '21

27 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 3

nova modify quota
by Ankele zhang 27 Jan '21

27 Jan '21

Hi~ I have an Rocky OpenStack platform on CentOS7.6. I need to delete some code about 'quota' in nova, because I build my baremetal node and my quota usage changed by nova. I have traced the Nova code by pdb, but I could not found the change quota usage place in nova. If ironic has config to avoid 'quota usage waste', or some good method to delete the code? Looking forward to your reply. Ankele

1 0

[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

Re: [openstack-dev] [neutron][taas] Proposal of Dashboard for TaaS
by Madhuwantha priyashan 25 Jan '21

25 Jan '21

Dear sir, I am an undergraduate student and I am doing a project using OpenStack now. I need to install tap as a service in OpenStack but I could not find any guideline for this. It is great full if u can provide guidelines for this task. Thank you

3 3

Syntribos
by Matei Goga 24 Jan '21

24 Jan '21

Hi, Was wondering if there was a replacement for Syntribos or some equivalent project that could be used to pentest an OpenStack deployment. Much thanks! ~ Matei

1 0

pip 21 heads-up (Python 2 support gone)
by Radosław Piliszek 24 Jan '21

24 Jan '21

Hello Fellow OpenStackers, Please notice pip 21 was released just yesterday. It means Python 2 is no longer supported. Upgrading pip to latest on Python 2 may render pip unusable (as ancient pip may not consider 21 an unsupported version and install it nonetheless). Similarly, using default get-pip.py on Python 2 no longer works. There is, however, https://bootstrap.pypa.io/2.7/get-pip.py for those that want to use get-pip.py on Python 2. Kind regards, -yoctozepto

1 0

Re: [tripleo][ussuri][centos8] overcloud deploy fails with no valid host was found, GRUB2 cannot mount with regular user
by Ruslanas Gžibovskis 24 Jan '21

24 Jan '21

Should i try keep only ironic-python-agent-ramdisk ? In my overcloud-image yaml? On Sat, 23 Jan 2021, 23:28 Julia Kreger, <juliaashleykreger(a)gmail.com> wrote: > I'm not so sure about that. Note the different > "ironic-python-agent-ramdisk" versus "ironic-agent" in > > https://github.com/openstack/tripleo-common/blob/stable/ussuri/image-yaml/o… > > On Fri, Jan 22, 2021 at 3:02 PM Ruslanas Gžibovskis <ruslanas(a)lpic.lt> > wrote: > > > > Hi all, > > > > I am trying to build some cloud again and failing with [1]. I think this > is a most critical line. It fails during GRUB2 deployment on overcloud > image, I believe main error message is: mount: only root can do that. I > used the following steps to create image: > > > > cp -ar /etc/yum.repos.d repos > > # enable: repos/CentOS-HA.repo > > sed -i "s/enabled=0/enabled=1/g" repos/CentOS-Linux-HighAvailability.repo > > sed -i "s/gpgcheck=1/gpgcheck=0/g" repos/*repo > > export DIB_YUM_REPO_CONF="$(ls $(pwd)/repos/*repo)" > > export STABLE_RELEASE="ussuri" > > source /home/stack/stackrc > > mkdir /home/stack/images > > cd /home/stack/images > > openstack overcloud image build --config-file > /home/stack/overcloud-images-python3.yaml > > openstack overcloud image upload --update-existing > > # openstack overcloud node configure --all-manageable > > > > overcloud-images-python3.yaml file content can be found here [2], just > added additional packages, such as tcpdump, iperf, iptraf and so on... > > And steps from link [3] to set root pass to troubleshoot if needed. > > > > any thoughts? Maybe there were some changes recently (from 22 of > December) PRevious images from there. Thank you for your thoughts and > attention. > > > > [1] http://paste.openstack.org/show/GDYriAXxQniZTPQGJGbH/ > > [2] http://paste.openstack.org/show/2tkVFdwSZ0QMjoJKmOrm/ > > [3] > https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16… > > > > > > -- > > Ruslanas Gžibovskis > > +370 6030 7030 >

1 0

[review] oslo.messaging patterns in various projects
by Erik Olof Gunnar Andersson 23 Jan '21

23 Jan '21

I was helping troubleshoot an issue with Magnum recently and found out that there was a minor issue with how they handle RPC connections, and decided to do an audit of all OpenStack projects and found a bunch that are likely to be experiencing similar issues. The gist of the issue is that most of these projects creates a new rpc transport on every API call. If someone has some time over to help review these fixes, I would be grateful. https://review.opendev.org/c/openstack/magnum/+/770707 - Re-use transport for rpc calls https://review.opendev.org/c/openstack/magnum/+/770720 - Re-use transport for rpc server https://review.opendev.org/c/openstack/blazar/+/771110 - Re-use rpc transport https://review.opendev.org/c/openstack/solum/+/771111 - Re-use rpc transport https://review.opendev.org/c/openstack/murano/+/771341 - Use common rpc pattern for all services https://review.opendev.org/c/openstack/watcher/+/771381 - Use common rpc pattern for all services I tried to use a standardized approach with all of these, but feel free to add any feedback.

1 0