- openstack-discuss - lists.openstack.org

[barbican] Question about container policy rule:container_acl_read
by Krzysztof Pawłowski 19 Apr '20

19 Apr '20

Hi, I have a question about policy for container consumers. Am I correctly understanding that the below policy in code should allow users with read acl to create consumer for container? policy.DocumentedRuleDefault( name='consumers:post', check_str='rule:admin or rule:container_non_private_read or ' + 'rule:container_project_creator or ' + 'rule:container_project_admin or rule:container_acl_read', scope_types=[], description='Creates a consumer.', operations=[ { 'path': '/v1/containers/{container-id}/consumers', 'method': 'POST' } ] ), policy.RuleDefault( name='container_acl_read', check_str="'read':%(target.container.read)s"), It's not working for me and I want to be sure if I'm doing something wrong or it's designed to work other ways. My current solution is below policy to allow role 'creator' to update consumers: {"consumers:post": "rule:admin or rule:creator or rule:container_non_private_read or rule:container_project_creator or rule:container_project_admin or rule:container_acl_read"} Greets, Krzysztof Pawłowski

1 0

[PTL][SIG] Virtual PTG Layout & Signup
by Kendall Nelson 19 Apr '20

19 Apr '20

Greetings! I am sure you have all been anxiously awaiting more details on how we are going to virtualize the PTG :) After the community meetings we had last week/the week before to understand the key challenges and ideate on solutions, we have a plan! The virtual event will be held from Monday June 1 to Friday June 5. We set up available times in 3 different time windows where each window is a cross over time between at least 2 regions (Window A - Americas/Europe, Window B - Europe/APAC, and Window C - APAC/Americas). Here is an ethercalc[1]. We ask that the PTL/SIG Chair/Team lead sign up for time to have their discussions in with 4 rules/guidelines. 1. Cross project discussions (i.e. SIGs and horizonal teams), try to schedule yourselves towards the start of the week so that any discussions that might shape those of vertical teams might happen first. 2. Vertical teams (ex. Nova, Cyborg, Manila) should wait till April 6th at 7:00 UTC to start signing up for slots to help prioritize the scheduling of cross project conversations. 3. No team (SIG, horizonal project, vertical project, etc) can sign up for more than 4 hours per UTC day to help keep participants actively engaged. 4. No team (SIG, horizonal project, vertical project, etc) can sign up for more than 16 hours across all time slots to avoid burning out our contributors and to enable participation in multiple teams discussions. Once every team has had a chance to sign up (lets say two weeks from today April 28th at 7:00 UTC) if signing up for more time makes sense, it will be possible. We want to encourage ANY team to sign up, even those that had originally said no to the initial outreach when the PTG was supposed to be in person. The more the merrier! Once you have signed up for time slots, please also fill out this survey[2] with your team information. We need this additional information to help shape other decisions down the road and coordinate other details closer to the event. If you have any issues with signing up your team, due to conflict or otherwise, please let me know! While we are trying to empower you to make your own decisions as to when you meet and for how long (after all, you know your needs and teams timezones better than we do), we are here to help! Continue to check back for updates at openstack.org/ptg. -the Kendalls (diablo_rojo & wendallkaters) [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://openstackfoundation.formstack.com/forms/june2020_virtual_ptg_survey

11 20

[goals][Drop Python 2.7 Support] Week R-4 Update
by Ghanshyam Mann 18 Apr '20

18 Apr '20

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" at end of R-4 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… Highlights: ======== * Storlets wanted to keep py2.7 as Swift doing which is a valid request. Revert of py2.7 drop patches is ins progress. I am updating the goal doc also - https://review.opendev.org/#/c/720714/1 * Reaching out to individual projects PTL to merge the pending patches. If not done by next week. I am going to leave those from tracking which are pending for a long time but not getting attention from the team. They will fail the gate or already failing due to almost all projects are py3-only. Project wise status and need reviews: ============================ Phase-1 status: All the OpenStack services have dropped the python2.7. Phase-2 status: * Pending Tempest plugins: ** kuryr-tempest-plugin: https://review.opendev.org/#/c/704072/ I have replied to the comments on this patch. * Pending pythonclient: ** python-barbicanclient: https://review.opendev.org/#/c/699096/2 *** gate is already broken waiting for gate to be fixed. ** python-zaqarclient: https://review.opendev.org/#/c/692011/4 * Few more repo patches need to merge: ** masakari-specs: https://review.opendev.org/#/c/698982/ ** nova-powervm: https://review.opendev.org/#/c/700683/ ** paunch: https://review.opendev.org/#/c/703344/ * Deployment projects in progress: *** Openstack Charms - Most of them merged, few failing on func job. debugging. *** Openstackansible - In-progress. centos7 jobs are failing on few projects. ** Waiting from projects team to know the status: *** Openstack-Helm (Helm charts for OpenStack services) **** Discussion going on - http://lists.openstack.org/pipermail/openstack-discuss/2020-April/013814.ht… * Open review: https://review.opendev.org/#/q/topic:drop-py27-support+status:open Phase-3 status: This is audit and requirement repo work. I have started this and reaching out to projects need more work. How you can help: ============== - Review the patches. Push the patches if I missed any repo. -gmann

1 0

[election][nova] PTL Candidacy for Victoria
by Balázs Gibizer 18 Apr '20

18 Apr '20

Hi, I'd like to announce my candidacy for Nova PTL for Train. I'm a long time Nova contributor and Nova core since 2017. I'm currently serving as temporary Nova PTL since we lost Eric during the Ussuri cycle. We are facing multiple challenges for Victoria. We have to organize the first fully virtual PTG to plan the Victoria cycle due to sever travel restrictions around the word. I have already proposed ways [1] to the Nova team and I will continue working on making the best out of the current situation. In the past months we have lost Matt and Eric, two key contributors and Nova maintainers. So I will work on regrowing the Nova core team to restore our review bandwidth. As a first step I proposed two new Nova core members [2][3]. But I will also look for more possible candidates and I will try to mentor them to further increase the size of the core team. We have many unfinished business from the Ussuri cycle. So as a PTL I have the intention to make the team focus on finishing these work before we start any new big change in Nova. Thanks, Balazs Gibizer (gibi) [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013555.ht… [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013511.ht… [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013519.ht…

3 2

[tripleo] TripleO CI Summary: Unified Sprint 25
by Rafael Folco 17 Apr '20

17 Apr '20

Greetings, The TripleO CI team has just completed **Unified Sprint 25** [0] (Mar 27 thru Apr 16). The following is a summary of completed work during this sprint cycle [1]: - Contributed for TripleO-Operator-Ansible. - Internal component pipeline prep work: created the artifact requirements to build the pipeline (container and overcloud image builds). - Created an unified tempest test skip list <https://opendev.org/openstack/openstack-tempest-skiplist>. - Started migrating promoter jobs to CentOS8 and a new design for loading promoter configurations from multiple sources. - Migrated fs039 free ipa job to CentOS8 and fixed podman molecule testing. - Worked on collect-logs fixes for openstack-ansible jobs. - Restarted work on an upstream standalone TLS job - Started work to validate ansible 2.9 and the latest ceph-ansible - Started work on an ironic tempest plugin - Ruck/Rover recorded notes [2]. The planned work for the next sprint [3] extends the work started in the previous sprint and focuses on the following: - Stable branching work (ussuri): design ussuri jobs migration and do the prep work for moving upstream and periodic jobs. - TripleO-Operator-Ansible: contribute w/ code, docs, tests and zuul jobs. - Internal component pipeline: continue building the pipeline with the artifacts and jobs created in the previous sprint. - Shared Tempest role design. - 3rd party CI jobs naming alignment. - Continue work on an upstream standalone TLS job - Continue work to validate ansible 2.9 and the latest ceph-ansible - Refine the design for refactoring, consolidation and de-duplication of get_hash role across repositories. The Ruck and Rover for this sprint are Gabriele Cerami (panda) and Amol Kahat (akahat). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in etherpad [4]. Thanks, rfolco [0] Note: Unified Sprint 25 corresponds to “Sprint 45”. We also combined “Unified Sprints 24/25” to align with other TripleO DFGs after getting out of sync at the 2019 end of year shutdown. From now on we are going to refer to sprints with the “Unified Sprint” naming convention. [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-25 <https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-24> [2] https://hackmd.io/XMd_vskSTdGZl7ruZ1UckA [3] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-26 [4] https://hackmd.io/rKRieheXTtyIDtGHiiF-hQ

1 0

[ops] [nova] Default nova quota for project user
by Massimo Sgaravatto 17 Apr '20

17 Apr '20

Hello As far as I understand by default each project user is given the quota of the whole project. Is it possible to set a different default quota for users of a certain project ? And in general I'd like to be able to define different default values for different projects In: https://docs.openstack.org/nova/latest/admin/quotas.html it is explained how to update the quota for a specific project user, but I can't find how to set the default user quota for a given project Thanks, Massimo

3 5

[TripleO][Ansible] generating ansible.cfg for manual config-download
by Federico Iezzi 17 Apr '20

17 Apr '20

Hey there, I've recently played with Config-Download in TripleO. My aim was since the begging running Ansible standalone w/o relying on Mistral. TripleO Ansible [1] can introduce drastic flexibility, IMO much needed to improve the overall experience. Now, the major road blocker I found, was in relation of Ceph-Ansible. Without the nice ansible.cfg from Mistral, it's pretty much a bit hard running Ansible standalone. Yes, manually exporting the various Ansible paths can do the trick, but down the road, more and more roles may be introduced forcing users to always discover the latest ones. For example, in my case without the original ansible.cfg, the issue was the following braking ceph-ansible. $ ansible-playbook -i inventory.yaml --private-key ~/.ssh/id_rsa --become deploy_steps_playbook.yaml The error appears to be in '/home/stack/config-download/external_deploy_steps_tasks.yaml': line 13, column 13, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - import_role: role: ceph ^ here To solve it, I wrote this simple [2] Python script that relies on write_default_ansible_cfg from ansible in tripleo_common. The result is that, after the heat provisioning [3] I generate the config-download folder (with all its contents), the inventory and also the ansible.cfg file and ansible standalone can be executed called. You can find my templates and work at [4] What do you think about including the ansible.cfg as part of the config-download generation procedure? Cheers, Federico [1] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deploym… [2] https://github.com/m4r1k/nfvi_lab/blob/osp16/deployment_wrappers/write_defa… [3] https://github.com/m4r1k/nfvi_lab/blob/osp16/deployment_wrappers/005-deploy… [4] https://github.com/m4r1k/nfvi_lab/tree/osp16

3 4

[all] Removing Babel from requirements.txt
by Dmitry Tantsur 17 Apr '20

17 Apr '20

Hi folks, Many of the projects have [1] Babel in requirements.txt. I'm not sure why it was needed initially, but now Babel is only used in the translation infrastructure to manage the catalogs. Particularly, it's not imported in runtime by anything (oslo.i18n has recently removed [2] its usage). The problem is, Babel weighs nearly 30MiB (estimated on a venv), making it probably the heaviest dependency we have. According to amotoki, we don't need Babel anywhere in the requirements, since the translation infrastructure installs it explicitly [3][4]. Sphinx has a requirement on Babel, so doc and release note builds will be fine as well. I suggest that all projects remove an explicit requirement on Babel completely. I've started proposing changes [5] to implement it for repositories that are used by ironic projects (since it's my immediate area of interest). I'd appreciate help with the others. Dmitry [1] http://codesearch.openstack.org/?q=Babel&i=nope&files=requirements.txt&repo… [2] https://review.opendev.org/720550 [3] https://opendev.org/openstack/project-config/src/branch/master/playbooks/tr… [4] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-babel/tas… [5] https://review.opendev.org/#/q/topic:no-babel

3 2

[ops] RabbitMQ Config suggestions for > 100 nodes?
by Fabian Zimmermann 17 Apr '20

17 Apr '20

Hi, we run some openstack clusters and currently see issues with a lot connections in rabbitmq. So I would like to ask if someone here has some knowhow about running openstack on >100 nodes he is able to share. Our setup: * 3 Nodes Control-Plane * RabbitMQ Cluster with "sync_mode: all" (had issues during node-failure in the past without this) * transport_url contains all 3 nodes Most of the connections are neutron-based. We already played a bit with max_pool and max_pool_overload, but didnt change anything. As next try I would add some haproxy-lb and change the transport_url to the VIP, this should afaik reduce the amount of connections to 1/3, but I dont know if there are any drawbacks jet. Any suggestions? Thanks a lot, Fabian

3 2

[qa][devstack] Moving to release specific nodesets and jobs for Fedora
by Lee Yarwood 16 Apr '20

16 Apr '20

Hello all, $subject has come up with the last couple rounds of changes introducing support for the latest version of Fedora within devstack. I've pushed a change introducing version specific nodesets and jobs for Fedora 31 as a way of starting a discussion around this ahead of the PTG: WIP Fedora: Start using version specific nodesets and jobs https://review.opendev.org/#/c/719775/ I'm personally on the fence about this as while it would be nice to have version specific nodesets and jobs it does introduce a lot of churn with each new release of Fedora across many projects: http://codesearch.openstack.org/?q=fedora%5C-latest Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

4 5

[QA][barbican][cloudkitty][heat][ironic][magnum][manila][monasca][swift] Intermediary release reminder
by Sean McGinnis 16 Apr '20

16 Apr '20

Quick reminder that for deliverables following the cycle-with-intermediary model, the release team will use the latest ussuri release available on release week. The following deliverables have done a ussuri release, but it has not been refreshed in the last two months: Quality Assurance patrole barbican barbican-ui cloudkitty cloudkitty heat heat-agents ironic bifrost ironic-inspector ironic-prometheus-exporter ironic-python-agent ironic-ui ironic networking-baremetal networking-generic-switch magnum magnum-ui manila manila-ui monasca monasca-thresh monasca-ui swift swift There are still a couple weeks to go, so this is just a reminder that you should consider making a new one very soon, so that we don't use an outdated version for the final release. Just let me know if there any questions. Thanks! Sean

3 4

[tripleo] ptg meetings and time zones
by Wesley Hayutin 16 Apr '20

16 Apr '20

Greetings, Looking to see if there are strong preferences for our time slots for the PTG. I would suggest we try to shoot for 13-17 UTC slot [1] as much as possible. Any strong preference in not utilizing that time slot? Reminder.. topics topics topics Thanks all 0/ [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://etherpad.opendev.org/p/tripleo-victoria-topics <https://etherpad.opendev.org/p/tripleo-victoria-topics>

3 2

[TripleO][Ironic] pxe boot remote host
by Ruslanas Gžibovskis 16 Apr '20

16 Apr '20

Hi all, Could someone help me, I do not get, I try to boot remote host (behind Firewall). I have dhcp-relay configured. And finally, I see the DHCP request, but nothing else happens... except me crying ;'( "D DHCP request captured on undercloud vnet5 where dhcp is listening also on eth1, But I am not able to load a remote host. I had a thought, maybe DHCP is generally not working, but one node which is local, I am able to introspect and provide it. completely nothing in /var/log/containers/ironic-inspector/dnsmasq.log Any suggestions? My network, which I used and have configured on undercloud host is: 10.120.191.80/28 and IP for DHCP which is configured as dhcp relay is 94. output from tcpdump: 21:19:00.058565 40:a6:77:4b:07:cb > 52:54:00:20:c1:dc, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 58, id 60458, offset 0, flags [none], proto UDP (17), length 576) 10.41.94.241.67 > 10.120.191.94.67: [udp sum ok] BOOTP/DHCP, Request from 24:6e:96:14:a1:a4, length 548, hops 1, xid 0x9614a1a4, secs 12, Flags [Broadcast] (0x8000) Gateway-IP 10.41.94.241 Client-Ethernet-Address 24:6e:96:14:a1:a4 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Parameter-Request Option 55, length 36: Subnet-Mask, Time-Zone, Default-Gateway, Time-Server IEN-Name-Server, Domain-Name-Server, RL, Hostname BS, Domain-Name, SS, RP EP, RSZ, TTL, BR YD, YS, NTP, Vendor-Option Requested-IP, Lease-Time, Server-ID, RN RB, Vendor-Class, TFTP, BF Option 128, Option 129, Option 130, Option 131 Option 132, Option 133, Option 134, Option 135 MSZ Option 57, length 2: 1260 GUID Option 97, length 17: 0.68.69.76.76.57.0.16.56.128.80.200.192.79.56.68.50 ARCH Option 93, length 2: 0 NDI Option 94, length 3: 1.2.1 Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001" -- Ruslanas Gžibovskis +370 6030 7030

2 4

[kolla][ptg] virtual PTG
by Mark Goddard 16 Apr '20

16 Apr '20

Hi, For Victoria we will again be having a virtual PTG, however this time due to "you know what" we will be holding it at the same time as the other teams. The PTG will take place from 1st - 5th June, with various slots [1] available throughout the day from which we can select. Looking at previous events [2][3], we had two four hour slots. For Train this was 12:00 - 16:00 UTC, and for Ussuri 14:00 - 18:00 UTC. Note that Train was during daylight savings, Ussuri was not. We also held a mid-Train planning session for Kayobe [4], which took two hours. Based on the above, I suggest we go with the same as Ussuri: Monday 1st: 14:00 - 18:00 UTC (kolla) Tuesday 2nd: 14:00 - 18:00 UTC (kolla) Wednesday 3rd: 14:00 - 16:00 UTC (kayobe) This is just a proposal - if you would like to attend these sessions and the above time slots do not work for you, please get in touch. In particular, please speak up if these slots are significantly out of your working day - with sufficient interest we could split sessions across timezones. [1] https://ethercalc.openstack.org/126u8ek25noy [2] https://etherpad.openstack.org/p/kolla-ussuri-ptg [3] https://etherpad.openstack.org/p/kolla-train-ptg [4] https://etherpad.opendev.org/p/kayobe-train-planning Cheers, Mark

2 4

[tc] [ironic] Promoting ironic to a top-level opendev project?
by Dmitry Tantsur 16 Apr '20

16 Apr '20

Hi everyone! This topic should not come as a huge surprise for many, since it has been raised numerous times in the past years. I have a feeling that the end of Ussuri, now that we’ve re-acquired our PTL and are on the verge of selecting new TC members, may be a good time to propose it for a formal discussion. TL;DR I’m proposing to make Ironic a top-level project under opendev.org and the OpenStack Foundation, following the same model as Zuul. I don’t propose severing current relationships with other OpenStack projects, nor making substantial changes in how the project is operated. (And no, it’s not an April 1st joke) Background ========= Ironic was born as a Nova plugin, but has grown way beyond this single case since then. The first commit in Bifrost dates to February 2015. During these 5 years (hey, we forgot to celebrate!) it has developed into a commonly used data center management tool - and still based on standalone Ironic! The Metal3 project uses standalone Ironic as its hardware management backend. We haven’t been “just” a component of OpenStack for a while now, I think it’s time to officially recognize it. And before you ask: in no case do I suggest scaling down our invaluable integration with Nova. We’re observing a solid growth of deployments using Ironic as an addition to their OpenStack clouds, and this proposal doesn’t try to devalue this use case. The intention is to accept publicly and officially that it’s not the only or the main use case, but one of the main use cases. I don’t think it comes as a surprise to the Nova team. Okay, so why? =========== The first and the main reason is the ambiguity in our positioning. We do see prospective operators and users confused by the perception that Ironic is a part of OpenStack, especially when it comes to the standalone use case. “But what if I don’t need OpenStack” is a question that I hear in most of these conversations. Changing from “a part of OpenStack” to “a FOSS tool that can integrate with OpenStack” is critical for our project to keep growing into new fields. To me personally it feels in line with how OpenDev itself is reaching into new areas beyond just the traditional IaaS. The next OpenDev even will apparently have a bare metal management track, so why not a top-level project for it? Another reason is release cadence. We have repeatedly expressed the desire to release Ironic and its sub-projects more often than we do now. Granted, *technically* we can release often even now. We can even abandon the current release model and switch to “independent”, but it doesn’t entirely solve the issue at hand. First, we don’t want to lose the notion of stable branches. One way or another, we need to support consumers with bug fix releases. Second, to become truly “independent” we’ll need to remove any tight coupling with any projects that do integrated releases. Which is, essentially, what I’m proposing here. Finally, I believe that our independence (can I call it “Irexit” please?) has already happened in reality, we just shy away from recognizing it. Look: 1. All integration points with other OpenStack projects are optional. 2. We can work fully standalone and even provide a project for that. 3. Many new features (RAID, BIOS to name a few) are exposed to standalone users much earlier than to those going through Nova. 4. We even have our own mini-scheduler (although its intention is not and has not been to replace the Placement service). 5. We make releases more often than the “core” OpenStack projects (but see above). What we will do ============ This proposal involves in the short term: * Creating a new git namespace: opendev.org/ironic * Creating a new website (name TBD, bare metal puns are welcome). * If we can have https://docs.opendev.org/ironic/, it may be just fine though. * Keeping the same governance model, only adjusted to the necessary extent. * Keeping the same policies (reviews, CI, stable). * Defining a new release cadence and stable branch support schedule. In the long term we will consider (not necessary do): * Reshaping our CI to rely less on devstack and grenade (only use them for jobs involving OpenStack). * Reducing or removing reliance on oslo libraries. * Stopping using rabbitmq for messaging (we’ve already made it optional). * Integrating with non-OpenStack services (kubernetes?) and providing lighter alternatives (think, built-in authentication). What we will NOT do ================ At least this proposal does NOT involve: * Stopping maintaining the Ironic virt driver in Nova. * Stopping running voting CI jobs with OpenStack services. * Dropping optional integration with OpenStack services. * Leaving OpenDev completely. What do you think? =============== Please let us know what you think about this proposal. Any hints on how to proceed with it, in case we reach a consensus, are also welcome. Cheers, Dmitry

24 93

OpenStack should be buildable with sphinx 2.4: FTBFS in many packages
by Thomas Goirand 16 Apr '20

16 Apr '20

Hi, Sphinx 2.4 has been uploaded to Experimental. I just received bug reports against the OpenStack packages because some of them cannot be built with Sphinx 2.4. Here's the list: - ironic - os-api-ref - aodh - cloudkitty - kombu - panko - ceilometerclient - ceilometermiddleware - doc8 - dracclient - glareclient - murano-pkg-check - os-xenapi - scciclient - sahara - sphinxcontrib-programoutput - tempest-horizon It'd be nice if those affected could be fixed for Ussuri. IMO, it's just the doc, so fixing it wouldn't hurt code quality. In other words: help would be more than welcome writing patch or reviewing them, and testing Sphinx 2.4 compatibility. Cheers, Thomas Goirand (zigo)

7 13

[neutron] port binding issues after upgrade attempt
by Jean-Philippe Méthot 15 Apr '20

15 Apr '20

Hi, We’ve been running a somewhat old version of openstack-queens for a while (I don’t know the exact release number, you will understand why shortly). Our setup has dedicated network nodes which we set up to use l3ha not too long ago. The package version was more recent on the second network node than on the first one because of that, however, high availability worked fine. We then tried to upgrade to rocky and since then, we get binding failed errors for pretty much all our ports whenever a router change network node. The only way we’ve found to fix this is to shutdown our neutron services and then reimport our pre-upgrade openstack database backup. This way, every port gets created properly, as it was at the time. Since then we have: -Moved everything back to queens. -Reinstalled our controller and network nodes from scratch (which is why I don’t know which queens version we were using before). However, this issue still happens as soon as the router change network node. Most ports get binding failed errors and restoring the database backup is the only way we managed to get out of this issue each time. We use neutron-openvswitch for networking and tunneling is done with GRE. Our OS is centos 7. Is it possible that code pertaining to HA may have changed in the later versions of queens and rocky which could explain that we’re running into a bug of some sort? Is there a way I could get neutron to tell me exactly why port binding is failing? Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc.

1 0

[all][elections][tc] Technical Committee Election Results
by Kendall Nelson 15 Apr '20

15 Apr '20

Hello Everyone! Please join me in congratulating the 5 newly elected members of the Technical Committee (TC). Graham Hayes (mugsie) Kristi Nikolla (knikolla) Mohammed Naser (mnaser) Belmiro Moreira (belmoreira) Rico Lin (ricolin) Full results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_95cb11614fb23566 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round! -Kendall Nelson (diablo_rojo) & the Election Officials

9 8

[tripleo] undercloud installation failed at "waiting for container to start"
by Giuseppe Sannino 15 Apr '20

15 Apr '20

Hi all, need a (hopefully) small help from you. I'm trying to deploy Openstack on RHLE8 using TripleO. The "openstack undercloud install" fails at this stage: 2020-04-10 17:43:35.554 574937 WARNING tripleoclient.v1.tripleo_deploy.Deploy [ ] Wait for containers to start for step 5 using paunch ------------------------------------------------------------------------------------------------------------------------------------------------ 623.63s 2020-04-10 17:43:35.554 574937 WARNING tripleoclient.v1.tripleo_deploy.Deploy [ ] Wait for containers to start for step 4 using paunch ------------------------------------------------------------------------------------------------------------------------------------------------ 304.39s Images are fetched from the RedHat registry and pushed on the local registry: *>> containers-prepare-parameter.yaml* ContainerImageRegistryCredentials: registry.redhat.io: xxx:yyy ContainerImagePrepare: - push_destination: rhosp-under.ctlplane.localdomain:8787 *>> From "/var/log/tripleo-container-image-prepare.log"* I can see images are properly pushed into local registry: 2020-04-10 17:17:22,339 587093 INFO tripleo_common.image.image_uploader [ ] [registry.redhat.io/rhosp-rhel8/openstack-nova-compute-ironic:16.0-91] Completed upload for image 2020-04-10 17:17:22,341 586855 INFO tripleo_common.image.image_uploader [ ] result [] 2020-04-10 17:17:22,370 586855 INFO root [ ] ContainerClustercheckConfigImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-101 ContainerClustercheckImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-mariadb:16.0-101 : : : ContainerZaqarImage: rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-zaqar-wsgi:16.0-91 DockerInsecureRegistryAddress: - rhosp-under.ctlplane.localdomain:8787 >> From "install-undercloud.log" I can see a smooth procedure till it gets to the "TASK [Debug output for task: Start containers for step XX ]" phase. Specifically, at step 5 it ends unsuccesfully. *>> podman image list* Empty *>> podman ps* Empty >> openstack tripleo container image list [stack@rhosp-under ~]$ openstack tripleo container image list +--------------------------------------------------------------------------------------------------------+ | Image Name | +--------------------------------------------------------------------------------------------------------+ | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-zaqar-wsgi:16.0-91 | | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-heat-engine:16.0-91 | : : : | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-cron:16.0-96 | | docker://rhosp-under.ctlplane.localdomain:8787/rhosp-rhel8/openstack-keystone:16.0-93 | +--------------------------------------------------------------------------------------------------------+ Any suggestion would be more than welcome Many thanks in advance /Giuseppe

3 5

[neutron] Bug deputy report for week of April 6th
by Lajos Katona 15 Apr '20

15 Apr '20

Hi, I was Neutron bug deputy last week, please read a short summary of last week's reported Neutron bugs. What I would like to highlight: 1871032 <https://bugs.launchpad.net/neutron/+bug/1871032> and 1871239 <https://bugs.launchpad.net/neutron/+bug/1871239> are unassigned and 1871608 <https://bugs.launchpad.net/neutron/+bug/1871608> needs more investigation (at least from my side to what happens there). - Critical bugs - Rally job on stable branches is failing ( https://bugs.launchpad.net/neutron/+bug/1871596) In Progress - High priority bugs - Not Assigned: - OVN migration scripts doesn't work with SSL-only deployment ( https://bugs.launchpad.net/neutron/+bug/1871032) - ovn-octavia-provider is not using load balancing algorithm source-ip-port (https://bugs.launchpad.net/neutron/+bug/1871239) - In Progress - neutron.tests.functional.agent.ovn.metadata.test_metadata_agent.TestMetadataAgent.test_agent_registration_at_chassis_create_event fails randomly (https://bugs.launchpad.net/neutron/+bug/1871340) - OVN octavia provider driver should spawn long-living process in driver agent (https://bugs.launchpad.net/neutron/+bug/1871355) - fix Released - [VPNaaS]: DeprecationWarning: invalid escape sequence ( https://bugs.launchpad.net/neutron/+bug/1871621) - More investigation is necessary - OVN] Cannot create metadata port for segmented network ( https://bugs.launchpad.net/neutron/+bug/1871608) - Low priority bugs - [OVN] local conf devstack for a ovn-northd (DB only) node does not work (https://bugs.launchpad.net/neutron/+bug/1871730) - Whishlist - neutron ovn db clients need more logs if they fail to connect to db (https://bugs.launchpad.net/neutron/+bug/1871427) - Incomplete or solved in other projects - vm cannot be created after a large number of vms are removed from the same node (https://bugs.launchpad.net/neutron/+bug/1870723) - stable/stein tempest-full job fails with "tempest requires Python '>=3.6' but the running Python is 2.7.17" was solved in devstack ( https://bugs.launchpad.net/neutron/+bug/1871327) It was solved in devstack Best wishes Lajos (lajoskatona) ,-.,-. ( ( ( \ ) ) _..-.._ __)/ ,',' `. ," `. ,--. `. ," @ .' ` \ (Y ( ;''. `--.____, \ , ; ((_ ,----' ,---' _,'_,' (((_,- (((______,-' ------------------------------------------------ Thank you for visiting https://asciiart.website/ This ASCII pic can be found at https://asciiart.website/index.php?art=holiday/easter

2 4

[manila] Driver interface changes
by Carlos Silva 14 Apr '20

14 Apr '20

Greetings, zorillas! During the previous week we have merged a change in manila which improves the create share from snapshot functionality [1] to allow a multi-stage share creation. This means that a share creation request at the share manager can be acknowledged by the share driver to be pending; and the share manager will call a different driver interface to gather the status of this share, periodically until it is created. The primary benefit of this change is for drivers that cannot clone their snapshots instantaneously into new shares, and for drivers that would like to implement snapshot cloning across different storage pools or back ends. To make these changes, we needed to change the driver interface. All in-tree drivers were already modified and are up to date with the changes in the interface. The out-of-tree drivers will need to be updated as well according to the changes in the interface, then they will be able to work properly. [1] https://review.opendev.org/#/c/709697/ Regards, Carlos Eduardo da Silva.

1 0

[oslo] Ussuri stable branches created
by Ben Nemec 14 Apr '20

14 Apr '20

This has two major implications: 1) Master is no longer feature frozen 2) Any future Ussuri bug fixes will need to be backported Because of 2 and in spite of 1, please try to avoid merging any highly invasive changes to master between now and the Ussuri coordinated release. If we end up needing a last-minute bug fix we don't want to have to disentangle it from a huge refactoring effort (or whatever) in order to backport. Thanks. -Ben

1 0

[all][elections][tc] TC Voting Last Days
by Kendall Nelson 14 Apr '20

14 Apr '20

We are coming down to the last hours for voting in the TC election. Voting ends Apr 14, 2020 23:45 UTC. Search your gerrit preferred email address[0] for the following subject: Poll: OpenStack 'Victoria' TC Election (yes, the CIVS system had problems with escaped characters) That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/#victoria-tc-candidates What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from an official deliverable repo[1] and email the election officials[2]. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/raw/tag/0.5.0/reference/projects.y… [2] https://governance.openstack.org/election/#election-officials

1 0

[tc][all][SDK][API] Multi-region/edge OpenStack deployment
by Marie Delavergne 14 Apr '20

14 Apr '20

Hi, Following the previous discussions regarding approaches to make several instances of OpenStack collaborative[1], we finally decided to make a research report on the approach we initially proposed during the edge hackathon in Berlin (OSF summit 2018). The document is a short article (~10 pages long)[2] that gives a rather complete overview of the approach. If you are interested to see how mutliple instances of distinct OpenStack can give the illusion of a single system you might be interested to give it a look. A brief excerpt: “We propose a novel approach that delivers any collaboration between services of distinct OpenStack once and for all. Our approach eliminates development efforts related to the brokering aspect by leveraging dynamic composition and a Domain Specific Language (DSL). Using these two mechanisms, Admins/DevOps can specify, on a per-request basis, which services from which OpenStacks are required for the collaboration. This information is then interpreted to dynamical recompose services between the different OpenStacks, enabling the execution of single-, cross- or multiple-site requests without code effort.” The main idea is, considering several OpenStacks running, to use a DSL to specify which instance of the service (i.e. on which Openstack) the user wants its request to be executed. For instance, to provision a VM on a Nova in Paris using an image from a Glance in New York. You may contact the API either in NewYork or in Paris and perform the following request: "openstack server create --image debian --scope { compute: Paris, image: New York }" Along with the report comes a proof of concept available on GitLab[3]. Feel free to get back to us. Cheers [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013562.ht… [2] https://hal.inria.fr/hal-02527366/ [3] https://gitlab.inria.fr/discovery/openstackoid ---- Marie Delavergne

2 2

[cinder] datera ibm-gpfs macrosan sandstone - upcoming deadlines
by Brian Rosmaita 14 Apr '20

14 Apr '20

This is a reminder that the drivers listed in the subject have ussuri blueprints containing some open items. datera: https://blueprints.launchpad.net/cinder/+spec/datera-driver-restoration - needs: update support matrix, update docs if necessary, release note ibm-gpfs: https://blueprints.launchpad.net/cinder/+spec/ibm-gpfs-supported - have declared intent to restore CI and mark driver supported, but no patches yet macrosan: https://blueprints.launchpad.net/cinder/+spec/macrosan-driver-supported - support patch mixed in with features, so must be merged by noon UTC on Friday 17 April - patch requires revision - at this point, should probably make sure the CI is running reliably and split the patch into (a) mark the driver supported in ussuri, and (b) the new features (which will be held for victoria) sandstone: https://blueprints.launchpad.net/cinder/+spec/add-sandstone-driver - needs: update support matrix, documentation page, release note Please address these issues immediately; all patches should be merged before RC-1 (23 April). Tracking this on: https://etherpad.opendev.org/p/cinder-ussuri-driverstuff

1 0

[tripleo] puppet-tripleo has puppet-openstack-unit-5.5-centos-8 broken
by Takashi Kajinami 14 Apr '20

14 Apr '20

# resending with the correct tag. sorry for the noise. Hi All, Currently puppet-openstack-unit-5.5-centos-8 job in puppet-tripleo is broken. I've already filed a bug[1] and submitted the fix[2] to revert the commit which caused the failure. [1] https://bugs.launchpad.net/tripleo/+bug/1872562 [2] https://review.opendev.org/#/c/719699/ Please hold rechecks in puppet-tripleo until the fix is merged. Sorry for the inconvenience. Thank you, Takashi -- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam(a)redhat.com

2 2

[nova]-Pci device pass-through error.
by zhangcf9988＠aliyun.com 13 Apr '20

13 Apr '20

Hello, contributors to the Openstack community: I've got a problem and I'd love to get some advice. When we used the openstack-pike version, we encountered the following problems: Deployment environment: The openstack-pike version of openstack was installed on CentOS7.7.1908 system using yum, where nova version was 9.1.3 Nova - compute node: The Dell R730 server was used, and three graphics CARDS of the same model Nvidia 1050 Ti were installed. At the same time, the iommu was enabled and the graphics card pass-through was configured. But we had a problem: Two PCI expansion board CARDS were installed on Dell R730, two Nvidia 1050 Ti graphics CARDS were installed on the first PCI expansion board card, and one was installed on the second PCI expansion board card. As an Nvidia 1050 Ti graphics card is composed of two chips, respectively: Video card chip (Proudct_id:1c82, Vendor_id:10de) Sound card chip (Proudct_id:0fb9, Vendor_id:10de) Create a VM, we hope that the VM can passthrough for graphics and sound card chip at the same time, but we test found that VM will get 2 graphics or sound card chip, rather than a complete physical graphics should be some graphics and sound card chip, consequences of this, we installed the three pieces of graphics card, no one can be normal use, because the first VM occupies two graphics chips, lead to the second created, VM libvirtd detected a VM occupies physical graphics graphics chips, cause the failure of the second always create a VM. At the same time, I also tested that when I removed one of the two Nvidia graphics CARDS on the first PCI expansion board card and installed a physical Nvidia graphics card on the first and second PCI expansion board CARDS, the test created a VM that could obtain a video card and a sound card chip at the same time, so that the VM successfully obtained a complete Nivida physical graphics card. We hope that we can insert pieces of the same type of graphics card, but now we tried by modifying the nova pci_devices table in the database, the first VM can be modified by the graphics card is assigned the wrong question, but in fact, the second VM still complains when created, and will also we manually modify the database information to clean up, at present there are two possible solutions, the first is to modify the source code, the second is using different types of graphics CARDS, don't know the problem, can be solved by modifying the source code. Thank you very much. The following is the configuration of nova on the control node: [DEFAULT] enabled_apis = osapi_compute,metadata my_ip = 172.16.160.206 use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver transport_url = rabbit://openstack:mqpass123@baseserver available_filters=nova.scheduler.filters.all_filters available_filters=nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter enabled_filters=RamFilter,ComputeFilter,AvailabilityZoneFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,PciPassthroughFilter [api] auth_strategy = keystone [api_database] connection = mysql+pymysql://nova:novapass123@baseserver/nova_api [cinder] os_region_name = RegionOne [database] connection = mysql+pymysql://nova:novapass123@baseserver/nova [ephemeral_storage_encryption] [filter_scheduler] [glance] api_servers = http://controller:9292 [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = baseserver:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = novapass123 [neutron] url = http://controller:9696 auth_url = http://controller:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = netpass123 service_metadata_proxy = true metadata_proxy_shared_secret = 20190909 [oslo_concurrency] lock_path=/var/lib/nova/tmp [pci] alias = { "name": "nvidia1050ti", "product_id": "1c82", "vendor_id": "10de", "device_type": "type-PCI" } alias = { "name": "nvidia1050ti", "product_id": "0fb9", "vendor_id": "10de", "device_type": "type-PCI" } [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://controller:35357/v3 username = placement password = novapass123 [vnc] enabled = true vncserver_listen = $my_ip vncserver_proxyclient_address = $my_ip #The following is the configuration for nova-compute: /etc/nova/nova.conf: [DEFAULT] enabled_apis = osapi_compute,metadata transport_url = rabbit://openstack:mqpass123@baseserver my_ip = 172.16.160.204 use_neutron = True firewall_driver = nova.virt.firewall.NoopFirewallDriver instance_name_template = instance-%(uuid)s remove_unused_base_images=false [api] auth_strategy = keystone [keystone_authtoken] auth_uri = http://controller:5000 auth_url = http://controller:35357 memcached_servers = baseserver:11211 auth_type = password project_domain_name = default user_domain_name = default project_name = service username = nova password = novapass123 [vnc] enabled = True #vncserver_listen = 0.0.0.0 #vncserver_proxyclient_address = $my_ip vncserver_listen = 172.16.160.204 vncserver_proxyclient_address = 172.16.160.204 novncproxy_base_url = http://172.16.160.206:6080/vnc_auto.html keymap=en-us [glance] api_servers = http://controller:9292 [oslo_concurrency] lock_path = /var/lib/nova/tmp [placement] os_region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://controller:35357/v3 username = placement password = novapass123 [libvirt] virt_type = kvm #virt_type = qemu use_usb_tablet=true [filter_scheduler] enabled_filters = RetryFilter,AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,AggregateCoreFilter,AggregateDiskFilter,DifferentHostFilter,SameHostFilter, PciPassthroughFilter available_filters = nova.scheduler.filters.all_filters [PCI] passthrough_whitelist = [{ "vendor_id": "10de", "product_id": "1c82" }, {"vendor_id": "10de", "product_id": "0fb9"}] alias = { "name": "nvidia1050ti", "product_id": "1c82", "vendor_id": "10de", "device_type": "type-PCI"} alias = { "name": "nvidia1050ti", "product_id": "0fb9", "vendor_id": "10de", "device_type": "type-PCI"} [neutron] metadata_proxy_shared_secret = 20190909 service_metadata_proxy = true url = http://controller:9696 auth_url = http://controller:35357 auth_type = password project_domain_name = default user_domain_name = default region_name = RegionOne project_name = service username = neutron password = netpass123 flavor: openstack flavor create --public --ram 10240 --disk 50 --vcpus 4 nvidia1050ti --id 1 \ --property os_type=windows \ --property hw_firmware_type=uefi \ --property hw_machine_type=q35 \ --property img_hide_hypervisor_id=true \ --property os_secure_boot=required \ --property hw_cpu_cores=4 \ --property hw_cpu_sockets=1 \ --property hw_cpu_threads=2 \ --property pci_passthrough:alias='nvidia1050ti:2' image: openstack image create win10base1903UEFI --file win10base1903Q35V1.qcow2 --container-format bare --disk-format qcow2 --public \ --property os_type=windows \ --property hw_firmware_type=uefi \ --property hw_machine_type=q35 \ --property img_hide_hypervisor_id=true \ --property os_secure_boot=required \ --property hw_cpu_cores=4 \ --property hw_cpu_sockets=1 \ --property hw_cpu_threads=2 \ --property pci_passthrough:alias='nvidia1050ti:2' #The following is an error reported in openstack-nova -compute: 2020-03-31 10:57:04.555 2643 INFO os_vif [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Successfully plugged vif VIFBridge(active=False,address=fa:16:3e:51:25:34,bridge_name='brq8d505aa1-51',has_traffic_filtering=True,id=1a673f99-8a71-41be-a87e-40f3308fcfc3,network=Network(8d505aa1-5146-49db-8814-7dcef91bd1c1),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1a673f99-8a') 2020-03-31 10:57:04.723 2643 ERROR nova.virt.libvirt.guest [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Error launching a defined domain with XML: <domain type='kvm'> <name>instance-7e5d283f-5ed5-4ebe-b145-d348e94addca</name> <uuid>7e5d283f-5ed5-4ebe-b145-d348e94addca</uuid> <metadata> <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> <nova:package version="16.1.7-1.el7"/> <nova:name>test1</nova:name> <nova:creationTime>2020-03-31 02:57:04</nova:creationTime> <nova:flavor name="nvidia1050ti_50G"> <nova:memory>10240</nova:memory> <nova:disk>50</nova:disk> <nova:swap>0</nova:swap> <nova:ephemeral>0</nova:ephemeral> <nova:vcpus>4</nova:vcpus> </nova:flavor> <nova:owner> <nova:user uuid="68711849a60849d7807d71968ba6b275">demo</nova:user> <nova:project uuid="fa79259f6d2a442c86d4cd5e0e6c788c">demo</nova:project> </nova:owner> <nova:root type="image" uuid="24bb256e-9cea-4dcd-96e0-e6bd81156052"/> </nova:instance> </metadata> <memory unit='KiB'>10485760</memory> <currentMemory unit='KiB'>10485760</currentMemory> <vcpu placement='static'>4</vcpu> <cputune> <shares>4096</shares> </cputune> <sysinfo type='smbios'> <system> <entry name='manufacturer'>RDO</entry> <entry name='product'>OpenStack Compute</entry> <entry name='version'>16.1.7-1.el7</entry> <entry name='serial'>30535dfb-90e3-401e-bbf7-f2c43120fb65</entry> <entry name='uuid'>7e5d283f-5ed5-4ebe-b145-d348e94addca</entry> <entry name='family'>Virtual Machine</entry> </system> </sysinfo> <os> <type arch='x86_64' machine='pc-q35-rhel7.6.0'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> <nvram>/var/lib/libvirt/qemu/nvram/instance-7e5d283f-5ed5-4ebe-b145-d348e94addca_VARS.fd</nvram> <boot dev='hd'/> <smbios mode='sysinfo'/> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='123456789ab'/> </hyperv> <kvm> <hidden state='on'/> </kvm> </features> <cpu mode='host-model' check='partial'> <model fallback='allow'/> <topology sockets='1' cores='4' threads='1'/> </cpu> <clock offset='localtime'> <timer name='pit' tickpolicy='delay'/> <timer name='rtc' tickpolicy='catchup'/> <timer name='hpet' present='no'/> <timer name='hypervclock' present='yes'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca/disk'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </disk> <controller type='usb' index='0' model='qemu-xhci'> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x11'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0x12'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='pci' index='5' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='5' port='0x14'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/> </controller> <controller type='pci' index='6' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='6' port='0x15'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/> </controller> <controller type='pci' index='7' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='7' port='0x16'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/> </controller> <interface type='bridge'> <mac address='fa:16:3e:51:25:34'/> <source bridge='brq8d505aa1-51'/> <target dev='tap1a673f99-8a'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <log file='/var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca/console.log' append='off'/> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <log file='/var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca/console.log' append='off'/> <target type='serial' port='0'/> </console> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' listen='172.16.160.204' keymap='en-us'> <listen type='address' address='172.16.160.204'/> </graphics> <video> <model type='cirrus' vram='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x05' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x04' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> </hostdev> <memballoon model='virtio'> <stats period='10'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </memballoon> </devices> </domain> : libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.724 2643 ERROR nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Failed to start libvirt guest: libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.726 2643 INFO os_vif [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Successfully unplugged vif VIFBridge(active=False,address=fa:16:3e:51:25:34,bridge_name='brq8d505aa1-51',has_traffic_filtering=True,id=1a673f99-8a71-41be-a87e-40f3308fcfc3,network=Network(8d505aa1-5146-49db-8814-7dcef91bd1c1),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1a673f99-8a') 2020-03-31 10:57:04.741 2643 INFO nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Deleting instance files /var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca_del 2020-03-31 10:57:04.743 2643 INFO nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Deletion of /var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca_del complete 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Instance failed to spawn: libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Traceback (most recent call last): 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2203, in _build_resources 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] yield resources 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2018, in _build_and_run_instance 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] block_device_info=block_device_info) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 2903, in spawn 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] destroy_disks_on_failure=True) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5453, in _create_domain_and_network 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] destroy_disks_on_failure) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] self.force_reraise() 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] six.reraise(self.type_, self.value, self.tb) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5423, in _create_domain_and_network 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] post_xml_callback=post_xml_callback) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5341, in _create_domain 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] guest.launch(pause=pause) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 144, in launch 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] self._encoded_xml, errors='ignore') 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] self.force_reraise() 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] six.reraise(self.type_, self.value, self.tb) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/guest.py", line 139, in launch 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] return self._domain.createWithFlags(flags) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in doit 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] result = proxy_call(self._autowrap, f, *args, **kwargs) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in proxy_call 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] rv = execute(f, *args, **kwargs) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in execute 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] six.reraise(c, e, tb) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in tworker 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] rv = meth(*args, **kwargs) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1110, in createWithFlags 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] libvirtError: Requested operation is not valid: PCI device 0000:05:00.0 is in use by driver QEMU, domain instance-2de376e6-eb86-49aa-b35f-a8852143969d 2020-03-31 10:57:04.823 2643 ERROR nova.compute.manager [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] 2020-03-31 10:57:04.887 2643 INFO nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Terminating instance 2020-03-31 10:57:04.896 2643 INFO nova.virt.libvirt.driver [-] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Instance destroyed successfully. 2020-03-31 10:57:04.898 2643 INFO os_vif [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] Successfully unplugged vif VIFBridge(active=False,address=fa:16:3e:51:25:34,bridge_name='brq8d505aa1-51',has_traffic_filtering=True,id=1a673f99-8a71-41be-a87e-40f3308fcfc3,network=Network(8d505aa1-5146-49db-8814-7dcef91bd1c1),plugin='linux_bridge',port_profile=<?>,preserve_on_delete=False,vif_name='tap1a673f99-8a') 2020-03-31 10:57:04.939 2643 INFO nova.virt.libvirt.driver [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Deletion of /var/lib/nova/instances/7e5d283f-5ed5-4ebe-b145-d348e94addca_del complete 2020-03-31 10:57:05.025 2643 INFO nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Took 0.13 seconds to destroy the instance on the hypervisor. 2020-03-31 10:57:05.869 2643 INFO nova.compute.manager [req-2e175998-52b0-44fc-9bc9-a84d1766fe70 68711849a60849d7807d71968ba6b275 fa79259f6d2a442c86d4cd5e0e6c788c - default default] [instance: 7e5d283f-5ed5-4ebe-b145-d348e94addca] Took 0.62 seconds to deallocate network for instance. 2020-03-31 10:57:12.019 2643 INFO nova.compute.resource_tracker [req-5a0cf06d-ee8e-4839-a5a5-ee5269299d20 - - - - -] Final resource view: name=dellserver phys_ram=261922MB used_ram=10752MB phys_disk=399GB used_disk=50GB total_vcpus=48 used_vcpus=4 pci_stats=[PciDevicePool(count=0,numa_node=0,product_id='1c82',tags={dev_type='type-PCI'},vendor_id='10de'), PciDevicePool(count=2,numa_node=0,product_id='0fb9',tags={dev_type='type-PCI'},vendor_id='10de'), PciDevicePool(count=1,numa_node=1,product_id='1c82',tags={dev_type='type-PCI'},vendor_id='10de'), PciDevicePool(count=1,numa_node=1,product_id='0fb9',tags={dev_type='type-PCI'},vendor_id='10de')] zhangcf9988(a)aliyun.com

