- openstack-discuss - lists.openstack.org

[qa][ptg] Xena PTG
by Masayuki Igawa 13 Mar '21

13 Mar '21

Hi, If you are planning to attend QA sessions during the Xena PTG, please fill in the doodle[1] with time slots which are good for you before 23rd March so that we can book the best time slots for most of us. And, please add any topic which you want to discuss on the etherpad[2]. [1] https://doodle.com/poll/5ixvdcbm488kc2ic [2] https://etherpad.opendev.org/p/qa-xena-ptg Best Regards, -- Masayuki Igawa

1 0

[all][tc][legal] Possible GPL violation in several places
by Radosław Piliszek 13 Mar '21

13 Mar '21

Dear fellow OpenStackers, it has been brought to my attention that having any (Python) imports against a GPL lib (e.g Ansible) *might be* considered linking with all the repercussions of that (copyleft anyone?). Please see the original thread in Launchpad: https://bugs.launchpad.net/kolla-ansible/+bug/1918663 Not only the projects that have "Ansible" in name might be affected, e.g. Ironic also imports Ansible parts. Do note *I am not a lawyer* so I have no idea whether the Python importing is analogous to linking in terms of GPL. I am only forwarding the concerns reported to me in Launchpad. A quick Google search was inconclusive. I have done some analysis in the original Launchpad thread mentioned above. I am copying it here for ease of reference. """ Hmm, the reasoning is interesting. OpenStack Ansible and TripleO would probably also be interested in knowing whether GPL violation is happening or not. I am not in a position to answer this question. I will propagate this matter to the mailing list: http://lists.openstack.org/pipermail/openstack-discuss/ FWIW, TripleO is by Red Hat, just like Ansible, so one would assume they know what they are doing. OTOH, there is always room for a mistake. All in all, end users must use Ansible so they must agree to GPL anyhow, so the license switch would be mostly cosmetic: +/- the OpenStack licensing requirements [1]. That said, Ansible Collections for OpenStack are already licensed under GPL [2]. And a related (and very relevant) project using Ansible - Zuul - includes a note about partial GPL [3]. A quick search [4] reveals a lot of places that could be violating GPL in OpenStack (e.g. in Ironic, base CI jobs) if we followed this linking logic. [1] https://governance.openstack.org/tc/reference/licensing.html [2] https://opendev.org/openstack/ansible-collections-openstack [3] https://opendev.org/zuul/zuul [4] https://codesearch.opendev.org/?q=(from%7Cimport)%5Cs%2B%5Cbansible%5Cb&i=n… """ -yoctozepto

3 4

[Quuens][nova] lost config.drive file
by Ignazio Cassano 13 Mar '21

13 Mar '21

Hello, probably because an human error, we lost the file disk.config drive file for some instances under /var/lib/nova/instances/uuid directories. Please, is there something we can do for rebuild it for revert instances without rebuild ? Anycase, does the instance rebuilding regenerate the file? Thanks Ignazio

1 0

