March 2020 - openstack-discuss - lists.openstack.org

[tripleo] TripleO CI Summary: Sprint 44
by Rafael Folco 27 Mar '20

27 Mar '20

Greetings, The TripleO CI team has just completed Sprint 44 / Unified Sprint 23 (Mar 05 thru Mar 25). The following is a summary of completed work during this sprint cycle: - Migrated stable branches from rdo-cloud to vexxhost - Upstream TripleO migrated to CentOS-8. - Upstream component pipeline <http://tripleo-cockpit.usersys.redhat.com/d/2tivP9BWz/component-pipeline?or…> done. - RDO content unpinned - First CentOS-8 promotion on March 16th - Promotion server is online and ready for CentOS-8 - Completed development of unified logging with tripleo-quickstart and infrared, roll out in progress Ruck/Rover Notes: - https://hackmd.io/7MBqFHurTA2e5H8kYRwgag The planned work for the next sprint [1] extends the work started in the previous sprint and focuses on the following: - TripleO-Operator-Ansible: contribute w/ code, docs, tests and zuul jobs. - Internal component pipeline: starting work - Unified tempest test skip list The Ruck and Rover for this sprint are Wesley Hayutin (weshay) and Sandeep Yadav (ysandeep). 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 [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-24 [2] https://hackmd.io/XMd_vskSTdGZl7ruZ1UckA

1 0

[tc][elections] Nomination
by Donny Davis 27 Mar '20

27 Mar '20

Hello Openstack Humanoids, My name is Donny Davis and I would like to announce my candidacy for TC. I built my first Openstack cloud by hand on the Grizzly release to provide a training environment for fellow employees who lacked Satellite equipment to train on. I have spent subsequent years of my life building, maintaining, operating, and teaching other people how to Openstack. I contribute Openstack CI resources via Fort Nebula (last cycle), and this cycle via Open Edge. This is a cloud that has been tuned specifically for the Openstack Community CI workload. I support many of the obscure requirements to run non-standard CI jobs on this cloud. This Openstack deployment is all my personal equipment and is 100% privately funded. In the last cycle my commit for test instances was mostly 50 concurrent jobs, and this cycle is mostly 40. As a member of the TC, I bring close to a decade of experience as an Operator. I feel the Openstack community can continue to deliver quality code while focusing on easing the burden of getting Openstack clouds into production. For a long time the focus of this community has been to develop bleeding edge features to deliver technical value to consumers. Now this community should focus on making those features easier to consume. I can view the TC through the eyes of a builder, tinkerer, trainer, and long time operator of Openstack. Thank you for your consideration. -- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First"

1 0

[ironic][ops] Stable Ocata and Pike branches are now Unmaintained
by Iury Gregory 27 Mar '20

27 Mar '20