2 1

[project] puppet-tripleo has puppet-openstack-unit-5.5-centos-8 broken
by Takashi Kajinami 13 Apr '20

13 Apr '20

Hi All, Currently puppet-openstack-unit-5.5-centos-8 job in puppet-tripleo is broken. I've already filed a bug[1] and submitted the fix[2] to revert the commit which caused the failure. [1] https://bugs.launchpad.net/tripleo/+bug/1872562 [2] https://review.opendev.org/#/c/719699/ Please hold rechecks in puppet-tripleo until the fix is merged. Sorry for the inconvenience. Thank you, Takashi -- ---------- Takashi Kajinami Senior Software Maintenance Engineer Customer Experience and Engagement Red Hat e-mail: tkajinam(a)redhat.com

1 0

[tacker][neutron] Need help in setting up QOS for Neutron Service in Devstack CI Job
by Patil, Tushar 13 Apr '20

13 Apr '20

Hi OpenStackers, In tacker project, we need to setup QOS plugin in devstack CI job (tacker-functional-devstack-multinode-python3) to run our functional tests. I have checked what config options are needed to enable QOS in neutron and updated .zuul.yaml accordingly as you can see in patch [1] PS 18. Mainly, I have enabled following environment variables in .zuul.yaml:- Q_SERVICE_PLUGIN_CLASSES: router,neutron.services.metering.metering_plugin.MeteringPlugin,networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin,neutron.services.qos.qos_plugin.QoSPlugin, Q_ML2_PLUGIN_EXT_DRIVERS: port_security,qos L2_AGENT_EXTENSIONS: qos NEUTRON_PORT_SECURITY: False Problem: Main point is service_plugins config option is configured with qos but the [ml2].extension drivers doesn't include qos. I hav set qos" in Q_ML2_PLUGIN_EXT_DRIVERS but still it's not set in the /etc/neutron/plugins/ml2/ml2_conf.ini in Section [ml2].extension_drivers on the controller node and because of this reason the q-svc service is not starting on the controller node. I have scoured devstack.log to find out where it's overwriting extension_drivers with "port_security" instead of "port_security, qos" but I couldn't find one. On the controller node, we can see this log statement:- 2020-04-10 13:07:23.388678 | controller | + lib/neutron_plugins/ml2:populate_ml2_config:59 : iniset /etc/neutron/plugins/ml2/ml2_conf.ini ml2 extension_drivers port_security,qos It's clear from above log, qos is set properly but where exactly it's overwritten with just port_security or qos is removed is not clear to me. Any pointers where I can debug to solve this problem or how to set QOS correctly? [1]: https://review.opendev.org/#/c/717530/18 Regards, tpatil Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

