- openstack-discuss - lists.openstack.org

[all] Migrating upstream CI/CD jobs to Ubuntu Focal (20.04)
by Ghanshyam Mann 09 Jun '20

09 Jun '20

Hello Everyone, As per the victoria cycle testing runtime, we need to run upstream CI/CD jobs on Ubuntu Focal[1]. For better tracking and speeding up this work, TC is in the process of selecting this as 2nd goal for the Victoria cycle[2]. Plan: ------ * devstack will provide the WIP patch for devstack base job running on focal and all projects will test their jobs using the same[3]. * migrate projects side jobs to focal. This includes testing the jobs and fixing the failure if any or migrate jobs to run on focal nodeset if not automatically migrated by devstack job. * Once all projects are running successfully on focal, then merge the devstack base job. * Deadline: I am planning to finish this by m-2 (July 31st) but anytime before is always better. Current progress: ---------------------- * devstack base jobs migration on focal which can be used by project side testing is in progress. frickler patch failing with one nova test[4]. * As we have community goal to migrate all legacy jobs to zuulv3 native[5], migration to focal will only cover the devstack based or zuulv3 native jobs not the legacy jobs. All the legacy jobs will automatically be moved on focal distro during their migration to zuulv3 native. If anything failing and cannot be fixed immediately, then those legacy jobs can temporarily override the nodeset to bionic. * selecting this as community goal is also is in progress. [1] https://governance.openstack.org/tc/reference/runtimes/victoria.html [2] https://review.opendev.org/#/c/731213/ [3] https://review.opendev.org/#/c/731207/4 [4] https://review.opendev.org/#/c/734029/1 [5] https://governance.openstack.org/tc/goals/selected/victoria/native-zuulv3-j… -gmann

1 0

[tc][interop] Interop repos renaming from openstack/ to osf/ namespace
by Ghanshyam Mann 09 Jun '20

09 Jun '20

Hello Everyone, With OpenDev model, TC merged the resolution of keeping only openstack governance owned projects to 'openstack/' namespace[1]. Migration for other non-openstack-owned projects/repos have been done but Interop repos[1] are still under openstack/ namespace which is confusing. After discussing it in today interop meeting, it was agreed to move all the interop repos from 'openstack/' to 'osf/' namespace. I have proposed the changes to infra - https://review.opendev.org/#/c/734669/ Redirect will be provided for old url but few of the below things need to be taken care by interop team: - zuul jobs update to use the new url. I have proposed the changes which i found in my grep but if any job is missed, please update those with 734669 as Depends-On[3]. - github mirroring (if needed). After discussing it with clarkb,AJaeger, and fungi this needs to be done by osf github org admin. I am leaving that for now and something can be done once renaming is completed. [1] https://governance.openstack.org/tc/resolutions/20190322-namespace-unoffici… [2] https://opendev.org/openstack/interop https://opendev.org/openstack/refstack https://opendev.org/openstack/refstack-client https://opendev.org/openstack/python-tempestconf [3] https://review.opendev.org/#/q/topic:interop-repo-renaming+(status:open+OR+… -gmann

1 0

[tc][neutron] Victoria/Virtual PTG Summary
by Nate Johnston 09 Jun '20

09 Jun '20

As I sit down to describe the highlights of the virtual OpenDev PTG of June 2020, the first thing I have to say is that the virtual participation is a two edged sword. On one hand, the spontaneity of the hallway track and the ability to quickly drop in to another group's meeting were largely lost. But I think that there were some people in the Neutron room that would not have been able to make it if the event was held in Vancouver. Once the pandemic is in the rear view mirror, I hope that we can resume in-person events. But I think that there is potential value to interspersing virtual events with the in-person variety, to reach out to students, small companies, and ravel-averse companies or individuals. I'd also like to say that the Foundation staff did a great job with running an event that so completely broke from precedent. The choice of two videoconferencing platforms, with the ability of teams to select the one that matched their needs the best, was foresighted since certain areas had access issues with certain platforms. --- Technical Committee --- I felt that the TC sessions at this PTG were very productive and valuable. In particular, we used the 'raise hands' feature in Zoom to ensure an orderly exchange of views that gave everyone a chance to speak, and I felt that went very well. A few of the highlights of what the TC discussed and decided are: 1.) The TC decided to draft a policy change to provide a model for a project without a PTL. If an interested project was interested in changing to a PTL-less model they could opt-in to such a model, but for projects that do not opt in nothing would change. When imagining how a project could function without a PTL, we deconstructed the role into it's component parts, including: interfacing with the release, infrastructure, and security teams; doing the necessary prep work for PTG and summit events; acting as a public contact point for the project; acting as the bug resolver of last resort. Of these the only ones that are essential from a TC perspective are the release liaison and the infrastructure liaison (for CI issues); the VMT team already has a list of subject matter experts they consult for vulnerabilities. An events person may be called for on a per-event basis - and if no one steps forward for a project, then that project wouldn't be represented at that event. There's definitely more responsibility diffused within the project team in this model, without a "the buck stops here" PTL position. And not every question is answered - for example, who looks for potential cores to mentor and bring up to speed while still ensuring diversity in the core group over time? Look forward to a governance proposal in the coming month or so about this topic, and hopefully a lively discussion that will help us sort out the rough edges! 2.) There has been an increasing consensus that the division between the Technical Committee and the User Committee of OpenStack is an artificial one, a relic of the rapid-expansion phase of the OpenStack universe and not in keeping with the current OpenStack environment. In particular, with more operators contributing back and interested in guiding the technical evolution of OpenStack, the dichotomy between developers and operators/users seems false and sends the wrong message. To that end, the TC has formally proposed that the TC and UC should merge into a single body. Because changes to the Foundation bylaws are costly and slow, we would like to execute this merger without changes to the foundation bylaws. Since the TC is specified in greater detail than the UC in the bylaws, the merger would be accomplished by the UC becoming a subset of the TC. This change was anticipated by the higher rate of operators being nominated and elected to the TC this past election, and the proposed governance change [1] completes a merger that has been a long time in coming. 3.) There has been some feedback from operators that the unfinished migration from project-specific clients to the unified OpenStack client causes uncertainty and difficulty for both operators and users. Some have even created their own client that hides the difference between the unified client and the remaining project-specific clients. This is obviously a bad experience and something we can improve. Given this, the TC will place a greater emphasis on preparing the community to conclude the migration to OSC. 4.) The community goals for the V cycle have been selected, and they are to conclude the migration to Zuul v3, and to migrate the base Ubuntu image used in the upstream gates from Bionic 18.04 to Focal 20.04 [2]. 5.) In the U cycle the TC created the 'ideas' repository [3], which is a place for people to post ideas that they think would be great for the OpenStack community. We did this after reflecting that there are a lot of great ideas that are discussed on the mailing list that are perhaps a bit ahead of their time, and then get lost in the mailing list archives. Rather than forgetting about an idea, it could be posted to the ideas repo and then brought back when time is right. Rather than shifting the graveyard for ideas from the mailing list to this repo, the TC or a representative could review the tabulated ideas with an eye to what is ready for revival and discussion in a PTG or forum session. --- Neutron --- The Neutron community made good use of the Jitsi/Meetpad platform after a few opening hiccups. It handled the large number of people in the room well for the most part, and the etherpad integration was interesting. I think it was great how the Neutron team worked well with the Keystone, Nova, Cyborg, and Edge SIG teams and had great collaboration on each front. The themes in the Neutron community were the same as they have been before: stadium projects are increasingly being run by the Neutron core team, those that are not are entering hibernation, with networking-midonet currently at the most risk. The community slowly pushes forward with Engine Facade and is looking to fully deprecate python-neutronclient. We acknowledged that the neutron-lib migration has stalled and decided to make the process easier with debtcollector deprecations. The biggest thing for me in the summit was the decision to move forward with ML2/OVN as the default back end for Neutron, including in devstack. This will be proposed to the broader community and the Neutron team will work with everyone to make sure this is a success. In conclusion, I am as always grateful for the tremendous worldwide OpenStack community. I am proud of how much was accomplished, and I think this PTG sets the stage for a great Victoria cycle. Thanks, Nate [1] https://review.opendev.org/#/c/734074/ [2] Waiting on https://review.opendev.org/#/c/731213/ to be merged [3] https://governance.openstack.org/ideas/

1 0

[tripleo] Victoria TripleO PTG summary
by Wesley Hayutin 09 Jun '20

09 Jun '20