Greetings Ironicers and Operators, During the ironic upstream meeting held on 09 March 2020, we decided to move stable/ocata and stable/pike to unmaintained [1]. Apologies for sending this email almost 3 weeks after the decision was made. We have documented what unmaintained means in our contributor docs [2]. Feel free to rise any questions here or in the irc channel (#openstack-ironic) [1] http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-iro… [2] https://docs.openstack.org/ironic/latest/contributor/#our-policy-for-stable… Best regards, -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

openstack-dev Tacker
by Akshata Jitendra Gage 27 Mar '20

27 Mar '20

Hello, I am new to Tacker. As mentioned in the installation guide i have installed tacker on my server. I need to know that is there any way available by which we can create "service function chaining" via Horizon? And is there any forum related to tacker on which i can raise my doubts and questions? Thanks & Regards Akshata Gage

2 1

[election][neutron] PTL nomination
by Slawek Kaplonski 27 Mar '20

27 Mar '20

Hi, I want to propose my candidacy for Neutron PTL in the Victoria cycle. I have been serving this great team as PTL in the Ussuri cycle already and I would love to continue this in the next cycle as well. Ussuri was my first time as PTL and I learned a lot during this cycle. I think that this new experience and knowledge which I now have will help me serve as PTL in this next cycle as well. In Ussuri I proposed a couple major goals which I wanted to focus on: * merge networking-ovn driver into main Neutron repository - in Ussuri we actually merged networking-ovn code into neutron and made ovn driver as one of the main in-tree drivers for ML2. We also merged the networking-ovn core team into the neutron core team. * Improve overall stability of our CI - we are continuously working to improve CI stability: during this cycle we added couple OVN related jobs to Neutron CI, and we also removed some unnecessary jobs. Unfortunately we didn’t make enough progress with our CI and some jobs still need a lot of work to improve their stability. I think that this is a continuous effort and we will need to focus on it in the next cycle as well. * Improve test coverage for existing features - we introduced many new test cases in the neutron-tempest-plugin repository. Many of them are covering some additional scenarios and advanced functionality: multicast traffic, TCP and UDP port forwarding, and others. I think that this is a continuous effort and we will need to focus on that one in the next cycle as well. * Finish the transition to the new engine facade - this is something which we didn’t make enough progress so far and I would like to treat it as a priority in Victoria. * Improve the stability of Neutron when it is running under uWSGI - recently we promoted our uWSGI jobs to be voting. Those jobs are now pretty stable. I think that in the next cycle we need to finally focus on making uwsgi as the default in Devstack, so that it will be used in most Neutron CI job. In addition to that I wanted to continue Miguel’s way of mentoring potential new core reviewers and contributors, and I think that this has been working pretty fine. In addition to the networking-ovn core team which is now part of neutron core, we also have new core reviewer Lajos Katona and new member of drivers team: Nate Johnston. Our team is now in good shape and we have many active core reviewers and contributors. That’s my summary of what we actually achieved in the Ussuri cycle. Now let’s talk about what are my goals for the Victoria cycle. * Continue adoption of the OVN driver in Neutron - now that the OVN is in-tree, we need to think about making it the default in Devstack. * Finish adoption of new engine facade - it’s unfinished goal from the Ussuri cycle and I think that we should treat it as a priority now, * Metadata over IPv6 - we still have not finished the RFE about support for Metadata service in IPv6 only networks. In the Ussuri cycle we made some progress with the spec [1], and we also had some discussions about it with cloud-init developers. Now I think it’s time to finally get this spec merged and implement it in Neutron, * Continue work on test coverage and CI stability - this is a never ending story and I think that it should be treated with high priority all the time. It is my continuing desire to do my best to help our outstanding team to deliver better software and to grow. [1] https://review.opendev.org/#/c/315604/ — Slawek Kaplonski Senior software engineer Red Hat

1 0

[release] Release countdown for week R-6, March 30 - April 3
by Sean McGinnis 27 Mar '20

27 Mar '20

Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on April 2. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/ussuri branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/…) In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (April 9) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, April 9. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/ussuri branches, this would be a good point for teams to review membership in their $project-stable-maint groups. Once the stable/ussuri branches are cut for a repo, the ability to approve any necessary backports into those branches for ussuri will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: April 2 (R-6 week) Client library freeze: April 9 (R-5 week) Ussuri-3 milestone (including cycle highlights): April 9 (R-5 week) Cycle Highlights Due: April 9 (R-5 week) Ussuri final release: May 13

1 0

[neutron] Final release of non-client libraries
by Slawek Kaplonski 27 Mar '20

27 Mar '20

Hi, Next week is deadline for final releases for non-client libraries and I was checking what patches we are still in review and potentially we would need to have in Ussuri. *Neutron-lib* I see only https://review.opendev.org/#/c/712657/ which potentially may be good to get before final release. IMO it’s in good shape, please review it if You have few minutes (it’s small). *Ovsdbapp* There are 3 opened patches on https://review.opendev.org/#/q/project:openstack/ovsdbapp+branch:master+sta… But I think that maybe only https://review.opendev.org/#/c/683355/ may be potentially needed, mostly by ovn subteam. So please check if this is needed and we should update it to make it in before final Ussuri release. Os-ken I don’t see any important patches waiting in the list https://review.opendev.org/#/q/project:openstack/os-ken+branch:master+statu… so it should be good to go. If I missed anything or You have something else which You need to get in before this final release, please ping me by email or on irc. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][tc] Meeting Agenda April 2nd
by Jean-Philippe Evrard 27 Mar '20

27 Mar '20

Hello everyone, Here are the report topics for the tc next meeting, April 2nd. A few of those are most likely noop, tbh. Feel free to join us! - Report on tc/uc merge (ttx) - Report on the analysis of the 2019 survey (jungleboyj), and survey 2020. - Report on telemetry after Rico's convo with the PTL (ricolin) - report on stable branch policy work: mnaser to push an update to distill what happened on the ML in terms of stable branch policy (mnaser) - report on the community goals for U and V, py2 drop (gmann) - Moving OpenDev discussion forward (clarkb) - Report on the OSF board initiatives (mnaser) Please note that, as usual, the office hours are happening after the meeting, so if you want to chat over new things, it's a perfect place! Regards, Jean-Philippe Evrard