2 3

Re: [Release-job-failures] Release of openstack/puppet-aodh for ref refs/tags/16.2.0 failed
by Emilien Macchi 13 Apr '20

13 Apr '20

We have identified the issue and will propose patches today and it'll fix the release jobs. On Mon, Apr 13, 2020 at 8:56 AM <zuul(a)openstack.org> wrote: > Build failed. > > - release-openstack-puppet > https://zuul.opendev.org/t/openstack/build/816a2104b2c94b199eaab1288b64f1c7 > : POST_FAILURE in 2m 57s > - announce-release https://zuul.opendev.org/t/openstack/build/None : > SKIPPED > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Emilien Macchi

3 3

[cinder] feature freeze and FFEs
by Brian Rosmaita 13 Apr '20

13 Apr '20

I wasn't paying close enough attention to the "real life" calendar, and did not realize that we would be so short-handed on reviewers around the Feature Freeze, with a lot of people unavailable. So, I am granting Feature Freeze Exceptions to the following. To make it into Ussuri, these should be merged by noon UTC on Friday 17 April. https://blueprints.launchpad.net/cinder/+spec/sf-aa-support - looks good, but I really want to allow time for one of our A/A HA experts to take a final look https://blueprints.launchpad.net/cinder/+spec/copy-image-in-multiple-stores - this may need a minor revision, but otherwise looks OK https://blueprints.launchpad.net/cinder/+spec/nfs-volume-encryption - some questions have come up about testing this one. We should decide by mid-week whether it still looks good for Ussuri or not. https://blueprints.launchpad.net/cinder/+spec/macrosan-driver-supported - this patch includes adding support for some new functionality and hence is subject to the feature freeze; needs a minor revision and release note; third-party CI appears functional. Problems need to be addressed very early next week, or this may wind up slipping to Victoria. The following blueprint contains multiple patches that have all been approved. Two haven't been able to merge; they require a rebase and conflict resolution. I expect that they will all merge early next week, but technically they require an FFE (which is granted). https://blueprints.launchpad.net/cinder/+spec/unity-ussuri-features The following blueprints are not yet marked 'Implemented', but the outstanding work is not subject to the feature freeze (mostly verification of stable third-party CI and then marking drivers as 'supported' or 'unsupported', which by Cinder policy must be done by RC-1). I just want to mention them so no one freaks out about not having an FFE. (You don't need one.) https://blueprints.launchpad.net/cinder/+spec/add-sandstone-driver https://blueprints.launchpad.net/cinder/+spec/cinder-nimble-driver https://blueprints.launchpad.net/cinder/+spec/datera-driver-restoration https://blueprints.launchpad.net/cinder/+spec/ibm-gpfs-supported https://blueprints.launchpad.net/cinder/+spec/restore-unsupported-drivers If I missed anything, please apply for a FFE by the usual method, that is, an email with the subject '[cinder] FFE request' before 18:00 UTC on Tuesday 14 April.