Greetings, Thanks to everyone who attended the OpenStack PTG last week! A special thanks to those who presented their topics and discussed work items with the folks in attendance. As you know the event was virtually hosted in a video conference and seemed quite busy and packed with great topics and conversations. As the current PTL for TripleO I will do my best here to summarize those conversations and items others should be made aware of. To review the topics and discussion please follow the links here [1]. The event was recorded, however the OpenStack foundation has not made any of the videos publicly available yet. Monday June 1st: Retrospective: The TripleO project started with a retrospective of the Ussuri cycle. I attempted to use OpenStack’s storyboard for the process, but had to revert to an etherpad for usability. Keep trying, Storyboard is getting there. The good news is that the good things outweighed the bad things [2], and the ideas for improvement were focused on making things faster \0/ TripleO Operator Ansible Status: by Alex Schultz Alex gave a nice overview of his hard work throughout Ussuri to make TripleO Operator Ansible a reality. TripleO Operator Ansible is the official way now to execute TripleO commands via ansible. The upstream ci and consultants in the field are all consolidating around the tool. The history of reviews to make this happen can be found [4], while Alex completed a lot of the work he also attracted a number of contributors that also completed a lot of work. One note that Alex wanted to emphasize was that while TripleO Operators are meant to be executed by customers, and consultants, TripleO-Ansible is NOT meant to be exposed or called directly. Slides are available here [3]. Thank you Alex! The Future of python-tripleoclient: by Rabi Mishra Rabi led a very interesting conversation about the steps the project would have to take to further simplify the stack of projects used in a TripleO deployment. Currently there are a number of layers in client calls to tripelo-operator-ansible, python-tripleoclient, tripleo-ansible playbooks/modules, tripleo-common library which is complex and not an ideal user experience in terms of logs, resolving bugs. Out of the gate Rabi discussed breaking down python-tripleoclient into something more basic and moving more functions to ansible modules. The proposal was to get rid of CLI or replace it with a very simple one and move all the logic in tripleoclient to ansible playbooks/modules. The top level playbooks would directly map to current cli actions and would be in tripleo-ansible repo. tripleo-operator-ansible can also change to use those playbooks directly and transparently under the hood. Details from the session can be found here [5]. Thanks Rabi! Ansible Strategies & us: by Alex Schultz Alex was up again to let us know what he’s been up to make Ansible more performant. Ansible offers several different kinds of “strategies” with regards to how tasks are executed across multiple hosts. The strategies are pluggable and Alex has built a custom strategy currently called “TripleO Free” that can be used across some but not all of TripleO’s tasks [7]. The performance enhancement is spectacular, reducing a 30 node deployment from almost 2 hours to under 50 minutes. Well done!!! I’ll note the strategy name will be changed to garner more community support and the performance gains are not as pronounced with fewer nodes. A standard CI like deployment ( 4-5 nodes ) can expect to see 20 minutes cut off the deployment Slides of Alex’s presentation can be found here [6]. Very well done! Thanks Alex! Mistral has been removed, so what is left to do? By Kevin Carter Kevin hit us next with what to expect now that mistral has been removed and what steps we need to take next to make the community successful. I’ll note the mistral container is still on the undercloud but inactive, and workflow processing has been converted directly to ansible. There is still some cleanup in tripleo-common and rpm dependencies to prune. A link to the conversation is available [8], and Kevin’s presentation is available [9]. Thank you Kevin! TripleO Operator Pipelines By Emilien Macchi Emilien walked us through what it would take to further consolidate on TripleO Operator Ansible based CI pipelines in TripleO, OSP and at customer sites. Breaking down the full workflow of a deployment and day two operations in CI was reviewed. The goal here is to replace as much CI as possible with TripleO Operator Ansible to have a standardized ansible interface with TripleO in any CI or customer environment. TripleO Operators are shipping in Ussuri and should be backwards compatible with earlier releases. There will be a major push upstream to further integrate TripleO Operator Ansible into every CI job. Notes and comments are published here [10]. Thanks a million! [1] https://etherpad.opendev.org/p/tripleo-ptg-victoria [2] https://etherpad.opendev.org/p/tripleo-ptg-retrospective [3] https://docs.google.com/presentation/d/1Oxs-sflnJd5KIMoY6e_mlfU2zK4QWqWSG7A… [4] https://etherpad.opendev.org/p/tripleo-operator-ansible [5] https://etherpad.opendev.org/p/tripleo-future-of-tripleoclient [6] https://docs.google.com/presentation/d/19mr3HyyYUUGcwbRHsy2-k-F4WNCYCoFvSPz… [7] https://review.opendev.org/#/q/topic:strategy-improvements [8] https://etherpad.opendev.org/p/tripleo-remove-mistral [9] https://docs.google.com/presentation/d/1iir7FA6YwBxRoU_SZJQ2H9Enbak4GAfBw73… [10] https://etherpad.opendev.org/p/tripleo-operator-pipelines Tuesday June 2nd CI updates: by Wes Hayutin In the CI update I mostly covered the new upstream Component Pipeline. The component pipeline has three major goals, the first is to enable us to release at any time with working components of OpenStack, secondly break down a large problem into smaller problems, and third reduce time to debug and fix. The presentation covers monolithic vs. components builds, the workflow and testing and monitoring of the pipeline. The presentation is available here [11] I also noted that the upstream CI executed 268,805 deployments of TripleO in the Ussuri cycle. Third party CI executed 132,853 deployments. Not to shabby. Details are here [12]. Thanks easter bunny! IPv6 and DCN (routed-networks) in upstream CI by Harald Jensas Harald kicked off the next topic about utilizing more advanced networking with OVB in our third party TripleO CI. The proposal is to update the CI with multiple network segments. Herald has been the primary of OVB ( openstack virtual baremetal ) and looks to be wrapping up this feature [13]. Documentation for the feature can be found here [14] and notes of the discussion are posted [15] Thank you Harald! Enable network isolation by default by Harald Jensas Harald continued the networking discussion by highlighting common mistakes made in the field with network isolation settings and TripleO. When customers or consultants accidentally forget to include network-isolation settings heat can be destructive to the production environment and delete networks during an update or upgrade. The discussion led to merged patches that already solve the issue, but catching it earlier in the process was still a concern and led to discussion around additional validations. The goal was also shifted to make network-isolation more approachable by our customers. A spec will be written to improve the customer experience here. Notes can be found [16] Thanks Harald! Future deprecation of tripleo-validations by Cedric Jeanneret Cedric led us through the current status and future of TripleO Validations. The deprecated version of the validations do not have clear ownership, and testing each validation has proved to be difficult. Enter the solution with the validation teams new framework of validations where the validation service is clearly delineated from the validations themselves. We discussed ownership, packaging, CI with the entire workflow of packaging and testing all have clear ownership and fits in very neatly with the component pipeline. Please read through the details of the discussion as this will impact several projects with a clean, exciting way to validate each service in OpenStack [17]. Thank you Cedric!! Container Image Build v2 by Emilien Macchi and Kevin Carter Kevin and Emilien have been putting in a lot of extra hours revamping the container build system for TripleO and have produced a much improved system in record time. TripleO will benefit from smaller containers, faster builds and the flexibility to handle upstream and downstream builds easily. If you haven’t seen the presentation please do have a look [18]. Notes on the topic can be found here [19]. Get involved if you can keep up, Thanks Emilien, Kevin! Ceph Integration w/ cephadm by Francesco Pantano, Giulio Fidente, John Fulton The storage trio walked us through details of cephadm and the ramifications of replacing ceph-ansible. We discussed a wide range of topics here including what features should be built into TripleO vs. handled directly by cephadmin like scale up/down, updates, upgrades. The team walked us through how they dissected the deployment and injected cephadmin as a proof of concept that everything works well and proved we’re in good hands on the storage front. There is a lot of detail in the notes, so please have a read through here [20]. Thank you Francesco, Giulio ( aka bob dylan ), John! Removal of Heat and Swift from Undercloud by Rabi Mishra Rabi continued from his earlier topic regarding the noble effort to further simplify the OpenStack deployment by removing heat and swift. Rabi articulately described how heat is currently used in the latest release and what would have to be done to remove both heat and swift, walking us through heat resources, extra config, IPAM etc and how each could potentially be replaced. I personally really enjoyed hearing this particular topic and how we can move forward making OpenStack less complex. This is an important topic and you should review Rabi’s clear strategy here [21]. Thanks Rabi! Database migrations - can we make them more friendly, or can we do them a better way? By Jesse Pretorius Jesse led us next and spoke to the hard and complex problem of database migrations across OpenStack projects. This session was more of a brainstorming exercise in discovering creative solutions to complex problems. Unfortunately the group felt the problem came down to governance of OpenStack itself in more uniformly enforcing migration details. It was concluded getting all the projects to agree on a standard for migrations would be quite the uphill climb. Notes on the subject can be found here [22]. Thanks Jesse! [11] https://drive.google.com/file/d/1rAohZ01BDFGBOjI3kS9jy-n-P1weQVIX/view [12] https://etherpad.opendev.org/p/tripleo-ptg-victoria-ci-updates [13] https://review.opendev.org/#/q/topic:ipv6-support+(status:open+OR+status:me… [14] https://openstack-virtual-baremetal.readthedocs.io/en/latest/deploy/quintup… [15] https://etherpad.opendev.org/p/tripleo-ipv6-and-routed-networks-in-upstream… [16] https://etherpad.opendev.org/p/tripleo-enable-net-iso-by-default [17] https://etherpad.opendev.org/p/tripleo-validations-future [18] https://docs.google.com/presentation/d/1l2RzL-hJ-fT9jzi2A7s8ladEumOvy8tDy7D… [19] https://etherpad.opendev.org/p/tripleo-container-image-tooling-victoria [20] https://etherpad.opendev.org/p/tripleo-ceph [21] https://etherpad.opendev.org/p/tripleo-heat-swift-removal-undercloud [22] https://etherpad.opendev.org/p/tripleo-ptg-victoria-better-db-sync Wednesday June 3rd Speeding up deployments, updates and upgrades by Jesse Pretorius Jesse had quite a few suggestions and proposals on how we may speed up updates and upgrades. Some of the highlights were building on top of Alex’s ansible strategy improvements and avoiding skipped tasks, avoiding unnecessary reboots etc. There was a lot discussed, please refer to the etherpad for details [23]. Thank you Jesse! Running validations from within a container by Cedric Jeanneret Cedric continued to walk us through the very near future of validations. Cedric wanted to discuss the delivery of validations and the implications of using a container to host the validations. Older non-containerized versions of TripleO were discussed, using an ansible collection and a container were discussed. There are multiple use cases for validations leading the group to not consolidate on a single delivery mechanism. More discussion was needed at the end of this topic. Notes are here [24]. Thanks Cedric! Auto --limit scale-up of Compute nodes by Luke Short Luke walked us through his auto scale up spec [25] in the following presentation [26]. Essentially this is customizing the scale up process to better match the ansible configuration for forked processes to make the scale up quicker. Luke was able to perform a 10 node scale up in 20 minutes. Nice presentation Luke! TripleO usability enhancements: by Wes Hayutin Initially there was not a lot of suggestions in this topic prior to PTG, however once we got started with usability improvements they started to roll in. Definitely check the etherpad [27], but I’ll list some here. - Fix “FAILED - RETRYING in stack status” - fixed already in https://review.opendev.org/#/c/725665/ - Network-Isolation user experience - linked back to Harold’s topic - Chem raised a number of update / upgrade improvements on line 25 [27] - Eliminate the need for customers to remove deprecated services from roles_data in upgrades - Improved logging - Block commands that require a previous actions - Prompt user prior to dangerous actions - Keep simplifying, e.g.’s Rabi’s proposals. Check the etherpad for more details [27] Improvements in TLS Everywhere/ CI Presenter by Ronelle Landy, Ade Lee At the last PTG in Shanghai Ade and I proposed a job that would setup IPA and a Standalone deployment of TripleO and configure it to work together upstream to check and GATE changes to TLS. I’m happy to report that Ade and Ronelle got the job done!! The presentation is available here [29]. This should go a very long way to help prevent TLS related bugs across upstream and internal testing. Thanks Ade, Thanks Ronelle! [23] https://etherpad.opendev.org/p/tripleo-ptg-victoria-speedups [24] https://etherpad.opendev.org/p/tripleo-validation-container [25] https://review.opendev.org/#/c/727768/1/specs/victoria/auto_scale_up_comput… [26] https://drive.google.com/file/d/1c2D67QZ5UGBYRONogZJKMief5wJxQAIt/view [27] https://etherpad.opendev.org/p/tripleo-usability-enhancements [28] https://etherpad.opendev.org/p/tripleo-tls-everywhere-ci [29] https://docs.google.com/presentation/d/1gruDzHIjZtPtUUYSRGIrJynTOt9bZP3W7TL… Thursday June 4th Config-download 2.0 by Luke Short Luke walked us through a proposal to build on config download and what steps could be taken further simplify the deployment using Ansible. Using idempotent tasks, static playbooks etc. The source of truth with regards customer environments was a tough nut to crack here and it was difficult to see a very clear and backwards compatible method to approach this. Notes are available here [30] Ansible logging within tripleoclient by Cedric Jeanneret Cedric proposed improvements to TripleO logging here [31]. Cedric walked the group through the spec. Logging is certainly an area we all want to see improvement on and we all have opinions about so this was a lively conversation. Cedric pointed out there are two main types of steps we need to go after which is any ansible task, and any tripleo cli command called need to be logged together in a human readable way. Very good points made and the conversation will continue in the TripleO spec. [31]. Thanks Cedric! Transitioning the underlying CentOS/RHEL - how can we improve this process? By Jesse Jesse spoke to the challenges facing upgrades with regards to the mix of host RHEL versions in a deployment. Several finer points were made with nuances of the upgrade with regards to HA, pacemaker, libvirt and ironic versions. It was a good troubleshooting session and a thoughtful dialogue with the group. Read the details here [33] Thanks Jesse! VxFlexOS integration within TripleO by Jean Pierre Roquesalane/Rajini Karthik The Tripleo team answered questions and walked the Dell team through the best practices with integrating a 3rd party service with TripleO. Details are here [34] TripleO CI - audit coverage for neutron, ovn, ovs, octavia by Brent Eagles, Slawek Kaplonski, Wes Hayutin This session was about reemphasizing the importance of the network scenarios and workflows that are critical to TripleO’s success in the field. Over the past year or so Brent and others have done a great job in adding additional upstream coverage but it’s now time to make sure this is everyone’s job as well. We discussed the challenges with upstream jobs, the neutron project and TripleO. We also spec’d out some idea on where to build on top of Brent and Slawek successes to reach greater upstream coverage of critical network features and workflows. Notes are available [35]. Really appreciate Brent and Slawek making time to attend, thank you!! tripleo-validations package future by Cedric Jeanneret Last but not least Cedric led a discussion on packaging for validations and how we can align responsibility of validations with rpms, git repos and CI. We spoke to how the packaging is related to the component pipeline. Designing this carefully so that the validation’s team and other projects can work together and independently with clear lines. Good stuff here, details [36] Thanks Cedric! openstack tripleo deploy (standalone) for multinode by James Slagle Please read through the blueprint and specs proposed by James with regards to utilizing the standalone deployment for multinode overcloud deployments. [37] Thanks James [30] https://etherpad.opendev.org/p/tripleo-ptg-victoria-config-download-two [31] https://review.opendev.org/#/c/733652/1/specs/victoria/ansible-logging-trip… [32] https://etherpad.opendev.org/p/tripleo-ptg-victoria-ansible-logging [33] https://etherpad.opendev.org/p/tripleo-ptg-victoria-distro-transition [34] https://etherpad.opendev.org/p/tripleo-ptg-victororia-VxFlexOS [35 https://etherpad.opendev.org/p/tripleo-network-coverage-audit [36] https://etherpad.opendev.org/p/tripleo-validations-future [37 https://etherpad.opendev.org/p/tripleo-ptg-tripleo-deploy Did you make it? Special thank you sincerely ( I know I never sound sincere ) to both Emilien and Alex throughout the cycle in helping me with my PTL responsibilities!! See you next PTG :)

