March 2021 - openstack-discuss - lists.openstack.org

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-5 Update
by Ghanshyam Mann 13 Mar '21

13 Mar '21

Hello Everyone, Please find the week's R-5 updates on 'Migrate RBAC Policy Format from JSON to YAML' wallaby community-wide goals. Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml Updates: ======= * 8 more projects merged the patches last week, thanks to everyone for active review and merging these. * Sahara and Heat are failing on config object initialization, I am debugging those and will fix them soon. * Puppet Openstack left with the last patch which is on hold due to gnoochi upgrade in RDO[1]. * Panko patch is blocked due to failed gate[2], it is all good to merge (has +A) once the gate is green. Progress Summary: =============== Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml * Projects completed: 29 * Projects required to merge the patches: 5 (Openstackm Ansible , Sahara, Heat, Puppet Openstack, Telemetry ) * Projects do not need any work: 16 [1] https://review.opendev.org/c/openstack/puppet-gnocchi/+/768690 [2] https://review.opendev.org/c/openstack/panko/+/768498 -gmann

1 0

[tc][ptl][mistral] Leadership option for Mistral for Xena cycle
by Ghanshyam Mann 13 Mar '21

13 Mar '21

Hello Mistral Team, As Renat already sent an email about Mistral maintenance and help on PTL role[1], and as per TC discussion with the Mistral team, the DPL model[2] is one of the options we can try. As the Xena cycle election is completed now and Mistral is on the leaderless list[3], it is time to apply the DPL model. For this model, we need three mandatory liaisons 1. Release, 2. TACT SIG, 3. Security and these can be a single person or multiple[4]. Step to Apply: You need to propose the patch in governance with the three liaisons info; here is the example for Oslo project moving to DPL model - https://review.opendev.org/c/openstack/governance/+/757906 [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020137… [2] https://governance.openstack.org/tc/resolutions/20200803-distributed-projec… [3] https://etherpad.opendev.org/p/xena-leaderless [4] https://governance.openstack.org/tc/resolutions/20200803-distributed-projec… -gmann

1 0

[neutron] Bug deputy report for the week of Mar-8-2021
by Hongbin Lu 13 Mar '21

13 Mar '21

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. High * Functional test test_gateway_chassis_rebalance failing due to "failed to bind logical router": https://bugs.launchpad.net/neutron/+bug/1918266 * Neutron doesn't honor system-scope: https://bugs.launchpad.net/neutron/+bug/1918506 * quota: invalid JSON for reservation value when positive: https://bugs.launchpad.net/neutron/+bug/1918565 Medium * Slownesses on neutron API with many RBAC rules: https://bugs.launchpad.net/neutron/+bug/1918145 * [QoS][SR-IOV] Minimum BW dataplane enforcement fails if NIC does not support min_tx_rate: https://bugs.launchpad.net/neutron/+bug/1918464 * [OVN] BW limit QoS rules assigned to SR-IOV ports are created on NBDB: https://bugs.launchpad.net/neutron/+bug/1918702 * Toggling dhcp on and off in a subnet causes new instances to be unreachable: https://bugs.launchpad.net/neutron/+bug/1918914 Low * Driver VLAN do not create the VlanAllocation registers if "network_vlan_ranges" only specify the network: https://bugs.launchpad.net/neutron/+bug/1918274 RFE * [RFE] RFC 2317 support in Neutron with designate provider: https://bugs.launchpad.net/neutron/+bug/1918424 Won't Fix * Can't create m2 interface on the 15.3.2: https://bugs.launchpad.net/neutron/+bug/1918155 Invalid * Designate DNS – create TLD using valid Unicode string: https://bugs.launchpad.net/neutron/+bug/1918653 Incomplete * Race between sriov_config service and openib service: https://bugs.launchpad.net/neutron/+bug/1918255 * failed to name sriov vfs because the names reserved for representors: https://bugs.launchpad.net/neutron/+bug/1918397 Best regards, Hongbin

1 0

How to enable GPU in k8s environment
by open infra 13 Mar '21

13 Mar '21