1 1

[requirements][glance]FFE for python/glanceclient stable/ussuri bug fix
by Abhishek Kekane 13 Apr '20

13 Apr '20

Hi Stackers, We have released python-glanceclient 3.1.0 last week, however testing it with a recent glance feature we have found one important bug [1] which is fixed in master and backported to stable/ussuri branch [2]. I am requesting a FFE for this so that we can release python-glanceclient 3.1.1 with this bug fix. Kindly consider my request. [1] https://launchpad.net/bugs/1871674 [2] https://review.opendev.org/#/c/718551/ Thanks & Best Regards, Abhishek Kekane

2 1

[Glance] FFE for python/glanceclient stable/ussuri bug fix
by Abhishek Kekane 13 Apr '20

13 Apr '20

Hi Stackers, We have released python-glancecient 3.0.0 last week, however testing it with a recent glance feature we have found one important bug [1] which is fixed in master and backported to stable/ussuri branch [2]. I am requesting a FFE for this so that we can release python-glanceclient 3.0.1 with this bug fix. Kindly consider my request. [1] https://launchpad.net/bugs/1871674 [2] https://review.opendev.org/#/c/718551/ Thanks & Best Regards, Abhishek Kekane

1 0

[TripleO] Train cannot finish introspection due to ironic-agent fails
by Ruslanas Gžibovskis 13 Apr '20