1 0

[openstack-helm] Abandoning old patchsets
by Gage Hugo 09 Jun '20

09 Jun '20

Hello everyone. >From our discussions during the PTG and past meetings, it was brought up about openstack-helm's large number of old patchsets that are still active and have not been updated in a long time, some are several years old. Over the next few days we will be going through these changes and working to abandon anything that is older than 6-12 months, depending on any context if available. If anyone has a change they are still interested in and would like to pick back up, if it gets abandoned, please feel free to restore it and let us know that you intend to continue working on it.

1 0

OpenStack Glossary
by helena＠openstack.org 09 Jun '20

09 Jun '20

Greetings OpenStack Community! We are on a mission to create a glossary of OpenStack related terms and want your help! As the community grows and new contributors want to get involved, we hope to have a consistent definition to help familiarize them with the project. Similarly, having a glossary of terms has proven to be a good SEO tactic to gain more web traffic; by creating this glossary, we are hoping to have greater visibility to potential contributors, users, and supporting organizations. This is where you come in! We need your help to define the terms that we can use to educate future contributors. Below is an etherpad link. We ask that you add, edit, review, and collaborate on this etherpad to help us make the OpenStack community more accessible and understandable. If you think of more terms to add to the list, please do! As always, feel free to reach out with any questions. Cheers, Helena Spease OpenStack: [ https://etherpad.opendev.org/p/OpenStack_Glossary ]( https://etherpad.opendev.org/p/OpenStack_Glossary )

3 3

[ubuntu] Known that qemu 4.2 is incompatible with GCP instances?
by Neil Jerram 09 Jun '20

09 Jun '20

I run tests with GCP instances as the OpenStack hypervisors. Obviously it's better if those can use libvirt_type kvm, i.e. nested virtualization, and this has been possible prior to my current Ussuri upgrade work. With Ussuri on Ubuntu, IIUC, we get qemu 4.2 from cloud-archive:ussuri, but qemu 4.2 has a bug that was fixed by this commit prior to 5.0.0: https://github.com/qemu/qemu/commit/4a910e1f6ab4155ec8b24c49b2585cc486916985 target/i386: do not set unsupported VMX secondary execution controls Commit 048c951 ("target/i386: work around KVM_GET_MSRS bug for secondary execution controls") added a workaround for KVM pre-dating commit 6defc591846d ("KVM: nVMX: include conditional controls in /dev/kvm KVM_GET_MSRS") which wasn't setting certain available controls. The workaround uses generic CPUID feature bits to set missing VMX controls. [...] The bug manifests on a GCP instance with nested virtualization enabled [1], because such a GCP instance doesn't support MSR features. The OpenStack-level symptom is that a VM can't be scheduled onto that GCP instance. Is this a well-known problem? For CentOS/RHEL, [2] looks similar and maybe fixed, but it's difficult to be sure. Best wishes, Neil [1] https://cloud.google.com/compute/docs/instances/enable-nested-virtualizatio… [2] https://bugzilla.redhat.com/show_bug.cgi?id=1722360

2 3

[openstack-helm] No IRC Meeting Today 06/09
by Gage Hugo 09 Jun '20

09 Jun '20

Today's weekly IRC meeting will be cancelled since we just recently discussed topics during last week's PTG. We will continue as scheduled next week.

1 0

[qa] Virtual PTG Wrap-up and office hour was changed to Tue 1300 UTC
by Masayuki Igawa 09 Jun '20

09 Jun '20

Hi, Thank you for attending our sessions! We discussed many things during virtual PTG. Topics are the following. And as we discussed our office hour office time 30 minutes earlier than the current time. So, the office hour will start in 2 hours today. ========= Topics: Mon: @ bexar 13:00-13:30 Ussuri Retrospective (gmann) 13:30-14:00 Make tempest scenario manager a stable interface (kopecmartin/soniya) 14:00-14:30 tempest cleanup (kopecmartin) 14:30-15:00 Gates optimization by a better test schedulling (kopecmartin) Tue: @grizzly 13:00-13:30 Description for testcases as docstrings (kopecmartin) 13:30-14:00 Feature Freeze idea for new tests in Tempest and Patrole and other QA projects (gmann) 14:00-14:15 How to handle the tox.ini constarint for each Tempest new tag (gmann) 14:15-14:30 Migrating hacking checks from other projects to hacking itself(paras333) 14:30-15:00 Victoria Priority & Planning (30min) (masayukig) https://etherpad.opendev.org/p/qa-victoria-priority Etherpad: https://etherpad.opendev.org/p/qa-victoria-ptg You can find the recording video files on the etherpad. However, Monday's recording was disappeared somewhere in the cloud.. :( ========= -- Masayuki Igawa

1 0

[neutron] Drivers meeting on Friday 12.06.2020 cancelled
by Slawek Kaplonski 08 Jun '20

08 Jun '20

Hi Due to my day off this Friday I will not be able to attend and chair our drivers meeting. I know that also at least 2 other members of the drivers team will not be available this week so lets cancel this meeting and lets get back to it next week. Have a great week and see You all next week :) -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] CI meeting on Wednesday 10.06.2020 cancelled
by Slawek Kaplonski 08 Jun '20

