- openstack-discuss - lists.openstack.org

[neutron] Secure RBAC api performance regression
by Slawek Kaplonski 29 Jan '21

29 Jan '21

Hi, In Neutron we are merging more and more patches related to the secure rbac policies [1]. Recently we noticed that our neutron-rally-task job is failing very often [2]. I did some tests and here is what were my results: * on latest neutron, with about 12 patches related to secure rbac merged - list of 4k ports took about 1m 40s: $ time neutron port-list | wc -l neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. 4044 real 1m41,644s user 0m0,926s sys 0m0,087s * same test with all those patches reverted - and it took 8 seconds: $ sudo systemctl restart devstack@q-svc; sleep 5; time neutron port-list | wc -l neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. 4044 real 0m8,131s user 0m0,907s sys 0m0,120s After a bit of digging I found out that most of the slowdown came from calls of the method self._handle_deprecated_rule(default) in [3]. When I commented that one line I had results same like without secure-rbac patches: $ sudo systemctl restart devstack@q-svc; sleep 5; time neutron port-list | wc -l neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. 4044 real 0m7,875s user 0m0,931s sys 0m0,087s @Lance, can You maybe take a look at it and help me understand if we are doing something wrong with those new rules in Neutron? Or maybe there is a bug in oslo_policy? [1] https://review.opendev.org/q/topic:secure-rbac+project:openstack/neutron [2] https://bugs.launchpad.net/neutron/+bug/1913718 [3] https://github.com/openstack/oslo.policy/blob/e103baa002e54303b08630c436dfc… -- Slawek Kaplonski Principal Software Engineer Red Hat

2 1

[tc][all] Encouraging projects to apply for tag 'assert:supports-api-interoperability'
by Ghanshyam Mann 29 Jan '21

29 Jan '21

Hello Everyone, TC defined a tag for API interoperability (cover both stable and compatible APIs) called 'assert:supports-api-interoperability' which assert on API won’t break any users when they upgrade a cloud or start using their code on a new OpenStack cloud. Basically, Projects will not change (or remove) an API in a way that will break existing users of an API. We have updated the tag documentation to clarify its definition and requirements. If your projects follow the API interoperability guidelines[1] and some API versioning mechanism that does not need to be microversion then you should start thinking to apply for this tag. The complete requirement can be found here[2]. Currently, only nova has this tag but I am sure many projects are eligible for this, and TC encourage them to apply for this. [1] https://specs.openstack.org/openstack/api-wg/guidelines/api_interoperabilit… [2] https://governance.openstack.org/tc/reference/tags/assert_supports-api-inte… -gmann

2 3

[Release-job-failures] os-collect-config 11.0.2 and tripleo-ipsec 9.3.1
by Thierry Carrez 29 Jan '21

29 Jan '21

We had two release jobs failures around TripleO and stable/ussuri: > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/cb4de2810bd147e2bf1cd98d6a1160fa : SUCCESS in 46s > - release-openstack-python https://zuul.opendev.org/t/openstack/build/fb61c0814f114a2ea0c7298378e10e5f : FAILURE in 3m 07s > - announce-release https://zuul.opendev.org/t/openstack/build/None : SKIPPED > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/None : SKIPPED and > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/fad34ae84b9d4a8c982ca4f75c01f0c9 : SUCCESS in 58s > - release-openstack-python https://zuul.opendev.org/t/openstack/build/0edc8da3c58842ed85b826f56153cde3 : FAILURE in 3m 25s > - announce-release https://zuul.opendev.org/t/openstack/build/None : SKIPPED > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/None : SKIPPED In both cases those jobs are coming from post-processing of release tags being pushed as a result of merging https://review.opendev.org/c/openstack/releases/+/772047 The error is that os-collect-config 11.0.0 and tripleo-ipsec 9.3.0 both did not have a stable/ussuri branch cut around ussuri release time at https://review.opendev.org/c/openstack/releases/+/728537 (probably escaped our watch as they are cycle-trailing). os-collect-config 11.0.1 was released on master about 3 months ago, which worked because 12.0.0 (victoria) was not cut yet. But now that victoria is cut, 11.0.2 (and tripleo-ipsec 9.3.1) triggered an error. ----11.0.0------11.0.1-------12.0.0/11.0.2/13.0.0-------master \ -----stable/victoria ----9.3.0------10.0.0/11.0.0/9.3.1-----master \ ----- stable/victoria Given that os-collect-config 12.0.0/11.0.2/13.0.0 are the same commit and tripleo-ipsec 10.0.0/11.0.0/9.3.1 are the same commit, this might be solved by just cutting stable/ussuri on that same commit and reenqueuing the tag references in Zuul to trigger the jobs. I proposed https://review.opendev.org/c/openstack/releases/+/772995 to that effect. -- Thierry Carrez (ttx)