13 Apr '20

Hi all, I have python-ironic-agent failing using standard template files. Reproducible with CentOS7 + repos: * base: mirror.hh.se * centos-ceph-nautilus: mirror.hh.se * centos-nfs-ganesha28: mirror.hh.se * centos-openstack-train: mirror.hh.se * centos-qemu-ev: mirror.hh.se * epel: mirrors.glesys.net * extras: mirror.hh.se * updates: mirror.hh.se getting an error while loading provisioning, attached in the image attached. Text is: [ 317.948425] system[1]: Starting Ironic Python Agent. ... python trace ... SyntaxError: Non-ASCII character '\xe2' in file /usr/lib64/python2.7/site-packages/psutil/__init__.py on line 997, but no encoding declared: see http://www.python.org/peps/pep-0263.html for details any suggestions except running it on c8? Should i consider: remove epel repo? I have it added when creating images... install python3? from which repos? install some additional package? Thank you -- Ruslanas Gžibovskis +370 6030 7030

2 1

[goals][Drop Python 2.7 Support] Week R-6 Update
by Ghanshyam Mann 13 Apr '20

13 Apr '20

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" at end of R-6 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… Highlights: ======== * This is very close to mark as complete. * We merged many of charm repo patches and few more projects. * Few ansible repo failing on centos7 and waiting for migration on centos8 * I tried to reach out to team for pending patches. Project wise status and need reviews: ============================ Phase-1 status: All the OpenStack services have dropped the python2.7. Phase-2 status: * Pending Tempest plugins: ** cyborg-tempest-plugin: https://review.opendev.org/#/c/704076/ ** kuryr-tempest-plugin: https://review.opendev.org/#/c/704072/ * Pending pythonclient: ** python-barbicanclient: https://review.opendev.org/#/c/699096/2 *** gate is already broken waiting for gate to be fixed. ** python-zaqarclient: https://review.opendev.org/#/c/692011/4 ** python-tripleoclient: https://review.opendev.org/#/c/703344 * Few more repo patches need to merge: ** masakari-specs: https://review.opendev.org/#/c/698982/ ** cyborg-specs: https://review.opendev.org/#/c/698824/ ** nova-powervm: https://review.opendev.org/#/c/700683/ ** paunch: https://review.opendev.org/#/c/703344/ * Started pushing the required updates on deployment projects. ** Completed or no updates required: *** Openstack-Chef - not required *** Packaging-Rpm - Done *** Puppet Openstack- Done *** Tripleo - except python client, all is done. ** In progress: *** Openstack Charms - Most of them merged, few failing on func job. debugging. *** Openstackansible - In-progress. centos7 jobs are failing on few projects. ** Waiting from projects team to know the status: *** Openstack-Helm (Helm charts for OpenStack services) * Open review: https://review.opendev.org/#/q/topic:drop-py27-support+status:open Phase-3 status: This is audit and requirement repo work which is not started yet. I will start the audit in parallel to finishing the pending things listed above. How you can help: ============== - Review the patches. Push the patches if I missed any repo. -gmann