08 Jun '20

Hi, I need to cancel tomorrows CI meeting due to conflicting internal meeting which I have. I will check our CI status and will ping You on IRC if there will be any need. See You on the meeting next week. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][InteropWG] Tuesday June 9, UTC 17 - Meeting Reminder to review OpenStack Powered Logo Guidelines and your feedback
by prakash RAMCHANDRAN 08 Jun '20

08 Jun '20

InteropWG is inviting you to a scheduled Zoom meeting Tuesday June 9th,10-10.45 AM PDT / 13-13.45 EDT / 17-17.45 UTC,Join from a browser: https://Dell.zoom.us/wc/join/99829924353 , Password: 101045 , orJoin Zoom Meeting: https://Dell.zoom.us/j/99829924353?pwd=bU9NTkZQVkd3SmIrVGErZWFGVnlmUT09 , and in paralle on irc ,irc: #openstack-interopwg or #openstack , For background review - 1. https://www.slideshare.net/markvoelker/interopwg-intro-vertical-programs-ja… , 2. https://opendev.org/openstack/interop/src/branch/master/2020.06.json , 3. https://etherpad.opendev.org/p/victoria-ptg-interop-wg , Agenda: 1. Agenda Bashing2. Presentation for comments on Ussuri Interop Draft Guidelines (Need - Verbage and logo for adding OpenStack Powered DNS & Orchetsration - -https://www.openstack.org/brand/interop/) Review Project APIs for Interop Ussuri cycle a. keystone , b. glance , c. nova , d. neutron , e. cinder , f. swift , g. designate (OpenStack powered DNS logo?) , h. heat (OpenStack powered Orchestrator Logo?) . 3. Feed back by contributors and any other PTG or representatiive from community 4. Conclusion by Mark Voelker for Ussuri Draft - Vice Chair (Market Place, logo, irc, conference-bridge, issues in refstack-client, tempest features,...) 5. Approval verbal or irc vote in Interop WG for Draft to Board for Thursday June 11 schedule - https://wiki.openstack.org/wiki/Governance/Foundation/11June2020BoardMeeting Finally Any suggestions for Victoria cycle to explore 1. Ironic or Bare metal (Open Infrastructure Powered Logo?)2. NFV (tacker? NFVi &/or VNF/CNF APIs?) (OpenStack NFV Logo?)3. Ideas needed for Heterogeneus Cloud compliance (suggest use cases) (OpenStack Compatible Hybrid Cloud Logo?) ThanksPrakash : Chair InteropWGMark : Vice Chair : Interop WG

1 0

[tripleo] no irc meeting tomorrow
by Wesley Hayutin 08 Jun '20

08 Jun '20

Greetings, As discussed at the PTG, there will only be one TripleO irc meeting every three weeks. I'll update the docs and schedule to reflect that. Thanks

1 0

[oslo] Ping List for Victoria
by Ben Nemec 08 Jun '20

08 Jun '20

Hi, With the start of a new cycle, we refresh our courtesy ping list for the start of the meeting. We do this to avoid spamming people who may no longer be working on Oslo but haven't explicitly removed their name from the ping list. To that end, I've added a new ping list above the agenda template[0]. If you wish to continue receiving courtesy pings, please add your name there. In a couple of weeks we will switch to using this new list. Thanks. -Ben 0: https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template

1 1

[keystone] No meeting June 9th
by Nikolla, Kristi 08 Jun '20

08 Jun '20

Hi all, Since we met during the PTG on Thu-Fri, I don't think it's necessary to have the weekly meeting this Tuesday on June 9th. Have 1 hour back :) Best, Kristi

1 0

OSF Community Meeting - June 25 & 26
by Allison Price 08 Jun '20

08 Jun '20

Hi everyone, On June 25 (1300 UTC) and June 26 (0200 UTC) , we will be holding the quarterly OSF community [1] that will cover project updates from all OSF-supported projects and events. The OpenStack community is encouraged to prepare a slide and present a 3-5 minute update on the project and community’s progress. The update should cover updates that have occurred since the last community meeting on April 2. If you would like to volunteer to present the OpenStack update for one meeting (or both!) please sign up here [1]. We are aiming to finalize the content by Friday, June 19. If you missed the Q1 community meeting, you can see how the upcoming meeting will be structured in this recording [2] and this slide deck [3]. If you have any questions, please let me know. Thanks! Allison [1] https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2 <https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2> [2] https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb… <https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb…> [3] https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY… <https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY…>

1 0

[all][PTG] Feedback Etherpad
by Kendall Nelson 08 Jun '20

08 Jun '20