1 0

[tripleo][mistral] Farewell
by Dougal Matthews 27 Mar '20

27 Mar '20

Hey all, I am leaving Red Hat and my last day is tomorrow. As a result I will be moving on from OpenStack. I just wanted to say my farewells here and say thanks to everyone for all the fun over the years. As my last core duty I will be de-coring myself tomorrow :) If anyone wants to reach me beyond tomorrow, my email is probably best: dougal(a)dougalmatthews.com Cheers, Dougal

2 1

[nova][cinder] Why nova-api uses volume's size as bdm.volume_size?
by Zhi CZ Chang 27 Mar '20

27 Mar '20

1 0

[neutron] Drivers meeting - 27.03.2020
by Slawek Kaplonski 26 Mar '20

26 Mar '20

Hi, Due to lack of agenda for our next drivers meeting I will cancel it. I would like You to check list of opened, not triaged, old RFEs [1] and check if there are maybe some RFEs which You would like to continue work on, or maybe there are some which You think we should close as not needed anymore. Also if RFE on this list belongs to You, please respond to any questions from comments in this RFE or just let us know that You don’t want/don’t have time to continue work on it. Thx in advance [1] https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe — Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][elections][ptl][tc] Combined PTL/TC Nominations Kickoff
by Kendall Nelson 26 Mar '20

26 Mar '20

Hello Everyone! Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (5 positions) are now open and will remain open until Mar 31, 2020 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained at https://governance.openstack.org/election/#how-to-submit-a-candidacy Please make sure to follow the candidacy file naming convention: candidates/victoria/<Project_Name or "TC">/<email_address> (for example, "candidates/victoria/TC/stacker(a)example.org"). The name of the file should match an email address for your current OpenStack Foundation Individual Membership. Take this opportunity to ensure that your OSF member profile contains current information: https://www.openstack.org/profile/ Any OpenStack Foundation Individual Member can propose their candidacy for an available, directly-elected seat on the Technical Committee. In order to be an eligible candidate for PTL you must be an OpenStack Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the Train to Ussuri timeframe, Mar 22, 2019 00:00 UTC - Apr 07, 2020 00:00 UTC. Your Gerrit account must also have a verified email address matching the one used in your candidacy filename. Both PTL and TC elections will be held from Apr 07, 2020 23:45 UTC through to Apr 14, 2020 23:45 UTC. The electorate for the TC election are the OpenStack Foundation Individual Members who have a code contribution to one of the official teams over the Train to Ussuri timeframe, Mar 22, 2019 00:00 UTC - Apr 07, 2020 00:00 UTC, as well as any Extra ATCs who are acknowledged by the TC. The electorate for a PTL election are the OpenStack Foundation Individual Members who have a code contribution over the Train to Ussuri timeframe, Mar 22, 2019 00:00 UTC - Apr 07, 2020 00:00 UTC, in a deliverable repository maintained by the team which the PTL would lead, as well as the Extra ATCs who are acknowledged by the TC for that specific team. The list of project teams can be found at https://governance.openstack.org/tc/reference/projects/ and their individual team pages include lists of corresponding Extra ATCs. Please find below the timeline: nomination starts @ Mar 24, 2020 23:45 UTC nomination ends @ Mar 31, 2020 23:45 UTC campaigning starts @ Mar 31, 2020 23:45 UTC campaigning ends @ Apr 07, 2020 23:45 UTC elections start @ Apr 07, 2020 23:45 UTC elections end @ Apr 14, 2020 23:45 UTC Shortly after election officials approve candidates, they will be listed on the https://governance.openstack.org/election/ page. The electorate is requested to confirm their email addresses in Gerrit prior to 2020-03-31 00:00:00+00:00, so that the emailed ballots are sent to the correct email address. This email address should match one which was provided in your foundation member profile as well. Gerrit account information and OSF member profiles can be updated at https://review.openstack.org/#/settings/contact and https://www.openstack.org/profile/ accordingly. If you have any questions please be sure to either ask them on the mailing list or to the elections officials: https://governance.openstack.org/election/#election-officials -Kendall Nelson (diablo_rojo) & the Election Officials