3 4

[doc][release][requirements] Issues with wsmeext.sphinxext
by Pierre Riteau 13 Apr '20

13 Apr '20

Hello, A heads up for other projects using wsmeext.sphinxext: it seems to be broken following the release of Sphinx 3.0.0 yesterday. Our openstack-tox-docs job in blazar started to fail with: Extension error: Could not import extension wsmeext.sphinxext (exception: cannot import name 'l_' from 'sphinx.locale' Looks like it would affect aodh and cloudkitty too. Pierre Riteau (priteau)

6 6

[FFE][requirements][castellan] Critical bug found in Castellan 3.0.0
by Douglas Mendizabal 13 Apr '20

13 Apr '20

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, I would like to request a Feature Freeze Exception for Requirements to remove Castellan 3.0.0 and use the soon-to-be-released 3.0.1 build. The Barbican team found a critical bug in the Castellan 3.0.0 release [1] that is currently breaking our gates. The Oslo team will be making a new 3.0.1 release as soon as the bugfix patch merges. [2] Thanks, Douglas Mendizábal Barbican PTL [1] https://bugs.launchpad.net/castellan/+bug/1872480 [2] https://review.opendev.org/#/c/718775 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEwcapj5oGTj2zd3XogB6WFOq/OrcFAl6UhEgACgkQgB6WFOq/ Orfl1g/+Ll6Zw2LB6pQeDBdx/YLYcfyYZWol14Ye45wELMArUSwxwsI/Ekwdmtgo VfMgP8tg+OxiD6/I2Wx2S+a4Cys8/SiXCO7hMwUSoGDdthI2lB8ICUgPqaiUvrbe nKH7IW0niVKQW9ISBw2w5TrAaCf4vg1e8KDBDQE91d8wng3Sv/DPZsVFEcU+bixE ayr7LKlNrCpeSzHIZE1YOqAYGyL7NtvruzPdC52yz1lE/iNbJSQQpLjXTcr/E7gl KzBTj04VclFRz/ESS1/VaLHfnHjEW0UmeM7xmr5H/mncJgLF8lQttifVjHZ+cvsp QziIp87IOIeWGh7PYUAKwqWeh+WKYLghGrzsLc6LlHy+QRx5kUqlv/6XbPkXfsDh RmaOoCB3PkP0pStmbMNwfU6k9VWsa4K13ejOrDNZQfyHfcrzRfVFojcW7c+jRHZr R3Um4DP3LyozYA1c4U2WrHv5B+xO+e64LylNCt+mLQ+hoVUacrglA2PgMtak7pwe 5gJJTTLtJUXlwyoe2+iM4wu8JgKXOY3MuMh8R+e60/8U1IeAB2Meew6ec51qaNQ4 j9KCL3nopjpA/aJH1qCRjLqf2AslXFQ9XVtO9DmJ3MchDrqyVIKGDQk354AEUYvE o2zC1FVNNjmpsiam9QpNak+1D0IwxWXZBONjLD5K5R8cDBJMVBM= =6WW/ -----END PGP SIGNATURE-----

3 3

RE: [baremetal-sig][ironic] Baremetal whitepaper round 2: doodle
by Arne Wiebalck 13 Apr '20

13 Apr '20

Dear all, It seems that Wed April 15 at 2pm UTC (4pm CEST) seems to be the most convenient time. I've set up a video call here: https://cern.zoom.us/j/95696673823 Everyone is still welcome to join! As a reminder, the white paper is available from here: https://docs.google.com/document/d/1BmB2JL_oG3lWXId_NXT9KWcBJjqgtnbmixIcNsf… See you there! Arne -----Original message----- > From: Arne Wiebalck <Arne.Wiebalck(a)cern.ch> > Sent: Tuesday, April 7, 2020 10:14 AM > To: openstack-discuss(a)lists.openstack.org > Subject: [baremetal-sig][ironic] Baremetal whitepaper round 2: doodle > > Dear all, > > After the first very productive sessions on finishing the baremetal > whitepaper (thanks to everyone contributing and reviewing afterwards!), > we would like to keep the momentum and schedule a second round. > > I've set up a doodle here [0], and we will send out the call details > once we have settled on the time slot(s). > > If you'd like to participate, please make sure you reply to the doodle > before the end of this week. > > Thanks! > Arne > > [0] https://doodle.com/poll/kyd5vvgmg68vxduv > > > > >

1 0

[cinder][ops][extended-maintenance-sig][public-cloud-sig][enterprise-wg] Cinder to EOL some branches
by Brian Rosmaita 13 Apr '20

13 Apr '20

This is a courtesy notice that having received no responses to my email of 28 October [0] proposing to EOL some currently open Cinder branches, and following the policy articulated in [1], at today's Virtual PTG meeting the Cinder project team has decided to put the following stable branches into the End of Life state: driverfixes/mitaka driverfixes/newton stable/ocata stable/pike I will submit the paperwork to get this process moving one week from today (2 December 2019). cheers, brian [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010385.… [1] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l…

4 8

[neutron] Team meeting on Monday 13.04.2020 cancelled
by Slawek Kaplonski 12 Apr '20

12 Apr '20

Hi, Tomorrow is Easter Monday, I have holiday and will not be available to run our team meeting. So lets cancel it this time. See You all on next meeting which will be on Tuesday 21.04.2020. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[election][tacker][ptl] Announcing my PTL candidacy for Tacker (Yasufumi Ogawa)
by Yasufumi Ogawa 10 Apr '20

10 Apr '20

Hi all, I would like to nominate myself to be Tacker PTL for Victoria cycle. Our project is still active and going to implement requirements from telcom standardization and industries. I feel ready to do that. Thanks a lot. Regards, Yasufumi Ogawa

2 2

[octavia] dropping support for stable/queens
by Adam Harwell 10 Apr '20

10 Apr '20

I'm officially proposing dropping support for the queens stable branch of Octavia. Given a quorum of cores, we will move forward with marking it EOL and all that entails. Thanks, --Adam

5 5

[all][PTL][TC] U Community Goal: Project PTL & Contrib Docs Update #6
by Kendall Nelson 10 Apr '20

10 Apr '20

Hello Everyone! While we may be past feature freeze there is still time to complete this goal given that it is documentation focused. I urge those that have not started to do so immediately. If you need help, please let me know ASAP. For those projects that have not started yet, I would start with filling in the template[2] and then go take a look at what the others have done for more inspiration[1]. If you have any questions, please let me know or refer to the goal[3]. Once you get started, please make sure to keep the story up to date[4]. I look forward to reviewing your patches!! If there is anything I can do to help, please let me know. And also, I want to give a HUGE thank you to those that have already started/completed the goal! Nice work :) -Kendall (diablo_rojo) [1] Progress: https://review.opendev.org/#/q/topic:project-ptl-and-contrib-docs+(status:o… [2] Cookiecutter Template: https://opendev.org/openstack/cookiecutter/src/branch/master/%7b%7bcookiecu… [3] Accepted Goal: https://governance.openstack.org/tc/goals/selected/ussuri/project-ptl-and-c… [4] Task Tracking: https://storyboard.openstack.org/#!/story/2007236