Hello Everyone! Thanks to everyone who made the first ever virtual PTG a success! Instead of doing a live feedback session, we are asking you to share your experiences with us in a feedback etherpad! We started circulating it even before the PTG, but wanted to make sure you all saw it and had a chance to voice your feedback. We really appreciate it! -the Kendalls (diablo_rojo & wendallkaters) [1] https://etherpad.opendev.org/p/June2020-PTG-Feedback

1 0

[baremetal-sig][ironic] Baremetal whitepaper: the final chapter
by Arne Wiebalck 08 Jun '20

08 Jun '20

Dear all, The bare metal white paper [0] is almost finished, thanks to everyone who helped during the past weeks! We plan to have a (hopefully final) session to address the remaining open issues and to round things off during one of slots proposed in the doodle available at https://doodle.com/poll/afwgy9zs8fi55wqe Everyone is still welcome to give input or feedback. Like before, I will send out the call details once we have settled on the time slot. Cheers, Arne [0] https://docs.google.com/document/d/1BmB2JL_oG3lWXId_NXT9KWcBJjqgtnbmixIcNsf… -- Arne Wiebalck CERN IT

1 1

[swift, interop] Swift API level changes to reflect in Interop
by Arkady.Kanevsky＠dell.com 08 Jun '20

08 Jun '20

As we create new guidelines for Interop, We need to see what changes needed for object storage guidelines. So a few specific questions for Swift team: 1. What new Tempest tests added for Ussuri release? a. APIs for query and accessing older versions? Is it for S3 APIs or for swift API also? b. Any new or modified Tempest test for Etags? c. Any SIGUSR1 test coverage? d. New tempest tests for swift-ring-builder? 2. What are tempest tests deprecated for Ussuri release? a. Any tempest tests removed for auto_create_account_prefix? Any other API test coverage tests missed above? Thanks, Arkady

3 6

[tc] weekly update
by Mohammed Naser 08 Jun '20

08 Jun '20

Hi everyone, Here’s an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # CHANGES PENDING - Select migrate-to-focal goal for Victoria cycle: https://review.opendev.org/#/c/731213/ - Propose Kendall Nelson for vice-chair: https://review.opendev.org/#/c/733141/ - Clarify the support for linux distro: https://review.opendev.org/#/c/727238/ - Add njohnston liaison preference: https://review.opendev.org/#/c/733269/ - Update joining-tc.rst to be general tc-guide.rst: https://review.opendev.org/#/c/732983/ - Remove tricircle project team: https://review.opendev.org/#/c/731566/ - Add diablo_rojo liaison preferences: https://review.opendev.org/#/c/733284/ - Rename ansible-role-lunasa-hsm deliverable: https://review.opendev.org/#/c/731313/ - Merging TC and UC into a single body: https://review.opendev.org/#/c/734074/ - Retire swift-specs: https://review.opendev.org/#/c/733901/ # RETIRED PROJECTS - Remove congress project team: https://review.opendev.org/#/c/728818/ # GENERAL CHANGES - Switch to newer openstackdocstheme version: https://review.opendev.org/#/c/733313/ Thanks! Regards, -- Mohammed Naser VEXXHOST, Inc.

1 0

[cinder][kayobe][kolla][OSA][tripleo] Ussuri cycle-trailing release deadline
by Sean McGinnis 08 Jun '20

08 Jun '20

Hello teams with deliverables following the cycle-trailing release model! This is just a reminder about wrapping those Ussuri trailing deliverables up. A few cycles ago we extended the deadline for cycle-trailing to give more time, so the actual deadline isn't until August 13: https://releases.openstack.org/victoria/schedule.html#v-cycle-trail If things are ready sooner than that though, all the better for our downstream consumers. Just for awareness, the following cycle-trailing deliverables will need their final releases at some point in the next few months: cinderlib kayobe kolla-ansible kolla-cli kolla openstack-ansible os-refresh-config Thanks! Sean

1 0

[nova] Runway for Victoria
by Balázs Gibizer 08 Jun '20

08 Jun '20

Hi, Runway etherpad [1] with 3 slots and and empty queue is open for Victoria. Cheers, gibi [1] https://etherpad.opendev.org/p/nova-runways-victoria

1 0

[doc] installation guide maintenance
by Akihiro Motoki 08 Jun '20

08 Jun '20

Hi, During the doc migration, the installation guide was moved to individual project repos. I see problems in installation guide maintenance after the migration. - The installation guide is not maintained well perhaps in many projects. AFAIK they are not verified well at least in horizon and neutron. - Even if we try to verify it, it is a tough thing because we need to prepare base distribution and setup other projects together (of course it depends on projects). This leads to a development bandwidth and priority issue. - We sometimes receive bug reports on the installation guide, but it is not easy for the upstream team confirm them and verify fixes. I guess the installation guides are not being maintained well from these reasons. Any thoughts on this situation? (This is my first question.) If a project team has no bandwidth to maintain it, what is a recommended way? I see several options: - Drop the installation guide (per OS or as a whole) -- If drop what should the criteria be? - Keep the installation guide with warnings like "the upstream team does not maintain it and just host it". - Keep it as-is (unmaintained) Finally, I am not sure we need to maintain step-by-step guides on installations and I wonder we need to drop them at some time. Most users deploy OpenStack using deployment projects (or their own deployment tools). Step-by-step guides might be useful from educational perspective but unmaintained guides are not useful. Thanks in advance, -- Akihiro Motoki (amotoki)

5 7

[neutron] Neutron Bug Deputy Report Jun 1-8
by Lucas Alvares Gomes 08 Jun '20

08 Jun '20

Hi, This is the Neutron bug report of week 23 (1 Jun - 8 Jun). Untriaged: - "Inconsistent coding while upgrading" * https://bugs.launchpad.net/neutron/+bug/1881685 - "Centralized SNAT failover does not recover until "systemctl restart neutron-l3-agent" on transferred node" * https://bugs.launchpad.net/neutron/+bug/1881995 - "Quality of Service (QoS) in neutron" * https://bugs.launchpad.net/neutron/+bug/1882072 Critical: - "[OVN]IPv6 hot plug tempest tests are failing with OVN backend" * https://bugs.launchpad.net/neutron/+bug/1881558 - "Neutron-vpnaas scenario tests are very unstable" * https://bugs.launchpad.net/neutron/+bug/1882220 High: - "[OVN] Virtual port type set while port has no parents" * https://bugs.launchpad.net/neutron/+bug/1881759 * Fix released * Assigned to Maciej Jozefczyk * Patch proposed: https://review.opendev.org/732690 - "neutron-ipset-cleanup fails with Traceback: Unhandled error: oslo_config.cfg.NoSuchOptError: no such option AGENT in group [DEFAULT]" * https://bugs.launchpad.net/neutron/+bug/1881771 * Fix released * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/732701 - "neutron-ovn-db-sync-util fails with KeyError: 'port_security_enabled' when port security not enabled" * https://bugs.launchpad.net/neutron/+bug/1882061 * In-Progress * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/733512 - "neutron-ovn-db-sync-util stops with Traceback due to L3 service plugin expecting ``ovn`` mech driver to be present while ``ovn-sync`` mech driver is loaded" * https://bugs.launchpad.net/neutron/+bug/1882202 * In-Progress * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/733775 Medium: - "neutron-ovn-db-sync-util fails with Traceback when notify_nova config is present" * https://bugs.launchpad.net/neutron/+bug/1882020 * Fix released * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/733481 Invalid: - "Neutron CI doesn't run tests that require advanced image" * https://bugs.launchpad.net/neutron/+bug/1882060

1 0

Re：[cyborg][ptg] Cyborg PTG Summary for the Day — Come in series
by yumeng bao 07 Jun '20

07 Jun '20

Hi all, All topics for cyborg PTG are done! Notes and comments are on the etherpad. Thank you all for the great topics, participation, discussion etc! Topics that have come to an conclusion are marked with [AGREE] or [ACTION], while topics that need further discussion are not. listed below are important topics that need further discussion either in the format of future meeting or maillist or a spec: 1. 3rd party CI support for new drivers * define which tempest tests need to be used in 3rd party CI. * 2. cyborg/neutron/nova sriov intigration * a spec in nova will be proposed to continue discussion If you have any feedbacks please reply here or in IRC. Regards, Yumeng

1 0

[puppet] puppet-openstack meeting
by Thomas Goirand 07 Jun '20

07 Jun '20

Hi guys! Wouldn't it be nice to organize some meet-up online, for example using the jitsi instance that the infra team built? I at least would enjoy a lot seeing you face-to-face (ie: Tobias, Takashi, Zheng, as I know already Emilien and Alex). Moreover, it'd be nice to discuss the plans for Victoria. Your thoughts? Cheers, Thomas Goirand (zigo)