[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 12 Mar '21

12 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 12 Mar '21

12 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 12 Mar '21

12 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

[Nova][FFE] Smart-nic support
by yonglihe 12 Mar '21

12 Mar '21

Hi, Everyone Smart nics management involved Nova, Neutron and Cyborg. After 2 releases of discussing, coding and reviewing, we have merged Cyborg and Neutron support. Nova patches also got lots of attention and had many rounds of review, plus several +2. I hope we could merge Nova patches also in this release. The following is the Nova patches topic, individual patches links, and related resources links Now we blocked by lots of comments when reaching to the end of the feature freeze. Those comments could be addressed in 2-3 days, then we could get 3 more rounds review, very likely we could make it by RC1. Those comments include: • functional test -- released already. • minor typo, text changes, and needs more code comments • several codes flow refactor request • how to store arq-uuid ==nova patch topic link: https://review.opendev.org/q/topic:%22bp%252Fsriov-smartnic-support%22+(sta… ==nova individual patch link: 1) smartnic support - cyborg drive: two +2 https://review.opendev.org/c/openstack/nova/+/771362 2) smartnic support - new vnic type: rounds review https://review.opendev.org/c/openstack/nova/+/771363 3) smartnic support: main patch rounds review, one +2 https://review.opendev.org/c/openstack/nova/+/758944 4) smartnic support - reject server move and suspend, one +2 https://review.opendev.org/c/openstack/nova/+/779913 5) smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147 == resource: 1) blueprint sriov-smartnic-support https://blueprints.launchpad.net/nova/+spec/sriov-smartnic-support 2) Approved spec: merged https://review.opendev.org/c/openstack/nova-specs/+/742785 3) Cyborg NIC driver: merged https://review.opendev.org/c/openstack/cyborg/+/758942 4) neutron patch sets: merged neutron patch set: merged https://review.opendev.org/q/topic:%22bug%252F1906602%22+ 5) neutron-lib: merged Add new VNIC types for Cyborg provisioned ports https://review.opendev.org/c/openstack/neutron-lib/+/768324 6) neutron ml2 plugin support: merged [SR-IOV] Add support for ACCELERATOR_DIRECT VNIC type https://review.opendev.org/c/openstack/neutron/+/779292 Yongli He Regards

2 1

[Nova][FFE] libvirt vdpa support
by Sean Mooney 12 Mar '21

12 Mar '21

Hi everyone its that time again where feature are almost ready but not quite. vDPA (vHost data path acceleration) is an option kernel device offload api that allows virtio complient software devices such as a virtio net interface to be offloaded to a software or hardware acclerator such as a nic. the full detail can be found in the spec: https://specs.openstack.org/openstack/nova-specs/specs/wallaby/approved/lib… The series is up for review and gibi and stephen have been activly reviewing it over the last few day. https://review.opendev.org/q/topic:%22vhost-vdpa%22+(status:open%20OR%20sta… while the majority of the code now has +2s it wont be approved before the end of the day so i am formal asking for a feature freeze exception to allow an addtional day or to finalise the feature. the current status of the seriese id that there is one bug related to claiming pci device and marking the parent as unavaiable and claiming the parent and marking the child VF/VDPA devices as unavaiable. i have adressed this locally and will be pushing a patch to adress that later this evening once i add unit tests for thoes edgecaes. there is one patch that is pendeing to block unsupported lifecycle operation which i will be writing tomorrow. that final patch will also document them both in a release note and in the api-guide. in the evnet the full seriese is not deamed to be ready in time i have also written seperate patch to block booting vms with VDPA ports now that neutron supports it but nova does not, https://review.opendev.org/c/openstack/nova/+/780065 if we do not merge the full serise i would like to ask that we merge teh first 3 patches. openstack/nova: master: block vm boot with vdpa ports openstack/nova: master: objects: Add 'VDPA' to 'PciDeviceType' openstack/nova: master: add constants for vnic type vdpa the reason for block patch is that now that neutron support vnic-type vdpa i belive its possibel to create a port of that type and for nova to boot a vm however it will not actully use vdpa. i belvie it will take this else branch https://github.com/openstack/nova/blob/master/nova/network/os_vif_util.py#L… and result in the vm booting with a stansard ovs prot as if it was vnic-type=normal which will be confusing to debug since you were expecting to get hardware offloaed ovs but just got a standard ovs port instead without hardware offloads. operators can also block vnic-type vdpa in the neutron config. https://github.com/openstack/neutron/blob/a9fc746249cd34cb7cc594c0b4d74d8dd… but i think the nova solution is nicer since it does not require them to update there configs if this feature is not complted in Wallaby. i do belive we can complete this feature with only a small amount of addtional work and can continue to add more testing and lifecycle operations next cycle. stephen has submited https://review.opendev.org/c/openstack/nova/+/780112 to start extending the functional test framework to emulate vdpa devices so that we can harden the validation in the futrue via functional tests in addtion to the existing unit test coverage. i have not reviewed it yet so cant say how long that will take but i think that is something we can work and ensure it merged early next cycle if its not completed early next week. regards sean.

2 1

[release] Release countdown for week R-5 Mar 15 - Mar 19
by Herve Beraud 12 Mar '21

12 Mar '21

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the Wallaby deliverables can be proposed, well ahead of the final Wallaby release date (14 April, 2021). General Information ------------------- We are still finishing up processing a few release requests, but the Wallaby release requirements are now frozen. If new library releases are needed to fix release-critical bugs in Wallaby, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in Wallaby that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By 5 April, 2021 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/wallaby branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for Wallaby changes should be added there to make sure the consumers of your release notes see them. Finally, if you haven't proposed Wallaby cycle-highlights yet, you are already late to the party. Please see http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020714… for details. Upcoming Deadlines & Dates -------------------------- RC1 deadline: 22 March, 2021 (R-3 week) Final RC deadline: 5 April, 2021 (R-1 week) Final Wallaby release: 14 April, 2021 Xena PTG: 19 - 23 April, 2021 -- 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 0

[ops][glance][security] looking for metadefs users
by Abhishek Kekane 11 Mar '21

11 Mar '21

Hello operators and other people interested in metadefs, The Glance team will be giving the metadefs some love in the Xena development cycle in order to address OSSN-0088 [0]. The people who designed and implemented metadefs are long gone, and in determining how to fix OSSN-0088, we would like to understand how people are actually using them in the wild so we don't restrict them so much as to make them useless. We are looking for an operator who uses metadefs to give us a walkthrough on how you are using them at the Xena (virtual) PTG. We are planning to have this session on 23rd April around 1400 UTC. You can find more details about the same in PTG planning etherpad [1]. We are also willing to meet outside the PTG schedule in case the current scheduled time might be blocking the people. I will also reply to this as a reminder mail once our PTG schedule is final. If you do not use the metadef API for some reason related to its inability to solve a problem, lack of flexibility, or other reasons (but wish you could), we would also like to hear about that. We need to know if the feature is worth fixing and maintaining going forward. And when we say "an operator", we don't mean just one ... ideally, we'd like to have a few real-life use cases to consider. If this is affecting you (as an operator) then you can reach us either by mail or #openstack-glance IRC channel or glance weekly meeting [2] which will be held every Thursday around 1400 UTC. [0] https://wiki.openstack.org/wiki/OSSN/OSSN-0088 [1] https://etherpad.opendev.org/p/xena-ptg-glance-planning [2] https://etherpad.opendev.org/p/glance-team-meeting-agenda Thank you and Best Regards, Abhishek Kekane

6 9

[Multi-arch SIG] Xena PTG
by Rico Lin 11 Mar '21

11 Mar '21

Hi all As VPTG approaches (PTG will be held April 19th through April 23rd), I reserve a room on 4/20 Tuesday from 07:00-08:00 and 15:00-16:00 (UTC time). Exactly same as meeting schedule. We will use Meetpad this time. Let me know if you have any questions. You can find us on irc #openstack-multi-arch Please put your name in the PTG etherpad [1] if you plan to join. Also putting topic suggestions or comments on is more than welcome. Note: Don't forget to register PTG (for free) on [2]. [1] https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig [2] PTG Registration: https://april2021-ptg.eventbrite.com *Rico Lin* OIF Board director, OpenSack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack *Email: ricolin(a)ricolky.com <ricolin(a)ricolky.com>* *Phone: +886-963-612-021*

1 0

[heat] Xena PTG: same schedule as meeting time (4/21)(2 hours)
by Rico Lin 11 Mar '21

11 Mar '21

Hi all As VPTG approaches (PTG will be held April 19th through April 23rd), I reserve a room on 4/21 Wed. from 14:00-16:00 (UTC time). We will use Meetpad. this time. Let me know if you have any questions. Please put your name in the PTG etherpad [1] if you plan to join. Also putting topic suggestions or comments on is more than welcome. Note: Don't forget to register PTG (for free) on [2]. [1] https://etherpad.opendev.org/p/xena-ptg-heat [2] PTG Registration: https://april2021-ptg.eventbrite.com *Rico Lin* OIF Board director, OpenSack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack *Email: ricolin(a)ricolky.com <ricolin(a)ricolky.com>* *Phone: +886-963-612-021*

1 0

[manila] [FFE] Request for "Update cephfs drivers to use ceph-mgr" and "create share from snapshot support for CephFS"
by Victoria Martínez de la Cruz 11 Mar '21

11 Mar '21

Hi, I would like to ask for an FFE for the RFEs "Update cephfs drivers to use ceph-mgr" [0] and "Create share from snapshot support for CephFS" [1] Both RFEs are related. The first one updates the cephfs drivers to use the ceph-mgr interface for all manila operations. This change is required since the library currently used is already deprecated and it is expected to be removed in the next Ceph release. The second one leverages the previous one and adds a new functionality available through the ceph-mgr interface which is the create share from snapshot support. We have been working on both features for two cycles already and we could use a few more days to finish the testing. Looking forward to a positive response. Thanks, Victoria [0] https://blueprints.launchpad.net/manila/+spec/update-cephfs-drivers [1] https://blueprints.launchpad.net/manila/+spec/create-share-from-snapshot-ce…

2 1

[masakari] The legacy (client) has been dropped... finally!
by Radosław Piliszek 11 Mar '21

11 Mar '21

Hello Fellow OpenStackers, The Masakari team is proud to announce that the legacy Masakari client is no more! It has been deprecated since Stein and was less featureful than the OpenStack client plugin that was fully supported for a long time. The OSC plugin is also entirely based on OpenStack SDK. All Masakari client parts are available there. (This applies to Wallaby [version 7.0.0] and later.) -yoctozepto

1 0

[tacker] Xena PTG
by Yasufumi Ogawa 11 Mar '21

11 Mar '21

Hi, Next vPTG is going to be held 19-23 April. I've prepared etherpad for the PTG[1] and reserved same timeslots as previous, 6-8 am UTC from 20th Apr[2]. Please register from [3] and fill "Attendees" and "Topics" in the etherpad for your proposals. [1] https://etherpad.opendev.org/p/tacker-xena-ptg [2] https://ethercalc.net/oz7q0gds9zfi [3] https://april2021-ptg.eventbrite.com/ Thanks, Yasufumi

1 0

[TripleO] next irc meeting Tuesday Mar 16 @ 1400 UTC in #tripleo
by Marios Andreou 11 Mar '21

11 Mar '21

Reminder that the next TripleO irc meeting is: ** Tuesday 16 March 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 highlight at https://etherpad.opendev.org/p/tripleo-meeting-items This can be recently completed things, ongoing review requests, blocking issues, or anything else tripleo you want to share. Our last meeting was on Mar 02nd - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-03-02-14.… Hope you can make it on Tuesday, thanks, marios

1 0

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Thierry Carrez 11 Mar '21

11 Mar '21

We got two similar release processing failures: > - tag-releases https://zuul.opendev.org/t/openstack/build/707bb50b4bf645f8903d8ca59b43abbf : FAILURE in 2m 31s This one was an error running the tag-releases post-merge job after https://review.opendev.org/c/openstack/releases/+/779217 merged. It failed with: Running: git push --dry-run ssh://release@review.openstack.org:29418/openstack/tripleo-ipsec.git --all ssh://release@review.openstack.org:29418/openstack/tripleo-ipsec.git did not work. Description: Host key verification failed. > - tag-releases https://zuul.opendev.org/t/openstack/build/655e8980a53c4e829de25f0b8507b5f6 : FAILURE in 2m 57s Similar failure while running the tag-releases post-merge job after https://review.opendev.org/c/openstack/releases/+/779218 merged. Since this "host key verification failed" error hit tripleo-ipsec three times in a row, I suspect we have something stuck (or we always hit the same cache/worker). -- Thierry Carrez (ttx)

5 7

[release][OpenstackSDK][masakari] request FFE on OpenstackSDK for python-masakariclient
by Herve Beraud 11 Mar '21

11 Mar '21

Hello folks, As discussed this morning on #openstack-release the masakari team needs OpenstackSDK changes that haven't been released. They have been merged after the final release [1]. Those aren't landed in OpenstackSDK version 0.54.0 [2]. Here is the delta of changes merged between 0.54.0 and 736f3aa1 ( https://review.opendev.org/c/openstack/openstacksdk/+/777299) $ git log --no-merges --online 0.54.0..736f3aa16c7ee95eb5a42f28062305c83cfd05e1 736f3aa1 add masakari enabled to segment Only these changes are in the delta. Do you mind if we start releasing a new version 0.55.0 to land these changes and unlock the path of the masakari team? Client library deadline is today. Also this topic opens the door for another discussion. Indeed it's questionable that openstacksdk should follow the early library deadline, for that precise reason. We release python-*client the same time as parent projects so that late features can be taken into account. It seems appropriate that openstacksdk is in the same bucket All those safeguards are a lot less needed now that we move slower and break less things. That could be translated by moving OpenstackSDK from `type: library` [3] to `type: client-library` [4]. Let us know what you think about the FFE. Let's open the discussions about the type shifting. [1] https://review.opendev.org/c/openstack/openstacksdk/+/777299 [2] https://opendev.org/openstack/releases/commit/b87ad4371321d5b0dde7ed0b23623… [3] https://releases.openstack.org/reference/deliverable_types.html#library [4] https://releases.openstack.org/reference/deliverable_types.html#client-libr… -- 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 3

[all][elections][ptl][tc] Combined PTL/TC Nominations March 2021 End
by Kendall Nelson 11 Mar '21

11 Mar '21

Hello! The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 8 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Barbican, Cyborg, Keystone, Mistral, Monasca, Senlin, Zaqar, Zun -- TC Election Details -- There are 0 projects that will have elections. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Mar 12, 2021 23:45 UTC. Thank you, -Kendall Nelson (diablo_rojo) & the Election Officials [0] https://governance.openstack.org/election/#xena-ptl-candidates [1] https://governance.openstack.org/election/#xena-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

3 2

Windows vm is not launching from horizon
by Midhunlal Nb 11 Mar '21

11 Mar '21

Hi all, I successfully installed the openstack rocky version and everything is working properly. ---->Uploaded all images to openstack and I can see all images listed through openstack CLI. +--------------------------------------+---------------------+--------+ | ID | Name | Status | +--------------------------------------+---------------------+--------+ | 1912a80a-1139-4e00-b0d9-e98dc801e54b | CentOS-7-x86_64 active | | 595b928f-8a32-4107-b6e8-fea294d3f7f1 | CentOS-8-x86_64 active| | f531869a-e0ac-4690-8f79-4ff64d284576 | Ubuntu-18.04-x86_64 active| | 7860193b-81bd-4a22-846c-ae3a89117f9d | Ubuntu-20.04-x86_64 active | 1c3a9878-6db3-441e-9a85-73d3bc4a87a7 | cirros active | d321f3a3-08a3-47bf-8f53-6aa46a6a4b52 | windows10 active --->same images I can see through horizon dashboard,but i am not able to launch windows VM from horizon dashboard .Balance all images launching from dashboard. Getting below error; Error: Failed to perform requested operation on instance "windows", the instance has an error status: Please try again later [Error: Build of instance 15a3047d-dfca-4615-9d34-c46764b703ff aborted: Volume 5ca83635-a2fe-458c-9053-cb7a9804156b did not finish being created even after we waited 190 seconds or 61 attempts. And its status is downloading.]. --->I am able to launch windows VM from openstack CLI What is the issue ?why I am not able to launch from dashboard?please help me. Thanks & Regards Midhunlal N B +918921245637

3 2

[neutron] Drivers meeting - agenda for 12.03.2021
by Slawek Kaplonski 11 Mar '21

11 Mar '21

Hi, For tomorrow's drivers meeting we have 2 RFEs related to the integration of Neutron with Designate: * https://bugs.launchpad.net/neutron/+bug/1904559 * https://bugs.launchpad.net/neutron/+bug/1918424 I didn't marked them as triaged yet as I'm not really sure what more data we could need in both cases. I hope that we will get some more questions during the meeting so we can at least together triage them :) Of course, please check those RFEs and ask for anything You need there, even before the meeting :) -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[cinder] review priorities for the next few days
by Brian Rosmaita 11 Mar '21

11 Mar '21

Here's the list of cinder and driver features that haven't yet merged: https://etherpad.opendev.org/p/cinder-wallaby-features Please make reviewing these your top priorities. We'll get back to reviewing bug fixes next week. cheers, brian

2 1

[all][tc] Thoughts on Python 3.7 support
by Pierre Riteau 11 Mar '21

11 Mar '21

Hello, There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8. Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon: - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237 What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported? Best wishes, Pierre Riteau (priteau)

9 13

[release][oslo][monasca][keystone] Moving projects to independent
by Herve Beraud 11 Mar '21

11 Mar '21

Hello teams, We are about to move a couple of projects under the independent release models [1]. Those did not have any change merged over the cycle, we think that it is the right time to transition them to independent. Oslo: - futurist - debtcollector - osprofiler Keystone: - pycadf Monasca: - monasca-statsd Before we push the button we want to give ourselves a last chance to raise the hand if you think that it's an issue. Concerning Oslo's projects we already had a related discussion a few months ago and all participants agreed with that [2]. Please let us know ASAP if you disagree with that choice. Thanks for your attention. [1] https://review.opendev.org/q/topic:%22move-to-independent%22+(status:open%2… [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018527… -- 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 0

[election][zun] PTL candidacy for Xena
by ZTE 10 Mar '21

10 Mar '21

Hi! I'd like to propose my candidacy and continue serving as Zun PTL in the Xena cycle. Over the Wallaby release, the Zun team continues to keep the Zun stable and reliable, and also some great works have been done. My goals for the Xena cycle are to continue the progress made in the following areas: * zun-conductor: Add a service called zun-conductor * CRI: Use the CRI interface to get inventory when cri driver configed for Capsule. * Affinity&anti-affinity: Add the affinity and anti-affinity policies to zun. Thank you for taking the time to consider me for Xena PTL. Best regards, Shengqin Feng

1 0

[security][security-sig] No meeting tomorrow March 11th
by Gage Hugo 10 Mar '21

10 Mar '21

The security sig meeting tomorrow has been cancelled. We will meet again at the regular time next week. Thanks

1 0

[nova][neutron] Can we remove the 'network:attach_external_network' policy check from nova-compute?
by melanie witt 10 Mar '21

10 Mar '21

Hello all, I'm seeking input from the neutron and nova teams regarding policy enforcement for allowing attachment to external networks. Details below. Recently we've been looking at an issue that was reported quite a long time ago (2017) [1] where we have a policy check in nova-compute that controls whether to allow users to attach an external network to their instances. This has historically been a pain point for operators as (1) it goes against convention of having policy checks in nova-api only and (2) setting the policy to anything other than the default requires deploying a policy file change to all of the compute hosts in the deployment. The launchpad bug report mentions neutron refactoring work that was happening at the time, which was thought might make the 'network:attach_external_network' policy check on the nova side redundant. Years have passed since then and customers are still running into this problem, so we are thinking, can this policy check be removed on the nova-compute side now? I did a local test with devstack to verify what the behavior is if we were to remove the 'network:attach_external_network' policy check entirely [2] and found that neutron appears to properly enforce permission to attach to external networks itself. It appears that the enforcement on the neutron side makes the nova policy check redundant. When I tried to boot an instance to attach to an external network, neutron API returned the following: INFO neutron.pecan_wsgi.hooks.translation [req-58fdb103-cd20-48c9-b73b-c9074061998c req-4d68df7e-e0fd-4b1e-9b57-733731123d46 demo demo] POST failed (client error): Tenant 7c60976c662a414cb2661831ff41ee30 not allowed to create port on this network [...] INFO neutron.wsgi [req-58fdb103-cd20-48c9-b73b-c9074061998c req-4d68df7e-e0fd-4b1e-9b57-733731123d46 demo demo] 127.0.0.1 "POST /v2.0/ports HTTP/1.1" status: 403 len: 360 time: 0.1582518 Can anyone from the neutron team confirm whether it would be OK for us to remove our nova-compute policy check for external network attach permission and let neutron take care of the check? And on the nova side, I assume we would need a deprecation cycle before removing the 'network:attach_external_network' policy. If we can get confirmation from the neutron team, is anyone opposed to the idea of deprecating the 'network:attach_external_network' policy in the Wallaby cycle, to be removed in the Xena release? I would appreciate your thoughts. Cheers, -melanie [1] https://bugs.launchpad.net/nova/+bug/1675486 [2] https://bugs.launchpad.net/nova/+bug/1675486/comments/4

3 5

[release][heat][ironic][requirements][swift][OpenStackSDK] Cycle With Intermediary Unreleased Deliverables
by Armstrong Foundjem 10 Mar '21

10 Mar '21

Hello! Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Wallaby cycle: heat-agents ironic-prometheus-exporter ironic-ui ovn-octavia-provider python-openstackclient requirements swift Those should be released ASAP, and in all cases before 22 March, 2021, so that we have a release to include in the final Wallaby release. - Armstrong Foundjem (armstrong)

1 0

[glance] Xena PTG (Apr 19 - 23)
by Abhishek Kekane 10 Mar '21

10 Mar '21

Hello All, Greetings!!! Xena PTG is announced and if you haven't already registered, please do so as soon as possible [1]. I have created a Virtual PTG planning etherpad [2]. Please add your PTG topic in the etherpad [2]. If you feel your topic needs cross project cooperation please note that in the etherpad which other teams are needed. I am planning to reserve time slots for the PTG between 1400 UTC to 1700 UTC. Please let me know if you have any concerns or suggestions with the given time slots. [1] https://www.openstack.org/ptg/ [2] https://etherpad.opendev.org/p/xena-ptg-glance-planning Thank you, Abhishek

1 0

[ISSUE]Openstack create VNF instance ERROR
by Jhen-Hao Yu 10 Mar '21

10 Mar '21

Dear Sir, This our testbed: Openstack (stein) + Opendaylight (neon) + ovs (v2.11.1) We have trouble when creating vnf on compute node using OpenStack CLI: #openstack vnf create vnfd1 vnf1 Here are the log message and ovs information. COMPUTE NODE1: nova-compute.log [image: error1.png] [image: list1.png] [image: vsctl1.png] COMPUTE NODE 2: nova-compute.log [image: error2.png] [image: list2.png] [image: vsctl2.png] We don't use DPDK on our Openvswitch. Can anyone give us some advice on this issue? Thanks for helping us. [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/09/21, 10:20:09 PM

2 2

[neutron] Xena PTG
by Slawek Kaplonski 10 Mar '21

10 Mar '21

Hi, If You plan to attend Neutron sessions during the Xena PTG, please fill in doodle [1] with the time slots which are good for You. Please do that before 19.03.2021 (next Friday) so I will have time to book slots which are the best for most of us. Please also add any topics You want to be discussed to the etherpad [2] [1] https://doodle.com/poll/cc2ste3emzw7ekrh?utm_source=poll&utm_medium=link [2] https://etherpad.opendev.org/p/neutron-xena-ptg -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[scientific-sig] IRC meeting today - Jupyter notebook platforms
by Stig Telfer 10 Mar '21

10 Mar '21

Hi All - We have a Scientific SIG meeting today at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Today's agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_March_10th_2021 We'll be discussing experiences and best practices for providing JupyterHub and Jupyter notebook platforms on OpenStack. Cheers, Stig

1 0

[ISSUE]Openstack create VNF instance error
by Jhen-Hao Yu 10 Mar '21

10 Mar '21

Dear Sir, This our testbed: Openstack (stein) + Opendaylight (neon) + ovs (v2.11.1) We have trouble when creating vnf on compute node using OpenStack CLI: #openstack vnf create vnfd1 vnf1 Here are the log message and ovs information.*COMPUTE NODE1:* nova-compute.log ============================= Attempting claim on node cmp001: memory 2048 MB, disk 15 GB, vcpus 1 CPU Total memory: 7976 MB, used: 6656.00 MB memory limit not specified, defaulting to unlimited Total disk: 96 GB, used: 45.00 GB disk limit not specified, defaulting to unlimited Total vcpu: 4 VCPU, used: 3.00 VCPU vcpu limit not specified, defaulting to unlimited Claim successful on node cmp001 Creating image ERROR vif_plug_ovs.ovsdb.impl_vsctl [req-a514ba2a-7ada-4a35-944e-0c861055112e eacae20dfeb9442eb8643bb8784b03d1 caee3c14634f42438ec8479eb49ba388 - default default] Unable to execute ['ovs-vsctl', '--timeout=120', '--oneline', '--format=json', '--db=tcp:127.0.0.1:6640', '--', '--may-exist', 'add-br', 'br-int', '--', 'set', 'Bridge', 'br-int', 'datapath_type=netdev']. Exception: Unexpected error while running command. Command: ovs-vsctl --timeout=120 --oneline --format=json --db=tcp:127.0.0.1:6640 -- --may-exist add-br br-int -- set Bridge br-int datapath_type=netdev Exit code: 1 Stdout: '' Stderr: 'ovs-vsctl: tcp:127.0.0.1:6640: database connection failed (Connection refused)\n': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. ERROR vif_plug_ovs.ovsdb.impl_vsctl Unable to execute ['ovs-vsctl', '--timeout=120', '--oneline', '--format=json', '--db=tcp:127.0.0.1:6640', '--', '--may-exist', 'add-port', 'br-int', 'vhu5e8b5246-cd', '--', 'set', 'Interface', 'vhu5e8b5246-cd', 'external_ids:iface-id=5e8b5246-cd05-4735-9692-29d51db6e72d', 'external_ids:iface-status=active', 'external_ids:attached-mac=fa:16:3e:8f:b1:a1', 'external_ids:vm-uuid=30675d24-bd74-409c-ba36-4c59a72283ec', 'type=dpdkvhostuser']. Exception: Unexpected error while running command. Command: ovs-vsctl --timeout=120 --oneline --format=json --db=tcp:127.0.0.1:6640 -- --may-exist add-port br-int vhu5e8b5246-cd -- set Interface vhu5e8b5246-cd external_ids:iface-id=5e8b5246-cd05-4735-9692-29d51db6e72d external_ids:iface-status=active external_ids:attached-mac=fa:16:3e:8f:b1:a1 external_ids:vm-uuid=30675d24-bd74-409c-ba36-4c59a72283ec type=dpdkvhostuser Exit code: 1 Stdout: '' Stderr: 'ovs-vsctl: tcp:127.0.0.1:6640: database connection failed (Connection refused)\n': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. 2021-03-09 06:30:36.594 3282 ERROR vif_plug_ovs.ovsdb.impl_vsctl [req-a514ba2a-7ada-4a35-944e-0c861055112e eacae20dfeb9442eb8643bb8784b03d1 caee3c14634f42438ec8479eb49ba388 - default default] Unable to execute ['ovs-vsctl', '--timeout=120', '--oneline', '--format=json', '--db=tcp:127.0.0.1:6640', '--', '--columns=mtu_request', 'list', 'Interface']. Exception: Unexpected error while running command. Command: ovs-vsctl --timeout=120 --oneline --format=json --db=tcp:127.0.0.1:6640 -- --columns=mtu_request list Interface Exit code: 1 Stdout: '' Stderr: 'ovs-vsctl: tcp:127.0.0.1:6640: database connection failed (Connection refused)\n': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. 2021-03-09 06:30:36.594 3282 ERROR os_vif [req-a514ba2a-7ada-4a35-944e-0c861055112e eacae20dfeb9442eb8643bb8784b03d1 caee3c14634f42438ec8479eb49ba388 - default default] Failed to plug vif VIFVHostUser(active=False,address=fa:16:3e:8f:b1:a1,has_traffic_filtering=False,id=5e8b5246-cd05-4735-9692-29d51db6e72d,mode='client',network=Network(6be19cbf-c6a7-4735-a0ee-42e1c5a664e2),path='/var/run/openvswitch/vhu5e8b5246-cd',plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=True,vif_name='vhu5e8b5246-cd'): oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. Command: ovs-vsctl --timeout=120 --oneline --format=json --db=tcp:127.0.0.1:6640 -- --columns=mtu_request list Interface Exit code: 1 Stdout: '' Stderr: 'ovs-vsctl: tcp:127.0.0.1:6640: database connection failed (Connection refused)\n' ============================= ovs information: =========================== _uuid : 4a56f11f-f839-4032-ba85-2eec47260144 bridges : [1a600d85-9849-459a-8453-9a28eee63dc4, f21a1111-3c01-4988-99b7-ca5ab4a73051] cur_cfg : 653 datapath_types : [netdev, system] db_version : "7.16.1" dpdk_initialized : false dpdk_version : none external_ids : {hostname="cmp001", "odl_os_hostconfig_config_odl_l2"="{\"allowed_network_types\": [\"local\", \"flat\", \"vlan\", \"vxlan\", \"gre\"], \"bridge_mappings\": {}, \"datapath_type\": \"netdev\", \"supported_vnic_types\": [{\"vif_details\": {\"uuid\": \"4a56f11f-f839-4032-ba85-2eec47260144\", \"host_addresses\": [\"cmp001\"], \"has_datapath_type_netdev\": true, \"support_vhost_user\": true, \"port_prefix\": \"vhu\", \"vhostuser_socket_dir\": \"/var/run/openvswitch\", \"vhostuser_ovs_plug\": true, \"vhostuser_mode\": \"client\", \"vhostuser_socket\": \"/var/run/openvswitch/vhu$PORT_ID\"}, \"vif_type\": \"vhostuser\", \"vnic_type\": \"normal\"}]}", odl_os_hostconfig_hostid="cmp001", rundir="/var/run/openvswitch", system-id="ec007ae5-4b61-4f8e-af2b-b1b97413d20d"} iface_types : [erspan, geneve, gre, internal, "ip6erspan", "ip6gre", lisp, patch, stt, system, tap, vxlan] manager_options : [11b3ada9-d9b3-42bb-97fc-d254364acecd] next_cfg : 653 other_config : {local_ip="10.1.0.5", provider_mappings="physnet1:br-floating"} ovs_version : "2.11.1" ssl : [] statistics : {} system_type : ubuntu system_version : "18.04" =========================== # ovs-vsctl get bridge br-int datapath_type system =========================== *COMPUTE NODE 2:* nova-compute.log =========================== ERROR nova.compute.manager Failed to build and run instance: libvirt.libvirtError: internal error: process exited while connecting to monitor: qemu-system-x86_64: -chardev socket,id=charnet0,path=/var/run/openvswitch/vhub701eeae-c0: Failed to connect socket /var/run/openvswitch/vhub701eeae-c0: No such file or directory Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 2353, in _build_and_run_instance block_device_info=block_device_info) File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 3204, in spawn destroy_disks_on_failure=True) File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 5724, in _create_domain_and_network destroy_disks_on_failure) File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ self.force_reraise() File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise six.reraise(self.type_, self.value, self.tb) File "/usr/lib/python3/dist-packages/six.py", line 693, in reraise raise value File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 5693, in _create_domain_and_network post_xml_callback=post_xml_callback) File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 5627, in _create_domain guest.launch(pause=pause) File "/usr/lib/python3/dist-packages/nova/virt/libvirt/guest.py", line 144, in launch self._encoded_xml, errors='ignore') File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ self.force_reraise() File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise six.reraise(self.type_, self.value, self.tb) File "/usr/lib/python3/dist-packages/six.py", line 693, in reraise raise value File "/usr/lib/python3/dist-packages/nova/virt/libvirt/guest.py", line 139, in launch return self._domain.createWithFlags(flags) File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 190, in doit result = proxy_call(self._autowrap, f, *args, **kwargs) File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 148, in proxy_call rv = execute(f, *args, **kwargs) File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 129, in execute six.reraise(c, e, tb) File "/usr/lib/python3/dist-packages/six.py", line 693, in reraise raise value File "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 83, in tworker rv = meth(*args, **kwargs) File "/usr/lib/python3/dist-packages/libvirt.py", line 1110, in createWithFlags if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) libvirt.libvirtError: internal error: process exited while connecting to monitor: 2021-03-10T07:59:04.064555Z qemu-system-x86_64: -chardev socket,id=charnet0,path=/var/run/openvswitch/vhub701eeae-c0: Failed to connect socket /var/run/openvswitch/vhub701eeae-c0: No such file or directory INFO nova.compute.manager Took 0.68 seconds to deallocate network for instance. INFO nova.scheduler.client.report Deleted allocation for instance 308de941-1192-4dbd-8c4d-d7860139d6d4 =========================== ovs information: =========================== _uuid : b8f5b869-e794-4052-8896-3ee5d323a0b7 bridges : [5b6ab0c7-d8f1-43b0-9ab7-1e77280cd3ff, 70810190-6796-4500-bda4-dae856bcede1] cur_cfg : 1267 datapath_types : [netdev, system] db_version : "7.16.1" dpdk_initialized : false dpdk_version : none external_ids : {hostname="cmp002", "odl_os_hostconfig_config_odl_l2"="{\"allowed_network_types\": [\"local\", \"flat\", \"vlan\", \"vxlan\", \"gre\"], \"bridge_mappings\": {}, \"datapath_type\": \"netdev\", \"supported_vnic_types\": [{\"vif_details\": {\"uuid\": \"b8f5b869-e794-4052-8896-3ee5d323a0b7\", \"host_addresses\": [\"cmp002\"], \"has_datapath_type_netdev\": true, \"support_vhost_user\": true, \"port_prefix\": \"vhu\", \"vhostuser_socket_dir\": \"/var/run/openvswitch\", \"vhostuser_ovs_plug\": true, \"vhostuser_mode\": \"client\", \"vhostuser_socket\": \"/var/run/openvswitch/vhu$PORT_ID\"}, \"vif_type\": \"vhostuser\", \"vnic_type\": \"normal\"}]}", odl_os_hostconfig_hostid="cmp002", rundir="/var/run/openvswitch", system-id="dddc6d6c-0e7c-4813-97c9-7c72eaf9f46b"} iface_types : [erspan, geneve, gre, internal, "ip6erspan", "ip6gre", lisp, patch, stt, system, tap, vxlan] manager_options : [29b4ef4b-e2ba-43f3-aa42-b1bacaf9dd19, 75ae95f6-d251-4152-9e0d-5b65e5f7bb77] next_cfg : 1267 other_config : {local_ip="10.1.0.6", provider_mappings="physnet1:br-floating"} ovs_version : "2.11.1" ssl : [] statistics : {} system_type : ubuntu system_version : "18.04" =========================== # ovs-vsctl get bridge br-int datapath_type netdev =========================== We don't use DPDK on our Openvswitch. Can anyone give us some advice on this issue? Thanks for helping us. [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/10/21, 04:09:46 PM

1 0

[nova?] kvm/libvirt options
by Mauricio Tavares 09 Mar '21

09 Mar '21

Which kvm options can I specify to an instance when I create it? I am looking at https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-kvm.h… and it has a handful of CPU ones (based on https://docs.openstack.org/nova/latest/configuration/config.html#libvirt) making me think the rest is some kind of openstack default which is a subset of what I can specify using, say, virsh define.

2 1

[election][requirements] PTL candidacy for Xena
by Matthew Thode 09 Mar '21

09 Mar '21

Hi all, I would like to self-nominate for the role of PTL of Requirements for the Xena release cycle. I am the current PTL for the Wallaby cycle and I am willing to continue in this role. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible (stuff like prettytable). 3. Fix some automation of generate contstraints (pkg-resources being added and setuptools being dropped) 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. I look forward to continue working with you in this cycle, as your PTL or not. Thank you for your support, -- Matthew Thode

2 1

[election][magnum] Xena PTL candidacy
by Spyros Trigazis 09 Mar '21

09 Mar '21

Hello OpenStack community, I would like to continue serving as Magnum PTL. In wallaby we mostly maintained and updated our templates for kubernetes and related addons along with the CI maintenance. In this release, our focus continues to be making the cloud operators easier with: * control-plane on operators tenant * performance improvements for API calls * cluster node replacement * finish transition to helm3 for addons See you in gerrit, Spyros Trigazis

1 0

[election][qa] PTL candidacy for Xena
by Martin Kopec 09 Mar '21

09 Mar '21

Hi everyone, I would like to nominate myself for the PTL role of the QA in the Xena cycle. This would be my first PTL service, however, I have been contributing to Tempest for several years and have been a core contributor for over a year now. I'm also a core in refstack projects (python-tempestconf, refstack and refstack-client). A few things I would like to focus on in the Xena cycle: * Get Tempest scenario manager effort [2] finished - we started actively working on this ~2 cycles ago and we have made significant progress. After it's done we will declare the interface stable which will help to decrease the code duplicity among tempest plugins which is directly related to the maintenance difficulty. * Keep decreasing the bug counts * Decrease the number of open patches. Although many projects suffer from not enough personal resources, we can't let the contributors go out of their steam by making their patches to wait in the queue for too long. * Complete priority items from the previous cycles [1] https://www.stackalytics.com/?user_id=mkopec [2] https://etherpad.opendev.org/p/tempest-scenario-manager Thanks for your consideration! -- Martin Kopec irc: kopecmartin

1 0

[tripleo][ci] stein and quay.io
by Wesley Hayutin 09 Mar '21

09 Mar '21

Greetings, FYI... At this time the accounts used to push containers in quay.io has been locked out. We are working with quay support to resolve the issue. It's not 100% clear if there is an issue w/ our account or more generally w/ quay [2] At this time we know that the stable/stein branch in tripleo is specifically configured to pull containers from quay and has an open issue [1]. Merging patches on stable/stein is likely blocked unless we move all those jobs to non-voting at this time. Is there any interest in moving the jobs to non-voting? Please respond if this issue is blocking you. Thanks all! [1] https://bugs.launchpad.net/tripleo/+bug/1915921 [2] https://status.quay.io/

1 0

[TripleO] Xena PTG - registration and reserved time slots
by Marios Andreou 09 Mar '21

09 Mar '21

Hello TripleO gentle early reminder that PTG is coming soon-ish... 12 April is not *that* far away ;) As requested by [1] I just booked some slots for us at https://ethercalc.net/oz7q0gds9zfi . I selected the same times we used for the Wallaby PTG - 1300-1700 UTC for Monday/Tuesday/Wednesday/Thursday. Obviously we are a massively distributed team so there is no good time that will suit everyone. However I think this serves well enough for the majority of our contributors? We may not use Thursday but it was pretty close last time with respect to the number of sessions requested so I booked it just in case. Please speak up if you disagree with the times and days I have booked. Finally *** REMEMBER TO REGISTER *** for the PTG at https://april2021-ptg.eventbrite.com regards, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-March/020915.ht…

1 1

[election][cloudkitty] PTL candidacy for Xena
by Rafael Weingärtner 09 Mar '21

09 Mar '21

Hello guys, I would like to self-nominate for the role of PTL of CloudKitty for the Xena release cycle. I am the current PTL for the Wallaby cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain CloudKitty for their use cases and encourage the addition of new functionalities. Thank you for your support, -- Rafael Weingärtner

1 0

[OSSN-0088] Some of the Glance metadef APIs likely to leak resources
by Abhishek Kekane 09 Mar '21

09 Mar '21

Some of the Glance metadef APIs likely to leak resources -------------------------------------------------------- ### Summary ### Metadef APIs are vulnerable and potentially leaking information to unauthorized users and also there is currently no limit on creation of metadef namespaces, objects, properties, resources and tags. This can be abused by malicious users to fill the Glance database resulting in a Denial of Service (DoS) condition. ### Affected Services / Software ### Glance ### Discussion ### There is no restriction on creation of metadef namespaces, objects, properties, resources and tags as well as it could also leak the information to unauthorized users or to the users outside of the project. By taking advantage of this lack of restrictions around metadef APIs, a a single user could fill the Glance database by creating unlimited resources, resulting in a Denial Of Service (DoS) style attack. Glance does allow metadef APIs to be controlled by policy. However, the default policy setting for metadef APIs allows all users to create or read the metadef information. Because metadef resources are not properly isolated to the owner, any use of them with potentially sensitive names (such as internal infrastructure details, customer names, etc) could unintentionally expose that information to a malicious user. ### Recommended Actions ### Since these fundamental issues have been present since the API was introduced, the Glance project is recommending operators disable all metadef APIs by default in their deployments. Here is an example of disabling the metadef APIs in the deployments for current stable OpenStack releases either in policy.json or policy.yaml. ---- begin example policy.json/policy.yaml snippet ---- "metadef_default": "!", "get_metadef_namespace": "rule:metadef_default", "get_metadef_namespaces": "rule:metadef_default", "modify_metadef_namespace": "rule:metadef_default", "add_metadef_namespace": "rule:metadef_default", "get_metadef_object": "rule:metadef_default", "get_metadef_objects": "rule:metadef_default", "modify_metadef_object": "rule:metadef_default", "add_metadef_object": "rule:metadef_default", "list_metadef_resource_types": "rule:metadef_default", "get_metadef_resource_type": "rule:metadef_default", "add_metadef_resource_type_association": "rule:metadef_default", "get_metadef_property": "rule:metadef_default", "get_metadef_properties": "rule:metadef_default", "modify_metadef_property": "rule:metadef_default", "add_metadef_property": "rule:metadef_default", "get_metadef_tag": "rule:metadef_default", "get_metadef_tags": "rule:metadef_default", "modify_metadef_tag": "rule:metadef_default", "add_metadef_tag": "rule:metadef_default", "add_metadef_tags": "rule:metadef_default" ---- end example policy.json/policy.yaml snippet ---- To re-enable metadef policies to be allowed to be admin only, operator(s) can make a change in respective policy.json or policy.yaml as shown below; (assuming all metadef policies are configured to use rule:metadeta_default as shown in above example) ---- begin example policy.json/policy.yaml snippet ---- "metadef_default": "rule:admin", ---- begin example policy.json/policy.yaml snippet ---- Operators with users that depend on metadef APIs may choose to leave these accessible to all users. In that case, education of users about the potential for information leakage in the resource names is advisable so that vulnerable practices can be altered as mitigation. To re-enable metadef policies to all users, operator(s) can make a change in respective policy.json or policy.yaml as shown below; (assuming all metadef policies are configured to use rule:metadeta_default as shown in above example) ---- begin example policy.json/policy.yaml snippet ---- "metadef_default": "", ---- begin example policy.json/policy.yaml snippet ---- ### Contacts / References ### Author: Abhishek Kekane, Red Hat Author: Lance Bragstad, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0088 Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1545702 Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1916926 Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1916922 Mailing List : [Security] openstack-security(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg Thanks & Best Regards, Abhishek Kekane

1 0

Cleanup database(s)
by Eugen Block 09 Mar '21

09 Mar '21

Hi *, I have a quick question, last year we migrated our OpenStack to a highly available environment through a reinstall of all nodes. The migration went quite well, we're working happily in the new cloud but the databases still contain deprecated data. For example, the nova-scheduler logs lines like these on a regular basis: /var/log/nova/nova-scheduler.log:2021-02-19 12:02:46.439 23540 WARNING nova.scheduler.host_manager [...] No compute service record found for host compute1 This is one of the old compute nodes that has been reinstalled and is now compute01. I tried to find the right spot to delete some lines in the DB but there are a couple of places so I wanted to check and ask you for some insights. The scheduler messages seem to originate in /usr/lib/python3.6/site-packages/nova/scheduler/host_manager.py ---snip--- for cell_uuid, computes in compute_nodes.items(): for compute in computes: service = services.get(compute.host) if not service: LOG.warning( "No compute service record found for host %(host)s", {'host': compute.host}) continue ---snip--- So I figured it could be this table in the nova DB: ---snip--- MariaDB [nova]> select host,deleted from compute_nodes; +-----------+---------+ | host | deleted | +-----------+---------+ | compute01 | 0 | | compute02 | 0 | | compute03 | 0 | | compute04 | 0 | | compute05 | 0 | | compute1 | 0 | | compute2 | 0 | | compute3 | 0 | | compute4 | 0 | +-----------+---------+ ---snip--- What would be the best approach here to clean up a little? I believe it would be safe to simply purge those lines containing the old compute node, but there might be a smoother way. Or maybe there are more places to purge old data from? I'd appreciate any ideas. Regards, Eugen

2 8

[election][blazar] PTL candidacy for Xena
by Pierre Riteau 09 Mar '21

09 Mar '21

Hi, I would like to self-nominate for the role of PTL of Blazar for the Xena release cycle. I have been PTL since the Stein cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain the Blazar software for their use cases and encourage the addition of new functionalities. Thank you for your support, Pierre Riteau (priteau)

1 0