1 0

[release] Release countdown for week R-4, April 13 - 17
by Sean McGinnis 10 Apr '20

10 Apr '20

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 ussuri deliverables can be proposed, well ahead of the final ussuri release date. General Information ------------------- We are still finishing up processing a few release requests, but the ussuri release requirements are now frozen. If new library releases are needed to fix release-critical bugs in ussuri, 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 ussuri 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 April 23 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/ussuri branches should be created soon for all not-already-branched libraries. You should expect 3-4 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), a tox.ini constraints URL update, and a patch updating any cycle-specific job templates to the victoria version. Please review those in priority so that the branch can be functional ASAP. Note that the victoria job templates may not be quite ready yet, so the patch may initially fail. A simple recheck once they are in place should allow the patch to pass. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for ussuri changes should be added there to make sure the consumers of your release notes see them. Finally, if you haven't proposed ussuri cycle-highlights yet, you are already late to the party. Please see http://lists.openstack.org/pipermail/openstack-discuss/2020-April/013823.ht… for details. Upcoming Deadlines & Dates -------------------------- RC1 deadline: April 23 (R-3 week) Final RC deadline: May 7 (R-1 week) Final Ussuri release: May 13

1 0

[release][nova] FFE request for Nova Policy Defaults Refresh BP
by Ghanshyam Mann 10 Apr '20