1 0

[all][InteropWG] Last call for interop capabilities from OpenStack partciapting projects
by prakash RAMCHANDRAN 06 Jun '20

06 Jun '20

Hi all, We are happy to report that score of people turned up for Interop WG discussions on First call on Monday June1st.Friday 5th June we had a review call to consolidate and follow up on guidelines for the OpenStack Powered Trademark Program. https://etherpad.opendev.org/p/victoria-ptg-interop-wghttps://etherpad.open… Please note the terminology -https://github.com/openstack/interop/blob/master/doc/source/schema/2.0.rst#capabilities capabilities - required, advisory, deprecated, removed Stein Train /add Ussuri/delete Victoria KeystoneGlanceSwift Nova NA (Ironic BM) Neutron Cinder v2 Add-ons OpenStack Powered - Orchestration & DNSHeatDesignate Based on current review there are no net new APIs to be added to Ussuri cycle with respect to Stein that are eligible for Interop Programs.The above project teams can go through codeRefStack server guidelines page RefStack Client. Artem Goncharov (irc: gtema) - ANswers to Questions by Artem and follow up actions - refstack-client seems to be orphaned now and offered changes are not reviewed (gtema) - There is access failure and is being addressed by Mark, after that we will review this with help of gtema to file a ticket with bug details - link between guideline and required tempest is desired, since it requires currently effors to nail down failures by jumping between tempest versions (gtema) - This a feature add request, need a story or bug to aggressed in Tempest by gtema - network extensions api - does it make sense to include it? - Note any L2/L3 CRUD on network, subnet and ports and all their attributes are covered. The plug-ins and admin user requirements for extensions are out of scope and hence not considered. However you may verify with Neutron team as what is their proposal to this team? - resource tagging apis - does it make sense to include them? - Reosurce taggin again are optional attirbutes to reousrce ID and very speicifc to resource under trait libraray or ad-hoc to Vendor specific plugins and drivers and will not qualify for interoperability. You can still ask if any new resources that are used by any of core projects to propose and justify why tha'ts required for interop testing? Attached the current diff's for both 2020.06.json vs 2019.11.json and similar diff's for add-ons for Orchstration and DNS. Seeking volunteers to update web page write-up and logos to be proposed for "Openstack Powerd Orchestaion" & Openstack Powered DNS". Heat ans Designate teams can suggest what they would like to bring to table for draft and approval to board? ThanksPrakash

1 0

[nova][libvirt] Support for MIPS architecture?
by 赵晓琳 06 Jun '20

06 Jun '20

Hi I'm trying to run openstack on a host with MIPS architecture, but got some errors, and I have fixed them. Many people around me use hosts with MIPS architecture. We hope the official can add support for MIPS and we can maintain it. Thanks, xiaolin

4 5

[all][InteropWG] Please verify if Swift Project needs any updates for Interop testing of user APIs
by prakash RAMCHANDRAN 05 Jun '20

05 Jun '20

Hi Swift team core members, We are trying to run our ambassadors or volunteers to your meetings, but if we miss please reply with "Confirmed OK" to submit these draft to be merged for "OpenStack Powered Storage" approval. Please bring this to your PTG meetings if needed to assign a volunteer to complete the verification and patch if updates are needed. Swift: We test 20 capability with 60 tests -do you need any changes to 2020.06.json swift api draft before seeking approvals?https://docs.openstack.org/api-ref/object-store/ https://opendev.org/openstack/interop/src/branch/master/2020.06.json#L179Ch… Line 179-214 and confim that tests is capability tests 1-20 will suffcie or submit patch to inerop. - identity-v3-tokens-create [1/1] - identity-v3-tokens-delete [1/1] - objectstore-account-list [12/12] - objectstore-account-quotas [2/2] - objectstore-container-acl [2/2] - objectstore-container-create [2/2] - objectstore-container-delete [1/1] - objectstore-container-list [11/11] - objectstore-container-metadata [5/5] - objectstore-container-quotas [3/3] - objectstore-dlo-support [2/2] - objectstore-info-request [1/1] - objectstore-object-copy [4/4] - objectstore-object-create [2/2] - objectstore-object-delete [1/1] - objectstore-object-get [3/3] - objectstore-object-versioned [1/1] - objectstore-slo-support [4/4] - objectstore-temp-url-get [1/1] - objectstore-temp-url-put [1/1] ThanksInterop WG chai Prakash& Vice chair Mark

2 1

[kolla-ansible] Proposing Doug Szumski as Kolla Ansible core
by Radosław Piliszek 05 Jun '20

05 Jun '20

Hi Folks! This mail serves to propose Doug Szumski from StackHPC (dougsz @IRC, CC'ed) as Kolla Ansible core. Doug coauthored the Nova cells support and helps greatly with monitoring and logging facilities available in Kolla. Please give your feedback in this thread. If there are no objections, I will add Doug after a week from now (that is roughly when PTG is over). -yoctozepto

9 9

Networking-vpp 20.05 for VPP 20.05 is now available
by Naveen Joy (najoy) 05 Jun '20

05 Jun '20

Hello All, We'd like to invite you to try out Networking-vpp 20.05. As many of you may already know, VPP is a fast user space forwarder based on the DPDK toolkit. VPP uses vector packet processing algorithms to minimize the CPU time spent on each packet to maximize throughput. Networking-vpp is a ML2 mechanism driver that controls VPP on your control and compute hosts to provide fast L2 forwarding under Neutron. This latest version of Networking-vpp is updated to work with VPP 20.05. In this release, we've made the below changes: - We've added a class that defines network type APIs and implements them. The network types supported are VLAN, Flat and GPE. Our intent is to add support for pluggable network types without the need to modify code. We'll be continuing our work to enhance this feature in the next release. - We've updated the code to be compatible with VPP 20.05 API changes. - We've added code to deal with poorly formed security group subnets. For instance, 1.2.3.4/0 is completely acceptable in a security group rule. Previously, VPP accepted this in its API calls but this is not currently the case. We've fixed this up at the high level to be acceptable to VPP. - We've fixed an issue with missing package data required for VPP API message validation. - We've dropped VPP 19.04 compatibility code. - We've fixed an issue with the security group mechdriver code in which a SG rule is added but not pushed out to VPP until the next rule is added or the security group is changed. - We've moved VPP specific constants to a dedicated vpp_constants.py file. - Due to a VPP issue, GPE support will be deferred to the 20.05.1 release. - We've been doing the usual round of bug fixes, clean-ups and updates - the code will work with VPP 20.05, the OpenStack Stein release & Python 3. The README [1] explains how you can try out VPP with Networking-vpp using devstack: the devstack plugin will deploy the mechanism driver with VPP 20.05 and should give you a working system with a minimum of hassle. We will be continuing our development for VPP's 20.05.1 release. We welcome anyone who would like to come help us. -- Jerome, Ian & Naveen [1] https://opendev.org/x/networking-vpp/src/branch/master/README.rst

1 0

[openstack-ansible] PTG results
by Dmitriy Rabotyagov 05 Jun '20

05 Jun '20

Hi there, Sorry for the previous email - it has been sent accidentally - it was just at the draft stage... I did some formating afterwards:) Here are some of the decisions we come up with during the PTG week: * CentOS 8 topic. ** Install systemd-extras to get systemd-networkd ** Launch without LXC build at first because of the complexity of the solution. To implement LXC we would need the following: *** Replace what `machinectl` does with Ansible tasks, as it's not working properly without btrfs *** See how much it costs to implement lxd - that would not only resolve Centos 8 issue, but also is pretty appreciated among comunity. However, installing in with snapd will auto-update. it's possible to delay up to 60 days the updates but still needs to fix/clean ** Make nspawn unmaintained, because it mostly relies on machinectl. *** Remove nspawn from docs. *** Remove code in cycle afterwards. ** Backport CentOS 8 to Ussuri, drop CentOS 7 for Victoria afterwards. *** On Ussuri CentOS 7 is going to live without distro support *** write reno, that explains that distro installed OSA upgrade path might be tricky/broken for CentOS because of absent Centos7 packages for U. * Logs topic ** finish transition to journald *** check heat for logging *** check for ceph logs - see [1] but this may be a result of the way cephadm containerises all the ceph daemons ** Rewrite log collection script on python with systemd python bindings and get deprecated messages from services' journal into separate file ** Check where we don't use uwsgi role and see if we can use it there now (like designate) ** Check through the logs what roles are we covered with tempest, and what not. We have buch of roles that run tempest, but test like only keystone (but not itself). ** We add libvirtd_exporter [2] to ansible-role-requirements and offer it's deployments on users own prometheus. Offer prometheus deployment as step2. Document usage * Promote ELK stack to 1st class thing ** Create a separate repo and remove from openstack-ansible-ops ** provide out-of-the-box deployment with OSA. Model would be similar to ceph-ansible where deployment can be integrated or standalone * Work on speeding up OSA runtime: ** Fight with skipped tasks (ie by moving them to separate files that would be included) - most valid for systemd service, systemd_networkd and python_venv_build roles ** Try to split up variables by group_vars ** Try to use include instead of imports again * speedup ci ** try to speedup zuul required projects clone process - work with infra team ** Set *_db_setup_host across all roles to utility and adjust [7] * Build mariadb deps for focal (like 10.4.12 release). We can use repo.vexxhost.net for hosting it until mariadb 10.4.14 release. * In case having issues with distro jobs/support we don't hestitate remove it or setting to non-voting state * Remove SUSE support early in Victoria. We already have [4] for this - needs rebasing * Add neutron ovn to integrated tests (with perspective to make it default for new deployments). * Drop resource creation tasks out of os_tempest - OSA and TripleO manage resource creation themselves and pass required vars to os_tempest for config generation * Add support for zookeeper deployment for services coordination (like telemetry, designate, etc) * add tooling to bootstrap-ansible to apply provided gerrit patches for roles - start with this [3] * Try to add aarch64 jobs with separate pipeline once we have some python wheels built up * Migrate group names to remove underscores "The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10" * add tooling to bootstrap-ansible to apply provided gerrit patches for roles - start with this [5] use it like this [6] * publish common roles (galera, haproxy, memcached, uwsgi, python_venv_build, etc...) to galaxy, rename them to ansible-role-* pattern. As a stage 2 consider publishing os roles. * add some check for repo server, to verify it's ok (lua linters check) instead of failing afterwards because of missing dev libraries for hosts [1] https://github.com/ceph/ceph/blob/be117b555fc1bba1048b87a624d542fd629d1ad1/… [2] https://github.com/jrosser/rd-ansible-libvirtd-exporter [3] http://paste.openstack.org/show/794258/ [4] https://review.opendev.org/#/c/725541/ [5] http://paste.openstack.org/show/794258/ [6] http://paste.openstack.org/show/794259/ [7] https://review.opendev.org/#/c/671454