3 2

[oslo] PTL Non-Candidacy
by Ben Nemec 26 Mar '20

26 Mar '20

This won't come as a surprise to most of you, but in case you missed the announcement at the beginning of this cycle I won't be able to serve as Oslo PTL for the next one. While I very much wish this were not the case, I do feel good about the current state of the Oslo team and I'm confident it will continue to do good things under someone else's leadership. Thanks to all of the Oslo contributors who have made the past two years a great experience! -Ben

4 3

[all][ptl] How to Contribute to the OpenStack Blog & Superuser Magazine
by Allison Price 26 Mar '20

26 Mar '20

Hey Stackers— We have received more questions recently about where the community can contribute content, especially on official OpenStack or community channels. Accompanied by the amount of events that have been transformed to virtual experiences, the OpenStack Foundation has been working on ways for the community to centrally share learnings online, and create a place where the community can send project, SIG, and overall community updates. Superuser and the OpenStack blog are community channels—for the community, by the community, so we would really like to get more contributors. We even had a user survey completed yesterday from an operator saying they wish the blog had more information on bug fixes and software updates, so here we are. Here’s how you can contribute: OpenStack Blog <https://www.openstack.org/blog/> We are reviving the OpenStack blog! Here, we want to publish OpenStack bug fixes, software updates, and project milestones that would be beneficial for users to know more about that may be more in depth. Often these are posted on the mailing list, which is great, but could also double as blog posts so that they are searchable in the future when operators stumble upon an issue. Once you have an idea of what you would like to share or have questions, please email community(a)openstack.org <mailto:community@openstack.org>. We can also keep track of a running list of ideas / calls for content for people who have questions that would be great to get answered on the blog. PTLs—heading into the Ussuri cycle, this is a great time to share your ideas on the etherpad around what you can write about. The OpenStack Foundation will reach out to folks who put their names or nicks in the etherpad as well as those who proactively reach out. Superuser <https://superuser.openstack.org/> Superuser has evolved to cover the open infrastructure landscape covering different use cases and open source projects. Whether it’s a video or an article, this content is typically more in depth than what you would see on a project blog and includes things like hands on tutorials, case studies, thought leadership articles, Q&As with open source community leaders, and updates and highlights from open source events around the world. If you have an idea you would like to share, fill out this form <https://superuser.openstack.org/contribute/> and the editorial team will reach out. If you have questions about whether your topic is the right fit, email editor(a)openstack.org <mailto:editor@openstack.org>. You can also attend the OSF community meeting <http://lists.openstack.org/pipermail/foundation/2020-March/002856.html>next week to learn more about how you can get involved and contribute! Thanks! Allison Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[ironic] The Sanity Preservation Un-Conference, or SPUC - An Ironic gathering!
by Julia Kreger 26 Mar '20

26 Mar '20

Greetings Humans, Vulcans, AIs, and any other form of life! Today in the Ironic team meeting, we decided that we needed to have an un-conference! In the theme of an un-conference, I think we will start with two simple questions: * How is everyone? * What ironic (or non-ironic) things shall we discuss? >From there, we will identify topics of discussion, and possibly jump into separate video calls for ~15 minutes each, depending on the number of topics and general insanity. During the last ?15? minutes or so, we shall reconvene into the same video call to enjoy a little time sipping coffee Coffee, Tea or other delicious beverages while we determine who is wearing the silliest hat! So if you have a steampunk hat with gears or even some kind of hat you would wear to a fancy horse race, go right ahead! Only have a rose from your growing quarantine garden! You can wear that too! So what do you need to do! 1) Fill out the doodle[0] so we can actually schedule a time that works for a group of people! 2) Brainstorm some ideas of things you might want to talk about/present or LEARN! 3) Dust off your silly hats! NB: I know the windows on this doodle overlap with Baremetal SIG doodle that I sent out a little while ago. We will figure it out. -Julia [0]: https://doodle.com/poll/krtn9p4z7xx9pa29

6 8

[nova] API updates week 20-13
by Ghanshyam Mann 26 Mar '20

26 Mar '20