2 1

[rdo][ussuri][tripleo] use rsyslog by default for all OSP components and send them to undercloud
by Ruslanas Gžibovskis 29 Jan '21

29 Jan '21

Hi all, I would like to configure, during deployment, all OSP services save logs over rsyslog, not directly writing to files. I know OSP services support such. In most cases, services/modules write into files directly. Is there any TripleO option to set it all to logging over system logger? Also is there possibility, to send logs to centralised server, into undercloud, if to be precise? From there I want to send it to elastic, using rsyslog or send it to other log parser/analyser/storage. Have anyone met such articles/howtos/docs I could refer to tweak my config? -- Ruslanas Gžibovskis +370 6030 7030

2 2

Ussuri Trove trovestack problem
by Diaz, Santiago Miguel 28 Jan '21

28 Jan '21

Hi. Im new in Openstack. When I try to create Trove guest image with the next command ./trovestack build-image mariadb ubuntu xenial true ubuntu exit 1 obtain. Reading the logs I found: 2021-01-28 13:30:13.217 | [error] The following package is needed by the script, but not installed: 2021-01-28 13:30:13.218 | apt-transport-https 2021-01-28 13:30:13.218 | Please install and rerun the script. I resolved it changing then next file: /trove/integration/scripts/files/elements/ubuntu-guest/pre-install.d/04-baseline-tools - apt-get --allow-unauthenticated install -y language-pack-en python-software-properties software-properties-common + apt-get --allow-unauthenticated install -y language-pack-en python-software-properties software-properties-common apt-transport-https I hope it helps AVISO LEGAL: El presente correo electrónico y la información contenida en el mismo, es información privada y confidencial, está dirigida únicamente a su destinatario y no puede ser revelada a terceros, ni utilizada inapropiadamente en interés del destinatario. Excepto que se haya establecido expresamente de otra forma, éste correo electrónico y la mencionada información privada y confidencial no constituye una oferta, ni una promesa, ni una propuesta y no será interpretado como aceptación, ni como una tratativa pre-contractual, acuerdo parcial, contrato preliminar y/o pre-contrato, ni como un compromiso vinculante y/o declaración de voluntad oficial de TELECOM ARGENTINA S.A. Si Usted no es el destinatario original de éste mensaje y por ese medio pudo acceder a dicha información, por favor, elimine el mensaje. La distribución o copia de este mensaje esta estrictamente prohibida. La transmisión de e-mails no garantiza que el correo electrónico sea seguro o libre de error. Por consiguiente, no manifestamos que esta información sea completa o precisa. Toda información está sujeta a alterarse sin previo aviso. This email and the information contained herein are proprietary and confidential, and intended for the recipient only and cannot be disclosed to third parties or used inappropriately in the interest of the recipient. Except it has been expressly stated otherwise, the email and said private and confidential information are not an offer or promise, or a proposal and will not be construed as acceptance or as a pre-contractual negotiation, partial agreement, preliminary contract and / or pre-contract or binding commitment and/or an official statement of intent of TELECOM ARGENTINA S.A. If you are not the intended recipient of this message and thereby gained access to such information, please remove the message. Distribution or copying of this message is strictly prohibited. Transmission of e-mails does not guarantee that e-mail is safe or free from error. Therefore, we do not represent that this information is complete or accurate. All information is subject to change without notice.

2 1

[kolla][mariadb] failed to start a cluster
by Tony Liu 28 Jan '21

28 Jan '21

Hi, When running kolla-ansible to deploy 3 controller nodes (Ussuri), mariadb on node-1 started fine, but when start mariadb on node-2 and node-3 to join node-1, node-1 became nodor/desync and node-2 and node-3 complained "Member 2.0 (os-control-2) requested state transfer from '*any*', but it is impossible to select State Transfer donor: Resource temporarily unavailable". Ansible failed at "RUNNING HANDLER [mariadb : Wait for MariaDB service port liveness]" when timeout. What could be wrong here? Thanks! Tony

1 0

[tripleo] next irc meeting Tuesday Feb 02 @ 1400 UTC in #tripleo
by Marios Andreou 28 Jan '21