1 1

[nova] running nova-scheduler in a container
by Jean-Philippe Méthot 05 Jun '20

05 Jun '20

Hi, I’ve been building my own docker images as a mean to both learn docker and to see if we can make our own images and run them in production. I’ve figured out how to make most services run fairly well. However, an issue remains with nova-scheduler and I can’t seem to figure out what’s going on. Essentially, when I try to create a VM it loops in a scheduling state and when I try to delete a VM, it loops forever in a deleting state. I’ve narrowed down the culprit to nova-scheduler. As far as I know, nothing appears in the debug logs of my containerized nova-scheduler whenever I do any kind of action, which forces me to believe that nova-scheduler is not receiving any command. From what I’ve always understood, nova-scheduler works through RPC and Rabbitmq. The fact that this nova-scheduler connects to rabbitmq without issue makes me believe that something else is missing from my container configuration. Does Nova-scheduler listen on network port? Does it listen on a socket? Is there any way that nova-scheduler could ignore requests sent to it? Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc.

2 2

[openstack-ansible] PTG results
by Dmitriy Rabotyagov 05 Jun '20

05 Jun '20

1 0

[nova][ptg] virtual PTG
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, I need to book slots for nova discussions on the official schedule[2] of the virtual PTG[1]. I need two things to do that: 1) What topics we have that needs real-time discussion. Please add those to the etherpad [3] 2) Who wants to join such real-time discussion and what time slots works for you. Please fill the doodle[4] Based on the current etherpad content we need 2-3 slots for nova discussion and a half slot for cross project (current neutron) discussion. Please try to provide your topics and options before the Thursday's nova meeting. Cheers, gibi [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://ethercalc.openstack.org/126u8ek25noy [3] https://etherpad.opendev.org/p/nova-victoria-ptg [4] https://doodle.com/poll/ermn3vxy9v53aayy

1 5

[nova][neutron][ptg] How to increase the minimum bandwidth guarantee of a running instance
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] As a next step in the minimum bandwidth QoS support I would like to solve the use case where a running instance has some ports with minimum bandwidth but then user wants to change (e.g. increase) the minimum bandwidth used by the instance. I see two generic ways to solve the use case: Option A - interface attach --------------------------- Attach a new port with minimum bandwidth to the instance to increase the instance's overall bandwidth guarantee. This only impacts Nova's interface attach code path: 1) The interface attach code path needs to read the port's resource request 2) Call Placement GET /allocation_candidates?in_tree=<compute RP of the instance> 3a) If placement returns candidates then select one and modify the current allocation of the instance accordingly and continue the existing interface attach code path. 3b) If placement returns no candidates then there is no free resource left on the instance's current host to resize the allocation locally. Option B - QoS rule update -------------------------- Allow changing the minimum bandwidth guarantee of a port that is already bound to the instance. Today Neutron rejects such QoS rule update. If we want to support such update then: * either Neutron should call placement allocation_candidates API and the update the instance's allocation. Similarly what Nova does in Option A. * or Neutron should tell Nova that the resource request of the port has been changed and then Nova needs to call Placement and update instance's allocation. The Option A and Option B are not mutually exclusive but still I would like to see what is the preference of the community. Which direction should we move forward? Both options have the limitation that if the instance's current host does not have enough free resources for the requested change then Nova will not do a full scheduling and move the instance to another host where resource is available. This seems a hard problem to me. Do you have any idea how can we remove / ease this limitation without boiling the ocean? For example: Does it make sense to implement a bandwidth weigher in the scheduler so instances can be spread by free bandwidth during creation? Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg

3 6

[nova][neutron][ptg] Future of the routed network support
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] There is only basic scheduling support in nova for the neutron routed networks feature (server create with port.ip_allocation=deferred seems to work). There was multiple attempts in the past to complete the support (e.g.server create with port.ip_allocation=immediate or server move operations). The latest attempt started by Matt couple of cycles ago, and in the last cycle I tried to push that forward[1]. When I added this topic to the PTG etherpad I thought I will have time in the Victoria cycle to continue [1] but internal priorities has changed. So finishing this feature needs some developers. If there are volunteers for Victoria then please let me know and then we can keep this as a topic for the PTG but otherwise I will remove it from the schedule. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/q/topic:routed-networks-scheduling

2 2

[nova][ptg] Can we close old bugs?
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] We have more than 800 open bugs in nova [1] and the oldest is 8 years old. Can we close old bugs? If yes, what would be the closing criteria? Age and status? Personally I would close every bug that is not updated in the last 3 years and not in INPROGRESS state. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance…

5 7

[nova][ptg] bumping compute RPC to 6.0
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Do we want to bump the compute RPC to 6.0 in Victoria? We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria. I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log…

3 4

[manila][ptg] Minutes, recordings, final day items and Happy Hour!
by Goutham Pacha Ravi 04 Jun '20

04 Jun '20

Hello Zorillas and interested Stackers, It's Friday already, but it feels like we've been there every day this week! Thanks to note takers, we have the meeting etherpad up-to-date wrt the meetings we've had thus far. [1] Tomorrow, 5th June, Friday, we meet in the same room () between 1300 UTC and 1700 UTC - the schedule details are in the etherpad [1], however the main items are as below: - Optimize the quota processing logic for manage share (haixin) (1300-1330 UTC) - Share and share size quotas/limits per share server (carloss/dviroel) (1340-1410 UTC) - Share server migration (dviroel) (1420 - 1450 UTC) - Manila Container Storage Interface project update/roadmap/demo (tbarron) (1500-1530 UTC) - Manila OSC/CLI "common commands" discussion (maaritamm/vkmc) (1530-1550 UTC) - Virtual Happy Hour (all) (1600-1700 UTC) You'll find the recordings of our past discussions uploaded to YouTube [2]. Check the descriptions to skip ahead to specific topics. Please let me know if you have any difficulty accessing these videos. Hope to see you tomorrow! Thanks, Goutham Pacha Ravi [1] https://etherpad.opendev.org/p/victoria-ptg-manila [2] https://www.youtube.com/playlist?list=PLnpzT0InFrqBKkyIAQdA9RFJnx-geS3lp

1 0

[tripleo] Thanks for a great PTG :)
by Wesley Hayutin 04 Jun '20

04 Jun '20

Thanks all! Great topics, participation, discussion etc! Notes and a summary are in the works. And now your moment of zen.