Hi, What are the config files to deal with when enabling GPU (both nvidia and itel)? Regards, Danishka

1 0

[cinder] wallaby feature freeze
by Brian Rosmaita 13 Mar '21

13 Mar '21

The Wallaby feature freeze is now in effect. The following cinder patches have already been approved, but have not yet merged, and are granted a Feature Freeze Exception: - Add support to store volume format info in Cinder https://review.opendev.org/c/openstack/cinder/+/761152 - Add Consistency Groups support in PowerStore driver https://review.opendev.org/c/openstack/cinder/+/775090 The following patch had been approved, but ran into merge conflicts and had to be resubmitted, and requires re-review and approval. It also has been granted a FFE: - NetApp ONTAP: Implement FlexGroup pool https://review.opendev.org/c/openstack/cinder/+/776713 The third party CI is not reporting on the following patch, which otherwise would have been approved at this point. It has an FFE while this gets worked out: - Revert to snapshot for volumes on DS8000 https://review.opendev.org/c/openstack/cinder/+/773937 Any other feature patch (including driver features) must apply for an FFE by responding to this email before Tuesday, 16 March at 16:00 UTC. Note that application for an FFE is not a guarantee that an FFE will be granted. Grant of an FFE is not a guarantee that the code will be merged for Wallaby. It is expected that patches granted an FFE will be merged by 21:00 UTC on Friday 19 March. Bugfixes do not require an FFE. To be included in Wallaby, they must be merged before the first Release Candidate is cut on Thursday 25 March. After that point, only release-critical bugs will be allowed into the Wallaby release.

1 0

[Consultation] SFC proxy
by Jhen-Hao Yu 13 Mar '21

13 Mar '21

Dear Sir, (We made some edits from our previous mail.) We are testing a simple SFC in OpenStack (Stein) + OpenDaylight (Neon) + Open vSwitch (v2.11.1). It's an all-in-one deployment (OPNFV-9.0.0). We have read the document: https://readthedocs.org/projects/odl-sfc/downloads/pdf/latest/ and https://github.com/opnfv/sfc/blob/master/docs/release/scenarios/os-odl-sfc-… The driver we use is odl_v2: [image: image.png] [image: image.png] Our SFC topology: [image: enter image description here] <https://i.stack.imgur.com/7QMWh.png> All on the same compute node. Build SFC through API: 1. openstack sfc flow classifier create --source-ip-prefix 10.20.0.0/24 --logical-source-port p0 FC1 2. openstack sfc port pair create --description "Firewall SF instance 1" --ingress p1 --egress p1 --service-function-parameters correlation=None PP1 3. openstack sfc port pair group create --port-pair PP1 PPG1 4. openstack sfc port chain create --port-pair-group PPG1 --flow-classifier FC1 --chain-parameters correlation=nsh PC1 we expect that the encapsulation/decapsulation will be performed by the back-end driver, so that the data packet passes through the nsh-unaware VNF like a regular data packet. However, we can see that the NSH packet reaches the VNF interface (screenshot attached). [image: 123.jpg] Flow table: [image: 螢幕擷取畫面 2021-02-06 153311.png] It seems NSH header not decapsulate before entering NSH-unaware VNF. Could you give us some advice? We really appreciate it. Regards, Zack [image: Mailtrack] <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=sig…> Sender notified by Mailtrack <https://mailtrack.io?utm_source=gmail&utm_medium=signature&utm_campaign=sig…> 03/13/21, 12:07:12 PM

1 0

[requirements][all] Openstack Requirements is now frozen
by Matthew Thode 13 Mar '21

13 Mar '21

As the title states, requirements is now frozen, any updates to the master branch not already approved from now until requirements branches the stable/wallaby branch will require a FFE email to be submitted to this (openstack-discuss) mailing list. -- Matthew Thode

1 0

Status of Qinling
by Tallman, Nathan 12 Mar '21

12 Mar '21