28 Jan '21

Reminder that the next TripleO irc meeting is: ** Tuesday 02 February at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to hilight at https://etherpad.opendev.org/p/tripleo-meeting-items This can include recently completed things, ongoing review requests, blocking issues, or anything else tripleo you'd like to share. Our last meeting was on Jan 19 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-01-19-14.… Hope you can make it on Tuesday, thanks, marios

1 0

2020 Open Infrastructure Foundation Annual Report
by Kendall Nelson 28 Jan '21

28 Jan '21

Hello Everyone :) Despite being a very different year than most, the Open Infrastructure community, which has over 110,000 community members, made it a productive and successful year. One of the biggest milestones that happened in the global community last year was that OpenStack, one of the top three most active open source projects with 15 million cores in production, marked its 10th anniversary in 2020. The Open Infrastructure Foundation would like to extend a huge thanks to the global community for all of the work that went into 2020 and is continuing in 2021 to help people build and operate open infrastructure. Check out the OpenStack community’s achievements in 2020 from the OpenInfra Foundation Annual Report[1] and join us <https://openinfra.dev/join/> to build the next decade of open infrastructure! -Kendall Nelson (diablo_rojo) [1] https://www.openstack.org/annual-reports/2020-openstack-foundation-annual-r…

1 0

Integration tests failing on ppc64le master branch
by aditi Dukle 28 Jan '21

28 Jan '21

2 1

[all] Proposed Xena cycle schedule
by Herve Beraud 28 Jan '21

28 Jan '21