1 0

[oslo][keystone][nova] Spec for moving policy format default to YAML
by Ben Nemec 04 Jun '20

04 Jun '20

One of the outcomes of the Oslo PTG session on Monday was that we need to make YAML the official default for olso.policy instead of just the unofficial default as it has been since policy-in-code happened. The reason this hasn't happened before now is that it is complex and fraught with security concerns, but the RBAC work going on now has made it clear that we need do it anyway. To that end, I've written a spec[0] that I believe captures the plan we outlined in the PTG session. If this is relevant to your interests, please take a look and leave feedback. Thanks. -Ben 0: https://review.opendev.org/733650

2 1

[ops] [cinder] [nova] How can I understand if "Delete volume on instance delete" was selected ?
by Massimo Sgaravatto 04 Jun '20

04 Jun '20

Hi I need to delete an instance created from volume, but I don't want to delete such volume. How can I know if the option "Delete volume on instance delete" was selected when creating such instance ? I can't find any information in openstack server/volume show outputs Thanks, Massimo

2 2

[Openstack] OpenStack Ussuri for Ubuntu 20.04 LTS and 18.04 LTS
by Corey Bryant 04 Jun '20

04 Jun '20

The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack Ussuri on Ubuntu 20.04 LTS and on Ubuntu 18.04 LTS via the Ubuntu Cloud Archive. Details of the Ussuri release can be found at: https://www.openstack.org/software/ussuri To get access to the Ubuntu Ussuri packages: == Ubuntu 20.04 LTS == OpenStack Ussuri is available by default for installation on Ubuntu 20.04. == Ubuntu 18.04 LTS == The Ubuntu Cloud Archive pocket for OpenStack Ussuri can be enabled on Ubuntu 18.04 by running the following commands: sudo add-apt-repository cloud-archive:ussuri The Ubuntu Cloud Archive for Ussuri includes updates for: aodh, barbican, ceilometer, ceph octopus (15.2.1), cinder, designate, designate-dashboard, dpdk (19.11.1), glance, gnocchi, heat, heat-dashboard, horizon, ironic, keystone, libvirt (6.0.0), magnum, manila, manila-ui, mistral, murano, murano-dashboard, networking-arista, networking-bagpipe, networking-bgpvpn, networking-hyperv, networking-l2gw, networking-mlnx, networking-odl, networking-sfc, neutron, neutron-dynamic-routing, neutron-fwaas, neutron-fwaas-dashboard, neutron-vpnaas, nova, octavia, octavia-dashboard, openstack-trove, trove-dashboard, openvswitch (2.13.0), ovn (20.03.0), ovn-octavia-provider, panko, placement, qemu (4.2), sahara, sahara-dashboard, senlin, swift, trove-dashboard, vmware-nsx, watcher, watcher-dashboard, and zaqar. For a full list of packages and versions, please refer to: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ussuri_ver… == Branch package builds == If you would like to try out the latest updates to branches, we deliver continuously integrated packages on each upstream commit via the following PPA’s: sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka sudo add-apt-repository ppa:openstack-ubuntu-testing/queens sudo add-apt-repository ppa:openstack-ubuntu-testing/rocky sudo add-apt-repository ppa:openstack-ubuntu-testing/stein sudo add-apt-repository ppa:openstack-ubuntu-testing/train sudo add-apt-repository ppa:openstack-ubuntu-testing/ussuri == Reporting bugs == If you have any issues please report bugs using the 'ubuntu-bug' tool to ensure that bugs get logged in the right place in Launchpad: sudo ubuntu-bug nova-conductor Thank you to everyone who contributed to OpenStack Ussuri. Enjoy and see you in Victoria! Corey (on behalf of the Ubuntu OpenStack Engineering team)

3 6

[nova] [ops] user_id based policy enforcement
by Massimo Sgaravatto 04 Jun '20

04 Jun '20

Hi In my Rocky installation I am preventing users from deleting instances created by other users of the same project. This was implemented setting in the nova policy file: "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s" This works, even if in the nova log file I see: The user_id attribute isn't supported in the rule 'os_compute_api:servers:delete'. All the user_id based policy enforcement will be removed in the future. Now I would also like preventing user to see the console log file of instances created by other users. I set in the nova policy file: "os_compute_api:os-console-output" : "rule:admin_api or user_id:%(user_id)s" but this doesn't work Any hints ? More in general: were the user_id based policy eventually removed in latest OpenStack releases ? Which are then the possible alternatives to implement my use case ? Thanks, Massimo

2 5

[nova][ptg] Runway process in Victoria
by Balázs Gibizer 04 Jun '20

04 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] In the last 4 cycles we used a process called runway to focus and timebox of the team's feature review effort. However compared to the previous cycles in ussuri we did not really keep the process running. Just compare the length of the Log section of each etherpad [1][2][3][4] to see the difference. So I have two questions: 1) Do we want to keep the process in Victoria? 2) If yes, how we can make the process running? 2.1) How can we keep the runway etherpad up-to-date? 2.2) How to make sure that the team is focusing on the reviews that are in the runway slots? Personally I don't want to advertise this process for contributors if the core team is not agreed and committed to keep the process running as it would lead to unnecessary disappointment. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/nova-runways-rocky [2] https://etherpad.opendev.org/p/nova-runways-stein [3] https://etherpad.opendev.org/p/nova-runways-train [4] https://etherpad.opendev.org/p/nova-runways-ussuri

3 4

[nova][ptg] Feature Liaison
by Balázs Gibizer 04 Jun '20

04 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Last cycle we introduced the Feature Liaison process [1]. I think this is time to reflect on it. Did it helped? Do we need to tweak it? Personally for me it did not help much but I think this is a fairly low cost process so I'm OK to keep it as is. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/c/685857/

5 6

[ops][ptg] Virtual Ops Meetup at the PTG
by Erik McCormick 03 Jun '20

03 Jun '20

Hello all, Your friendly neighborhood Ops Meetup Team is hosting a first ever (and very experimental) Virtual Ops Meetup Wednesday, June 3rd at 13:00 UTC on the foundation Jitsi server. You can find us here: https://meetpad.opendev.org/victoria-ptg-ops-meetup Meetpad will open an integrated Ehterpad to go along with the meeting, but if you'd prefer to have it separate, just replace "meetpad" with "etherpad" in the URL. We recommend using Chrome wherever possible. If you're on a mobile device, there is also a Jitsi Meet app for iOS and Android that work pretty well. The schedule has us going until 15:00 UTC, but we'll continue as long as people are around and want to keep it going. I look forward to seeing a few (or many!) of you in a few hours! Cheers, Erik

2 3

[cinder] retrospective survey
by Brian Rosmaita 03 Jun '20

03 Jun '20

We're scheduled to hold our Cinder team Ussuri cycle retrospective tomorrow (Thursday, 4 June, see the etherpad for details and projected time): https://etherpad.opendev.org/p/victoria-ptg-cinder I posted a brief survey to help get you thinking. It's optional, but like I said, it may stimulate the thought process. Or if you won't be able to attend the retrospective, you can fill out the survey and we'll still be able to take your feedback into account. Here it is: https://rosmaita.wufoo.com/forms/cinder-ussuri-retrospective/ The survey is "sort of" anonymous (it collects your IP number). cheers, brian

1 0

[all][InteropWG] Please verify if Desigane+Heat Project needs any updates for Interop testing of user APIs
by prakash RAMCHANDRAN 03 Jun '20

03 Jun '20

HI all, This is second call to OpenStack Project Teams Core member for identfying any user APIs needed to submit patches for Brnading program.https://www.openstack.org/brand/interop/ Can Designate, Heat PTLs confirm that add-ons listed are all you need for add-on Branding programs for Orchestartion and DNS respetcively. Hi Designate & Heat Core team members, Hi add-ons (Heat + Designate teams) We are trying to run our ambassadors or volunteers to your meetings, but if we miss please reply with "Confirmed OK" to submit these draft to be merged for "OpenStack Powered Storage" approval. Please bring this your PTG meetings if needed to assign a volunteer to complete the verification and submit patch (if updates are needed). Add-ons: DNS: designate - Release notes - https://docs.openstack.org/releasenotes/designate/ussuri.htmladd-on program codes - https://opendev.org/openstack/interop/src/branch/master/add-ons/dns.2020.06… Confirmed OK - ? patch? Orchestration: heat - Release notes - https://docs.openstack.org/api-ref/orchestration/v1/index.htmladd-on program codes - https://opendev.org/openstack/interop/src/branch/master/add-ons/orchestrati… Confirmed OK - ? Patch? ThanksInterop Chair: PrakashVice Chair: Mark

1 0