Hello Everyone, Please find the Nova API updates of this week. Please add if I missed any BPs/API related work. API Related BP : ============ COMPLETED: 1. Add image-precache-support spec: - https://blueprints.launchpad.net/nova/+spec/image-precache-support Code Ready for Review: ------------------------------ 1. Nova API policy improvement - Topic: https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… - Weekly Progress: Lot of Policies work merged and I am working on remaining ones. - Review guide over ML - http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008504.h… 2. Non-Admin user can filter their instance by availability zone: - Topic: https://review.opendev.org/#/q/topic:bp/non-admin-filter-instance-by-az+(st… - Weekly Progress: Nova change is merged, novaclient change is in-progress - https://review.opendev.org/#/c/713089/ 3. Boot from volume instance rescue - Topic: https://review.opendev.org/#/q/topic:bp/virt-bfv-instance-rescue+(status:op… - Weekly Progress: Code Review is in progress. 4. Add action event fault details -Topic: https://review.opendev.org/#/q/topic:bp/action-event-fault-details+(status:… - Weekly Progress: Few discussion on how we can minimize the info leak to non-admin. discussion is going on. Almost good. 5. Support re-configure deleted_on_termination in server -Topic: https://review.opendev.org/#/q/topic:bp/destroy-instance-with-datavolume+(s… - Weekly Progress: Discussion happened not to use PATCH for this and use existing PUT method. gibi will discuss this in today nova meeting on process and FF wise. Specs are merged and code in-progress: ------------------------------ ------------------ - None Spec Ready for Review or Action from Author: --------------------------------------------------------- -Marking as None here as Ussuri spec deadline is already over. Others: 1. None Bugs: ==== I started fixing policy bugs while working on policy-defaults-refresh BP. 5 bugs have been identified till now and fix up for review. - https://bugs.launchpad.net/nova/+bugs?field.tag=policy-defaults-refresh NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. - https://etherpad.openstack.org/p/nova-bug-triage-ussuri -gmann

1 0

Regarding Split network plane for live migration
by Md. Hejbul Tawhid MUNNA 26 Mar '20

26 Mar '20

Hi, We are using Openstack Rocky . We are observing internal network is using while we do live migration. our internal network interface is 1G. So interface getting full and migration never getting complete. (nova server-migration-list ) 'Remaining Memory Bytes' increasing and decreasing but not getting completed. We have 10G interface for public/external network. I have tried following solution but no luck. still using internal network https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/s… Some Information: [DEFAULT] my_ip = Internal_network_IP [libvirt] live_migration_uri=qemu+ssh://nova@%s.external /system?keyfile=/var/lib/nova/.ssh/id_rsa&no_verify=1 Please let us know if any further information is required. Please advice us if we can solve the issue. Regards, Munna

3 4

[openstack-ansible][elections] Nomination
by Mohammed Naser 26 Mar '20

26 Mar '20

I'd like to announce my candidacy for OpenStack Ansible PTL. As usual, I want to go over all the points I talked about last time and their progress. # Simplifying scenarios for usage and testing We probably haven't progressed much in this, our testing has improved, we did add upgrade testing but unfortuantely that hasn't been as stable. # Using integrated repository for testing and dropping role tests This is pretty much done for the expect of a few corner projects. # Progress on switching all deployments to use Python3 This is also done with some packaging workarounds to make it work with CentOS 7. # Eventual addition of CentOS 8 option We made some progress in this, but it still needs a lot more work, big thanks to jrosser for driving a bunch of this work too. # Reduction in number of config variables (encouraging overrides) This has been done over a few roles now that are using overrides in hopes of minimizing the number of variables to speed up runs. # Increase cooperation with other deployment projects (i.e. TripleO) The Ansible SIG is moving and alive, TripleO uses python_venv_build and os_tempest as well as our connection plugins, so yay. We've worked on getting some new cores as well and making sure the project continues to be sustainable. Thank you for your consideration.

1 0

[tc][elections] Nomination
by Mohammed Naser 26 Mar '20

26 Mar '20