Hey everyone, The Wallaby cycle is going by fast, and it's already time to start planning some of the early things for the Xena release. One of the first steps for that is actually deciding on the release schedule. Typically we have done this based on when the next Summit event was planned to take place. Due to several reasons, we don't have a date yet for the second 2021 event. The current thinking is it will likely take place in October (nothing is set, just an educated guess, so please don't use that for any other planning). So for the sake of figuring out the release schedule, we are proposing two schedules, one targeting a release date in mid of september, one targeting a release date in early October. Hopefully this will then align well with event plans. I have two proposed release schedule up for review here: - https://review.opendev.org/c/openstack/releases/+/772367 (23w) - https://review.opendev.org/c/openstack/releases/+/772357 (25w) Please feel free to comment on the patch if you see any major issues that we may have not considered. Thanks! -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 1

[neutron] Drivers meeting agenda - 29.01.2021
by Slawek Kaplonski 28 Jan '21

28 Jan '21

Hi, Agenda for tomorrow's drivers meeting is available at [1]. We have 2 things to discuss: * 1 RFE - [RFE] [QoS] add qos rule type packet per second (pps) [2] * 1 On demand topic - Do we want to apply for tag 'assert:supports-api-interoperability' - see [3] for details. See You tomorrow on the meeting. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda [2] https://bugs.launchpad.net/neutron/+bug/1912460 [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019505… -- Slawek Kaplonski Principal Software Engineer Red Hat

2 2

Re: [Release-job-failures] Release of openstack/monasca-tempest-plugin for ref refs/tags/2.2.0 failed
by Herve Beraud 28 Jan '21

28 Jan '21

Hello monasca team, FYI a release failure happened on monasca-tempest-plugin within the job publish-monasca-tempest-plugin-docker-image. This build was triggered by https://review.opendev.org/c/openstack/releases/+/768551 (the Wallaby part). A new incompatibility in requirements was found by pip's new resolver: > pykafka 2.8.0 has requirement kazoo==2.5.0, but you'll have kazoo 2.8.0 which is incompatible. (c.f https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa… ) I didn't find a trace of these requirements on your repo so I think they are pulled/resolved from/for underlying libraries. After that the job fails to push the "latest" docker tag because the tag is not found, I think it's a side effect of the previous error. (c.f https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa… ) Let us know if we can help you, The Release Team. Le lun. 18 janv. 2021 à 23:31, <zuul(a)openstack.org> a écrit : > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/8dd9a4fce3bc4ae2a32134b7d7fec5b5 > : SUCCESS in 52s > - release-openstack-python > https://zuul.opendev.org/t/openstack/build/ff7c8136563444df9c565f07f618c559 > : SUCCESS in 3m 44s > - announce-release > https://zuul.opendev.org/t/openstack/build/78731c6e0948490d82e1e2d14eb67857 > : SUCCESS in 3m 42s > - propose-update-constraints > https://zuul.opendev.org/t/openstack/build/3eab7a3209a84a33b8d7b69e41e185cb > : SUCCESS in 2m 49s > - publish-monasca-tempest-plugin-docker-image > https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa > : POST_FAILURE in 8m 19s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

4 5

[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 25 Jan '21

25 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

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

23 Jan '21

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

2 5

[SIG] [all] [TC] [Automation] [Cloud Research] [k8s] [Containers] [Multi Arch] [Packaging] [PowerVMStacker] [Public Cloud] [Resource Management] Updates Required?
by Kendall Nelson 22 Jan '21

22 Jan '21

Hello Everyone! I don't know if any of you have looked at the sigs governance[0] site lately, but there are a number of SIGs that seem to have out of date statuses and/or chairs listed that are no longer active in the community. >From what I can tell, the following list of SIGs could maybe use some updating. - Automation - Cloud Research - Containers - k8s - Multi Arch - Packaging - PowerVMStacker - Public Cloud - Resource Management I have created an etherpad[1] with all the SIGs for more cohesive discussion on changes. Please make comments there! I am happy to push the updates if things need to change; I just need to know what to change it to. Tangentially related, kudos Rico for chairing the most SIGs by far! -Kendall Nelson (diablo_rojo) [0] https://governance.openstack.org/sigs/ [1] https://etherpad.opendev.org/p/2021-SIG-Updates

1 0

Re: [nova] unit testing on ppc64le
by aditi Dukle 22 Jan '21

22 Jan '21

2 3

[infra][ci] no more 3rd party CI test result in gerrit
by Lu, Lianhao 21 Jan '21

21 Jan '21

Hi All, I noticed that we're no longer be able to see the 3rd party CI test results in most of the projects in openstack gerrit, such as nova, neutron. But we can still see them in the ci-sandbox project. I'm wondering how to see those test results in gerrit now? Thanks! BR, -Lianhao

1 0

[tempest] extending python-tempestconf
by Szabolcs Tóth 21 Jan '21

21 Jan '21

Hej! The official tool named python-tempestconf has a parameter named --create, which allows to create the following resources: * CirrOS image (uploads the image based on the location defined with --image parameter), * Flavors (based on default values - DEFAULT_FLAVOR_RAM, DEFAULT_FLAVOR_RAM_ALT, DEFAULT_FLAVOR_DISK - which can be changed with --flavor-min-mem and --flavor-min-disk). In order to verify our specific installation with Tempest, we need to create the basic resources as * Flavors (with extra-spec parameters like hw:mem_page_size). * Networks (one for fixed_network_name and one for floating_network_name). * python-tempestconf is able to find an already existing network created with router:external flag and set it as value for floating_network_name. * Router and port (for routing traffic between internal and external networks). I would like to ask the following: * Is there any particular reason why the basic resource create functionality is limited to the image and flavor? * Are there any plans to extend the basic resource create functionality? * Ability to set extra parameters for the flavors. * Creating networks, routers and ports (based on a user inputs, which can be separate parameters or a specific file). Would the community accept contributions extending python-tempestconf into this direction? -- BR, Szabolcs

3 2

[All] copyright
by Kanevsky, Arkady 21 Jan '21

21 Jan '21

We have in a few places openstack copyright: # Copyright (c) 2020 OpenStack Foundation Should we use OpenInfra copyright going forward? Something like # Copyright (c) 20XX Open Infrastructure Foundation Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell EMC office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

3 3

[barbican][release] Barbican deliverables questions
by Herve Beraud 21 Jan '21

21 Jan '21

Hi Barbican Team, The release team noticed some inconsistencies between the Barbican team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). First, we noticed that ansible-role-atos-hsm and ansible-role-thales-hsm are new barbican deliverables, and we would appreciate to know if we should plan to release them for Wallaby. The second thing is that barbican-ui (added in Oct 2019) was never released yet and was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so it could be the good time to update all these things. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-re… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

2 2

[neutron]Drivers meeting agenda - 22.01.2021
by Slawek Kaplonski 21 Jan '21

21 Jan '21

Hi, Agenda for tomorrow's drivers meeting is at [1]. We have one RFE ready to discuss: - https://bugs.launchpad.net/neutron/+bug/1911126 We also have 2 new things which are now triaging, so please take a look at them if You have some time and ask questions if You have any: - https://bugs.launchpad.net/neutron/+bug/1912460 - https://bugs.launchpad.net/neutron/+bug/1911864 [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[Octavia] Network issue between amphora and health manager port
by CHANU ROMAIN 21 Jan '21

21 Jan '21

Hello, I try to install Octavia and i'm facing an issue with octavia-health- manager-listen-port interface. I use Openstack Ussuri on Ubuntu 18.04 with linuxbridge plugin I followed this procedure: https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#insta… When I try to create my loadbalancer I got this error: WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='10.244.3.243', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fe1ec077080>: Failed to establish a new connection: [Errno 113] No route to host',)) From my interface "o-hm0" I cannot ping 10.244.3.243 but if I try to ping from DHCP namespace it works fine. I think the problem is my "octavia-health-manager-listen-port" port appears "DOWN" when I list every ports. I figured out than Neutron didnt update iptables rules, probably because the interface is DOWN but if I add these rules: iptables -A neutron-linuxbri-FORWARD -m physdev --physdev-out o-bhm0 -- physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT iptables -A neutron-linuxbri-FORWARD -m physdev --physdev-in o-bhm0 -- physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT Amphora is able to communication with health manager port then the loadbalancer becomes UP but now I got this WARNING: 2021-01-21 15:27:21.230 2999834 WARNING octavia.amphorae.drivers.health.heartbeat_udp [-] Health Manager experienced an exception processing a heartbeat message from ('10.244.3.243', 30684). Ignoring this packet. Exception: 'NoneType' object has no attribute 'encode' I guess it's all about the port being stuck in DOWN state. Do you have any input how to configure this port? Best regards, Romain