10 Apr '20

Hello Everyone, I would like to ask the FFE for policy default refresh BP[1]. Most of the work is merged for this[2] but not 100%. Few policies not yet merged (~7) and 3 policies code is not yet up which I am working on. With that, I need more time to finish this work and require the FFE. [1] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh [2] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… -gmann

3 3

[election][tacker][ptl] Announcing my PTL candidacy for Tacker (Hyunsik Yang)
by hyunsikYang 10 Apr '20

10 Apr '20

Hello all Tacker members! I am Hyunsik Yang from the IISTRC(Internet Infra System Technology Research Center), South Korea. I wish to nominate myself for consideration as a Tacker Project PTL for the Victoria Cycle. I've previously contributed code, bug fixes and several reviews for Tacker from the Queens cycle. My goal is to improve the Tacker project by making it more standardized and precise. If you have any questions, please feel free to ask me. Thank you. Best regards, Hyunsik Yang *----------------------------------------------------------------* *Hyunsik Yang (Ph. D candidate)* *DCN laboratory / School of Electronic Engineering* *Soongsil University * *511 Sangdo-dong Dongjak-gu* *Seoul, 156-743 Korea* *TEL : (+82)-2-820-0841 * *M.P: (+82)-10-9005-7439*

2 2

[all][ideas][releases] Introducing Project Stopwatch: Another proposal to change the release cycles
by Jean-Philippe Evrard 10 Apr '20

10 Apr '20

Hello, I would like us to discuss how our release cycles are defined. We've been discussing in the past about longer or shorter cycles. This is only recorded in the mailing lists, which are hard to search. We should try to record conversations in this new "ideas" framework if we can. I think it's time to record something about the release cycles in our ideas. However, before I start the 2020 version of the eternal war "longer cycles" vs "shorter cycles", I would like us to discuss about something a little bit different, that you can find in review [1]: project Stopwatch. I have discussed with a few of you already about Stopwatch and how we could do cycles differently. This is to write the idea down. For me, it's time to change the cycles, by introducing more time to cool down. To make this happen, I need your opinions, as it quite an impactful change for the whole OpenStack. Regards, Jean-Philippe Evrard [1]: https://review.opendev.org/#/c/718929/

1 0

Etherpad and Gerrit maintenance on 2020-04-10
by corvus＠inaugust.com 09 Apr '20

09 Apr '20

Hi, Tomorrow, April 10, 2020, the OpenDev team will be performing minor updates to two services. * Gerrit restart for https://review.opendev.org/ at 16:00 UTC. This should be a momentary outage to restart the service in a container. We will maintain the same version in the same configuration; this is a preparatory step in order to perform future version upgrades more easily. Other than a short outage of about a minute, there should be no service impact or visible changes, but since the environment is changing, we wanted to announce this in case any problems are detected. * Etherpad migration and domain change at 17:00 UTC. We will migrate the data currently hosted on etherpad.openstack.org to a new server, also running in a container, on etherpad.opendev.org. We will set up redirects so that on completion of the migration, all etherpad.openstack.org URLs will redirect to the same pages on etherpad.opendev.org. https://etherpad.opendev.org/ will become the new canonical service URL. This also includes an upgrade to the latest release of Etherpad Lite (1.8.0). This involves a database migration as well. The service will be unavailable for the duration of this migration (expected to be about 30 minutes). Please report any issues in #opendev on Freenode or to the service-discuss(a)lists.opendev.org mailing list. Note that this message is being sent to service-announce and several other lists. Future announcements of this type will only be sent to service-announce, so please sign up[1] for that list if you haven't already. [1] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce -Jim

1 0

[release][oslo] FFE request for Oslo Policy
by Ghanshyam Mann 09 Apr '20

09 Apr '20

Hi, This is regarding the FFE request for policy for - https://review.opendev.org/#/c/717879/ This is part of introducing scope_type and new defaults in policies. During Nova implemtnation[1], we came across two things to solve before we release the new policies changes: 1. A lot of warnings as policy default are changing which end up filling the logs (226 MB n-api logs today). 2. Give operators an option to switch to the new system (scope and new defaults) at the same time without overwriting the policy file. We discussed those two things to solve via oslo_policy[2] which need FFE approval. Sorry for being late on this which should be planned early. Please let me know if it is ok to include these changes in the Ussuri release. [1] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… [2] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… -gmann

4 5

[kolla] Kolla Klub first meeting tomorrow
by Mark Goddard 09 Apr '20

09 Apr '20

Hi Kollaborators, Just a reminder that we will meet tomorrow at 15:00 UTC. Join here: https://meet.google.com/hph-pynx-vsy I have created a Google doc for the meeting agenda and notes: https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_…. See you tomorrow, Mark

1 1