Hi everyone, I want to run again for the OpenStack technical committee for the upcoming cycle. I have been a long time operator of OpenStack with a focus on never using a local for, which has resulted in my involvement with many different projects by making quality-of-life improvements for these services that can help other deployers. I've contributed and worked with different sizes of teams inside OpenStack. >From our big projects such as Nova to projects providing specific services such as Magnum and pretty much most deployments tools at this point. On the operator side, I've helped run one of the longest-running OpenStack public clouds and many private clouds. I've also interacted with many other OpenStack operators that are not as involved in our community, which gives me a significant exposure to our operator story and what that looks like outside our community of known operators. I believe it's time now for me to start driving significant changes in our community to simplify the operator experience, and I think that should start from the technical committee. We're seeing the world evolve around us with new technologies, but we've remained relatively stable and stuck to our "known and trusted" stack. Operators have historically had a lot of frustrations with systems like RabbitMQ and their clustering issues, which end up making the OpenStack experience disappointing. There are many new ways of doing RPC, which we can leverage and help make it even easier to run OpenStack (things such as gRPC). We've also had a history of making it complicated to use containers to deploy OpenStack and historically refused to ship "official" containers. The OpenDev community has built our a step of tooling that can allow us to ship containers very quickly, with nothing more than a well written bindep.txt file and a simple multi-stage build. It's about time that we start having official images and easy ways to deploy OpenStack to reduce those barriers. We define OpenStack as a "cloud operating system." We struggle to deliver much more than the essential infrastructure components. The drive behind OpenStack was to allow people to get more than the necessary infrastructure components. Still, large amounts of different efforts lead us into complicated ways of having to wrangle VMs to run services. With popular container orchestrators and schedulers, OpenStack has a perfect platform to be able to launch those services. By setting up a proper framework, we can start delivering many services such as database as a service, memory store as a service, and so much more by building out Kubernetes operators. It also opens up a whole domain of possible contributors that can use those operators without OpenStack. In closing, I don't expect everyone to agree with all the different ideas I'm putting out. We may only drive just a few of them, or maybe none of them. However, I want to convince you that we need to change. I can understand they sound like big leaps, and they may seem uncomfortable. However, they are genuinely some of the things we need to do to continue to be relevant and put us at the leading edge of technology like we used to be years ago. Thank you for reading this. Regards, Mohammed

1 0

[keystone][horizon] Two approaches to "multi-region" OpenStack deployment
by Krzysztof Klimonda 26 Mar '20

26 Mar '20

Hi, I’ve been spending some time recently thinking about best approach to some sort of multi-region deployment of OpenStack clouds. The two approaches that I’m currently evaluating are shared keystone database (with galera cluster spanning three locations) and shared-nothing approach, where external component is responsible for managing users, projects etc. Shared keystone database seems fairly straightforward from OS point of view (I’m ignoring galera replication over WAN woes for the purpose of this discussion) until I hit 3 regions. Additional regions must either reuse “global” keystone adding latency everywhere, or we need a way to replicate data from “master” galera cluster to “slave” clusters, and route all database write statements back to the master galera cluster, while reading from local asynchronous replica. This has me worried somewhat, as doing that that into eventually-consistent deployment of sort. Services deployed in regions with asynchronous replication can no longer depend on the fact that once transaction is finished, consecutive reads will return up-to-date state. I can imagine scenarios where, as an example, trust is setup for heat, but that fact is not replicated back to the database by the time heat tries to issue a token based on that trust and the process fails. The other approach would be to keep keystone databases completely separate, and have something external to openstack manage all those resources. While not sharing keystone database between regions sidesteps the issue of scalability, and the entire setup seems to be more resilient to failures, it’s not without its own drawbacks: * In this setup Horizon can no longer switch between regions without additional work (see notes below) * There is no longer single API entrypoint to the cloud * Some Keystone API operations would have to be removed from users via custom policy - for example, managing user assignment to projects (for users who have domain admin role) Additional thoughts Could horizon be modified to switch endpoints based on the region selected in the UI? Is the token reissued when region is changed in horizon, or is single token used? I’m assuming it’s the former given my understanding that when projects are changed, a new token is issued - but perhaps the initial token is always used to issue project-scoped tokens for Horizon? In the second scenario, with separate keystone databases, a backend for keystone could be created that proxies some operations (like aforementioned user assignment) back to the external manager so that it can be propagated to other clouds. Does that even make sense? In the end I’m reaching out in hope that someone could chime in based on their experience - perhaps I’m missing a better approach, or making wrong assumptions in my email, especially around asynchronous replication of keystone database and its effect on services in regions that may not have up-to-data view of the databas. Or perhaps trying ot synchronize keystone state by external tool is not really worth the additional effort that would require. -Chris

6 8

[tripleo] ptg topics
by Wesley Hayutin 25 Mar '20

25 Mar '20