2 1

[monasca][release] Abandoning monasca-ceilometer and monasca-log-api?
by Herve Beraud 21 Jan '21

21 Jan '21

Dear Monasca team, The release team noticed an inconsistency between the Monasca team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, monasca-ceilometer and monasca-log-api were released in train but not released in ussuri nor victoria. Do you think that they should be deprecated (abandoned) in governance? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-re… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

3 4

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

21 Jan '21

Hi everyone, Here’s the agenda for our weekly TC meeting. It will happen tomorrow (Thursday the 21st) 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) * Add Resolution of TC stance on the OpenStackClient (diablo_rojo) - https://review.opendev.org/c/openstack/governance/+/759904 * Gate performance and heavy job configs (dansmith) - http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ * Audit and clean-up tags (gmann) - 'supports-api-interoperability' tag - Manila request: https://review.opendev.org/c/openstack/governance/+/770859 * infra-core team (mnaser / diablo_rojo) - Stepping up to help with review load that will be new to everyone * Dropping lower-constraints testing from all projects (gmann) - http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.… * Decide on OpenSUSE in testing runtime (gmann) - https://review.opendev.org/c/openstack/devstack/+/769884 * Define 2021 upstream investment opportunities - https://review.opendev.org/c/openstack/governance/+/771707 * Open Reviews - https://review.opendev.org/q/project:openstack/governance+is:open Thank you Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[OpenStackSDK][release] Abandoning js-openstack-lib?
by Herve Beraud 21 Jan '21

21 Jan '21

Dear OpenStackSDK team, The release team noticed an inconsistency between the OpenStackSDK team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, js-openstack-lib (added January 9, 2020) was never released yet and was not ready for ussuri or victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-re… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

2 2

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-16 Update
by Ghanshyam Mann 20 Jan '21

20 Jan '21

Hello Everyone, Please find the week's R-16 updates on 'Migrate RBAC Policy Format from JSON to YAML' community-wide goals. Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Progress: ======= * Projects completed: 5 * Projects left to merge the patches: 25 * Projects left to push the patches: 2 (horizon and Openstackansible) * Projects do not need any work: 17 Updates: ======= * I have pushed the patches for all the required service projects. ** Because of many services gate is already broken for lower constraints job, these patches might not be green in the test results. I request projects to fix the gate so that we can merge this goal work before m-2. ** There are many project tests where CONF object was not fully initialized before the policy is init. This was working till now as policy init did not use the CONF object but oslo_policy 3.6.0 onwards it needs fully initialized CONF object during init only. ** Aodh work for this goal is blocked because it needs oslo_policy 3.6.0 but gnocchi is capped for oslo_policy 3.4.0 [1] - https://review.opendev.org/c/openstack/aodh/+/768499 * Horizon and Openstackansible work is pending to use/deploy the YAML formatted policy file. I will start exploring this next week or so. [1] https://github.com/gnocchixyz/gnocchi/blob/e19fda590c7f7f07f1df0ba93177df07… Merry Christmas and Happy Holidays! -gmann

6 11