Hello OpenStack community, I'm trying to find out if Qinling is alive or dead. The GitHub repo<https://opendev.org/openstack/qinling/src/branch/master/README.rst> says it's archived and no longer maintained, but the project page<https://www.openstack.org/software/releases/rocky/components/qinling> on openstack.org doesn't mention anything about Qinling being abandoned. Can anyone shed light on this for me? Thanks, Nathan -- Nathan Tallman Digital Preservation Librarian Penn State University Libraries (814) 865-0860 ntt7(a)psu.edu<mailto:ntt7@psu.ediu> Schedule a Meeting<https://outlook.office365.com/owa/calendar/PennStateUniversityLibraries2@Pe…> Chat with me on Teams<https://teams.microsoft.com/l/chat/0/0?users=ntt7@psu.edu> [Microsoft Teams Logo]

2 1

[tripleo] Update: migrating master from CentOS-8 to CentOS-8-Stream - starting this Sunday (March 07)
by Ronelle Landy 12 Mar '21

12 Mar '21

Hello All, Just a reminder that we will be starting to implement steps to migrate from master centos-8 -> centos-8-stream on this Sunday - March 07, 2021. The plan is outlined in: https://hackmd.io/9Xve-rYpRaKbk5NMe7kukw#Check-list-for-dday In summary, on Sunday, we plan to: - Move the master integration line for promotions to build containers and images on centos-8 stream nodes - Change the release files to bring down centos-8 stream repos for use in test jobs (test jobs will still start on centos-8 nodes - changing this nodeset will happen later) - Image build and container build check jobs will be moved to non-voting during this transition. We have already run all the test jobs in RDO with centos-8 stream content running on centos-8 nodes to prequalify this transition. We will update this list with status as we go forward with next steps. Thanks!

3 5

Re: [openstack-community] [victoria][keystone][ops]Keystone enforced policy issues
by Amy Marrich 12 Mar '21

12 Mar '21

Adding the OpenStack discuss list > On Mar 12, 2021, at 6:34 AM, Luke Camilleri <luke.camilleri(a)zylacomputing.com> wrote: > > Hi there, we have been troubleshooting keystone policies for a couple of days now (Victoria) and would like to reach out to anyone with some experience on the keystone policies. Basically we would like to follow the standard admin, member and reader roles together with the scopes function and have therefore enabled the below two option in keystone.conf > > enforce_scope = true > enforce_new_defaults = true > > once enabled we started seeing the below error related to token validation in keystone.log: > > 2021-03-11 19:50:12.009 1047463 WARNING keystone.server.flask.application [req-33cda154-1d54-447e-8563-0676dc5d8471 020bd854741e4ba69c87d4142cad97a5 c584121f9d1a4334a3853c61bb5b9d93 - default default] You are not authorized to perform the requested action: identity:validate_token.: keystone.exception.ForbiddenAction: You are not authorized to perform the requested action: identity:validate_token. > > The policy was previously setup as: > > identity:validate_token: rule:service_admin_or_token_subject > > but has now been implemented with the new scope format to: > > identity:validate_token: (role:reader and system_scope:all) or rule:service_role or rule:token_subject > > If we change the policy to the old one, we stop receiving the identity:validate_token exception. This only happens in horizon and running the same commands in the CLI (python-openstack-client) does not output any errors. To work around this behavior we place the old policy for validate_token rule in /usr/share/openstack-dashboard/openstack_dashboard/conf/keystone_policy.yaml and in the file /etc/keystone/keystone.conf > > A second way how we can solve the validate_token exception is to disable the option which has been enabled above "enforce_new_defaults = true" which will obviously allow the deprecated policy rules to become effective and hence has the same behavior as implementing the old policy as we did > > We would like to know if anyone have had this behavior and how it has been solved maybe someone can point us in the right direction to identify better what is going on. > > Last but not least, it seems that from Horizon, the admin user is being assigned a project scoped token instead of a system scoped token, while from the CLI the same admin user can successfully issue a system:all token and run commands across all resources. We would be very happy to receive any form of input related to the above issues we are facing > > Thanks in advance for any assistance > > > _______________________________________________ > Community mailing list > Community(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/community

1 0