Greetings, It's that time of year to start collecting topics for the PTG [1]. The in person PTG has been switched to a virtual meeting [2]. So the bad news is that the world is upside down atm, but the good news is that you may have a better lunch at the sessions ( I kid.. ) You can help plan the virtual ptg by signing up @ https://etherpad.openstack.org/p/Virtual_PTG_Planning Thanks all!! [1] https://etherpad.openstack.org/p/tripleo-victoria-topics [2] http://lists.openstack.org/pipermail/foundation/2020-March/002854.html

1 0

[all] Collecting Virtual Midcycle Best Practices
by Kendall Nelson 25 Mar '20

25 Mar '20

Hello Everyone! I wanted to collect best practices and pitfalls to avoid wrt projects experiences with virtual midcycles. I know of a few projects that have done them in the past and with how travel is hard for a lot of people right now, I expect more projects to have midcycles. I think it would be helpful to have all of the data we can collect in one place for those not just new to virtual midcycles but the whole community. I threw some categories into this etherpad[1] and filled in some options. Please add to it :) -Kendall (diablo_rojo) [1] https://etherpad.openstack.org/p/virtual-midcycle-best-practices

4 8

[tripleo] rdo registry migration
by Wesley Hayutin 25 Mar '20

25 Mar '20

Greetings, FYI.. the rdo registry is migrating from RDO to Vexxhost. You may find some of your jobs hitting "retry_limit" [1] This was caused by a default to log into registries for jobs running in rdo. The default has been updated. Jobs should return to their "GREENISH" status shortly [1] https://review.rdoproject.org/zuul/builds?job_name=tripleo-ci-centos-8-ovb-…

1 0

[heat][magnum][tripleo] Official build and test plan for heat container agent
by Rico Lin 25 Mar '20

25 Mar '20

Dear all tl;dr: Shall we build, publish, and test heat container agents on heat-agents directly?:) Please help to review https://review.opendev.org/#/q/topic:build-container-agent+(status:open) Current I think we encounter with following issues: ** No functional/scenario test for heat-agents but only unit tests* Right now, whatever patch people send up in heat-agents, we only vote against unit tests. This makes no sense for long term maintenance. Which makes me thinking of the second issue. ** No enable scenario tests for software deployment:* We have tests defined, but since we didn't build any customized image. We didn't enable it for a long time. To build a container image for heat-agents (aka heat container agent) is (IMO) the best way for us to enable these teats. Which we can also use it to cross gating on heat and heat-agents (or even heat-template). The no much to change for the test itself but only update the config script to enable the container. ** Can't guarantee cross-project usage:* We currently provide no guarantee for any usage of heat agents from other projects, especially Magnum and TripleO (I didn't personally check if TripleO still using it, but since they still have experiment CI running) who uses heat container agents. It will be nice if we provide basic images for other teams can build their additional requirements. To resolve the above issues, I propose [1]. Which a lot of logic was copied from the current magnum heat container agent scripts [2] so we can start with a higher possibility to allow magnum to reuse our works. For a more detail approach in [1]. The patch defines a build job in `check` pipeline. And a publish job in `post-check`. Uses zuul secrets to save docker authN information. As for the account, I created a new `openstackheat` account [3] for it (I specifically recall there ware discussion about having an official image hub for OpenStack, but not quite sure what happened since). The current approach also can support multiple architectures (like amd64 arm arm64 ppc64le s390x, etc). But for now, I think we should have tested before we publish for other architectures. You can run the build or publish job easily by running `make build-images-all-archs` to build images for all architectures or `make upload-images-all-archs` to build and publish images for all architectures. [1] https://review.opendev.org/#/q/topic:build-container-agent+(status:open) [2] https://opendev.org/openstack/magnum/src/branch/master/dockerfiles/heat-con… [3] https://hub.docker.com/r/openstackheat -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 1

[cinder][qa] propose Liang Fang for devstack-plugin-open-cas-core
by Brian Rosmaita 25 Mar '20

25 Mar '20

Liang Fang is driving the effort to create the devstack-plugin-open-cas and use it to test the cinder/nova volume-local-cache feature with tempest. Since he's our SME on open-cas, I propose that he be made a member of devstack-plugin-open-cas-core. (Currently, the only members of that group are the members of cinder-core and devstack-core.) In the absence of objections, I'll make the change before the next Cinder team meeting (Wednesday, 25 March at 1400 UTC in its new location of #openstack-meeting-alt). cheers, brian

4 4