June 2020 - openstack-discuss - lists.openstack.org

[announce] [debian] New deb-status page and extrepo configuration available for OpenStack on Debian
by Thomas Goirand 14 Jun '20

14 Jun '20

Hi! We've just setup online a new deb-status system [2] to compare what's been released in OpenStack upstream and what has been packaged in Debian. This is an effort to keep each stable branch up-to-date in Debian. This has been possible thanks to Michal Arbet from ultimum.io who wrote os-version-checker [1]. So, a big up to him and ultimum technologies. Note that the Rocky page may not reflect reality, since most of the components are available directly in Debian Buster. Browsing this page, you will notice that both Train and Ussuri are pretty much in an up-to-date shape! :) Note that this page is updated every hours. Also, the Debian packages are now available using extrepo, to make it easier to install. Extrepo is an initiative from Wouter Verhelst to have something comparable to PPA, at least in the way to install the repositories (ie: super easy now...). For example, to install Ussuri in Buster, one can do: apt-get install -t buster-backports extrepo extrepo enable openstack_ussuri This will install the repository as: /etc/apt/sources.list.d/extrepo_openstack_train.sources then you can start using Ussuri using apt as usual. Last, we're searching for volunteers to mirror the osbpo.debian.net Buster backport repositories (to make sure it isn't only on the hands of me and my employer). The only thing that shall be done is to setup an rsync mirroring of the repositories. Best would be to have a mirror in north-America and in Asia. If you're volunteering for this, especially if you are administering a CDN, please get in touch. Hoping this will improve the OpenStack on Debian experience, Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/debian/os-version-checker [2] http://osbpo.debian.net/deb-status/

1 0

[nova][doc] nova pdf building failing on new sphinx 3.1.0
by Ghanshyam Mann 12 Jun '20

12 Jun '20

Hello Everyone, With the new release of Sphinx 3.1.0, nova pdf-docs building started failing due to TeX memory issue (maybe this one - https://github.com/sphinx-doc/sphinx/issues/3099) I could not find the related changes in 3.1.0 which can cause this issue. The issue is to include the giant sample files(policy for now) in pdf doc. I am sure that was discussed previously also when we started pdf building in the Train cycle but do not know what was the solution? Luckily neutron is not facing this as their config sample files are as large as nova. I have logged bug[1] and provided the workaround[2] to unblock the nova gate. Workaround is to include the link to the sample file instead if its full content. Any thoughts on how to fix this? [1] https://bugs.launchpad.net/nova/+bug/1883200 [2] https://review.opendev.org/#/c/735279/ -gmann

1 1

Re: [Interop_WG] Today Fiday 6th June 10 AM PDT call
by prakash RAMCHANDRAN 12 Jun '20

12 Jun '20

Hi all, Can you help me on irc, should we be using #openstack-interop or #openstack-interopwgWHich of this we will be able to use the bit to record meetings besides the call? #topic 1 - Review of content for "OpenStack Powered DNS" and "OpenStack Powered Orchestration"#info We need to update the site https://www.openstack.org/brand/openstack-powered/ #topic 2 - Marketplace Vendors to validate their OpenStack Powered offers for Ussuri This can be tested on https://refstack.openstack.org/#/community_results I don't see any tests being made by any one on 11th or 12 th June, any reasons, is there a transition goin on or there is some issue with refstack-client? #action Prakash to follow up with Mark & Ghanshyam on both web site update for Logo add-on programs and refstack-client working wrt Refstack portal #topic 3 - Follow ups to close for Usuri actions items #action Seek help from Staff to update the formality to make "one or more co-chairs" in B192#link https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=doc/sour…... #info updated the googledocs for interops on CinderV2 apis being removed , correction it should have appeared as deprecated in 2019.11 , no issues as we have now dropped it out in 2020.11 approval#link https://docs.google.com/document/d/1vf8rxKxuFoXmZCxfMIIfHm4TzK1kuANktXyUHiu…... topic 4 - Formation new committee for Future Interop work - we discuss this before OpenDev June 29 and help get approvals next Board meeting #info consider Conformance vs Compliance to keep off legal part for new certifications or Logo programs Q1. Data points from MarketPlace?Please educate us how we collect Marketplace data - How customers use the Marketplace? Can we get Data points from Marketplace? If so How? Any answers from TC community or Users Community folks? Q2. Does Tempest testing Infra provider/Vendors offerings occur in real time or you run a batch and send report to interop and who receives this test results? Appreciate all the help from especially Mark, Ghanshyam and we like to have all support for community for interop continuation. ThanksPrakash On Thursday, June 11, 2020, 06:31:21 AM PDT, Ghanshyam Mann <gmann(a)ghanshyammann.com> wrote: Thanks Prakash for all your effort and energy. I can definitely help with guidelines and their testing part from Tempest point of view or you can count that as help from the community side. My concern is almost the same as Mark, I am involved in multiple areas so if interop requires more time then it might be an issue. As of now, I am ok to help to handle some code side part or as 2nd vice-chair hoping that would not take much bandwidth (i think we do not need 2nd vice-chair things as such :) but no strong opinion ). But the main issue for interop (i mentioned earlier also) is the maintainer for refstack and other repo. We really need some developers for that. -gmann ---- On Wed, 10 Jun 2020 21:07:13 -0500 prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote ---- > Mark, > OK let me handle it as chair, but let's refer or nominate Ghanshyam too as second vice chair and if needs to vote it lets do that. > I have submitted the change of irc channel to #openstack-interop as tested last week. and try pile all logs therein with startmeeting and endmeeting weekly to debate and arrive at how we proceed on this after tomorrows presentation which I like both of you to attend. > https://review.opendev.org/#/c/735034/1 > If we need anything to merge the above go ahead. > Arkady as usual is with me on Board is there to help us all, so we do have two from Board and two from TC and community. > So let me answer your latest email, and revise the presentation and web link for Board accordingly. > ThanksPrakash > > > > On Friday, June 5, 2020, 12:32:07 PM PDT, Mark Voelker <mvoelker(a)vmware.com> wrote: > > > So let us wait and check with OpenStack staff how they can help us if they can fix the web irc/time links, if not I will try fix it over week end. > Well, that’s sort of the point of having the meeting info housed in public repository: community members actually don’t need to go through the Foundation staff for things like this, they can just fix them with a few lines of text submitted via git! =) > If you’re not sure how to do that, let me know…it’ll only take a moment to submit a patch so I’m happy to help. > At Your Service, > Mark T. Voelker > > > On Jun 5, 2020, at 3:17 PM, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: > Mark, > I see that using irc does help take notes for weekly meetings, especially if there is frequent meetings weekly alternate week etc. > So let us wait and check with OpenStack staff how they can help us if they can fix the web irc/time links, if not I will try fix it over week end. > ThanksPrakash > On Friday, June 5, 2020, 11:49:22 AM PDT, Mark Voelker <mvoelker(a)vmware.com> wrote: > > Prakash, > Quick suggestion: since it looks you’re running these meetings on Zoom going forward, you may want to add the Zoom information to the upstream meetings calendar or alternately at least remove the old IRC meeting entry. See the "IRC meetings schedule” section here for information: > http://eavesdrop.openstack.org/ > The file that you’d want to submit a patch for is: > https://opendev.org/opendev/irc-meetings/src/branch/master/meetings/interop… > (Note that the times presented in the these files are in UTC rather than a local timezone.) > At Your Service, > Mark T. Voelker > > > On Jun 5, 2020, at 11:06 AM, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: > Hi all, > Prakash Ramchandran is inviting you to a scheduled Zoom meeting.To keep reliable zoom link have updated the weekly call to this one and see if you can join inspite of our ongoin PTG at 10 AM PDT. > Join from a browser: https://Dell.zoom.com/wc/join/99829924353 > Password: 101045 > Trying to consolidate what we got from PTG interactions to close the Draft updates. > https://etherpad.opendev.org/p/victoria-ptg-interop-wg > > > Closure in next week for Interop Guidline? > > What is the suggession for Board presentaion from team for Prakash on June 11th? > Anything you like to add on the call, we can keep it short and try close after PTG next week. > ThanksPrakash > > > > > > >

1 1

[release] Release countdown for week R-17, Jun 15 - Jun 19
by Sean McGinnis 12 Jun '20

12 Jun '20

Development Focus ----------------- The victoria-1 milestone is next week, on June 18! Project team plans for the Victoria cycle should now be solidified. General Information ------------------- If you planned to change the release model for any of your deliverables this cycle, please remember to do so ASAP, before milestone-1. Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Ussuri release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Victoria-1 milestone: June 18 Victoria-2 milestone: July 30

1 0

[all][interopWG] Following up on approval of Interop Guidelines for Ussuri
by prakash RAMCHANDRAN 11 Jun '20

11 Jun '20

Hi all, This is a follow up to send feedback to all of core teams (Nova, Neutron, Cinder, Keystone, Glance) + (Swift) + (Add-ons DNS Designate & Orchestration Heat). This was the patch which Mark submitted to kickstart the next refstack test for https://www.openstack.org/brand/openstack-powered/ A. We need to decide on content for "OpenStack Powered DNS" and "OpenStack Powered Orchestration" to this site https://review.opendev.org/#/c/735159/ Community Reporting - Should start seeing program staring 2020.06 new ones and please let us know when you have something to share for Ussuri https://refstack.openstack.org/#/community_results B. We need Marketplace Vendors to validate their OpenStack Powered offers for Ussuri and send emails which we will discuss at tomorrows meeting. C. Meeting will be on irc Friday as usual weekly like #openstack-interopwg @17.00 UTC Friday (PDT 10 AM) Will plan on using zoom call after IRC logins if needed. Agenda we will take as what was discussed at Board and follow ups to close for Usuri and plan further for committee formation for future of interop. ThanksPrakash / Mrak/ GhanshyamFor interopwg

1 0

[glance] Weekly priorities
by Abhishek Kekane 11 Jun '20

11 Jun '20

Hi Glance Members, We are approaching milestone 1 which is just a week away. Before milestone 1 we need to review below specs on priority. sparse image upload - https://review.opendev.org/733157 Unified limits - https://review.opendev.org/729187 Image encryption - https://review.opendev.org/609667 Cinder store multiple stores support - https://review.opendev.org/695152 Kindly review the specs. Thanks & Best Regards, Abhishek Kekane

1 0

[neutron] Virtual PTG summary
by Slawek Kaplonski 11 Jun '20

11 Jun '20

# Day 1 (Tuesday) ## Retrospective >From the good things team mentioned that migration of the networking-ovn driver to the core neutron went well. Also our CI stability improves in the last cycle. Another good thing was that we implemented all required in this cycle community goals and we even migrated almost all jobs to Zuul v3 syntax already. Not so good was progress on some important Blueprints, like adoptoion of the new engine facade. The other thing mentioned here was activity in the stadium projects and in the neutron-lib. ## Support for the new oslo.policy Akihiro and Miguel volunteered to work on this in the Victoria if they will have some cycles. It is important feature from the Keystone team's point of view. Keystone and Nova teams already have some experience on that transition so they can help us with that. We need to ensure that new policies in neutron can works fine with e.g. old ones defined in the stadium projects. ## Adoption of new enginefacade We discussed how to finish this adoption of new enginefacade in Neutron in Victoria cycle. There is couple of people who volunteered to help with that. After it will be done in Neutron we need to check what changes are required in the stadium projects too. ## tenant_id/project_id transition Rodolfo raised this issue that in some places we may still have e.g. only tenant_id and miss project_id. We should all be aware of that and whenever we see something like that e.g. in neutron, neutron-lib, tempest or other repos, we should propose patch to change that. ## Neutronclient -> OSC migration We found out that the only blocker which prevents us to EOL python-neutronclient as a CLI tool is lack of possibility to pass custom arguments to the commands. As we know, OSC/SDK team don't have anything against adding support for that in OSC. It's actually already done for e.g. Glance. Slaweq volunteered to work on it this cycle and if that will be done, define final date of EOL for python-neutronclient for Victoria+2 cycle. ## RFEs review We reviewed about 10 old, stagnant RFEs. We decicded to close some of them as non relevant anymore. For others we discussed some details and we will continue this discussion on LP and on the drivers meetings. ## Review of stadium projects We needed to review list of stadium projects again. Conclusions are: * neutron-vpnaas, networking-odl, networking-bagpipe, networking-bgpvpn are in good shape and we can definitely keep them in stadium, * neutron-fwaas - we will delete all code from this repo now and mark it as deleted project, see [1] for example how this is done, * neutron-dynamic-routing - send email to call for maintainers, but don't consider it as deprecated yet in this cycle, maybe in the next one, * networking-midonet - this one is the problem currently as it isn't well tested with current neutron in u/s gate. # Day 2 (Wednesday) ## Meeting with Edge SIG During this call project [2] was mentioned. For now it was moved to unofficial projects namespace but maybe someone will revive this project if there is use case for it. We talked about [3] and doing it in Victoria cycle. After discussions about the same with Nova team on Friday (see below) we decided that as a first step Nova will work on changes on their side and those changes will not require anything from the Neutron. On our side, Miguel Lavalle volunteered tentatively that he can work on this on too. There was also question about support of IEEE 1588 (PTP) in Neutron - so far we don't have any support for it. But we are always welcome for new RFEs :) ## Future of metering agent Discussion was related to the spec [4]. General conclustion from the discussion is that we will work on this new L3 agent extension which will collect metering data but this will not be in any way replacement for the old metering agent. When this will be ready, we can start discussion about potential deprecation of the old metering agent and its API but that's nothing for the current cycle for sure. ## ML2/OVS and OVN feature gaps List of gaps between ML2/OVS and ML2/OVN backends is in [5]. We discussed how to maintain this list and make it smaller. Decision from this discussion is that we will try to remember to add new items to this list every time when some new feature will be added to Neutron and implemented in ML2/OVS. We will also open LP for such things to keep it tracked on OVN driver side and to implement that when it will be needed by community. ## OVN driver and agent API During this discussion we talked about Neutron agents API and two options in it: * setting admin to be disabled (admin_state_up = False) - we decided that this is really relevant only for L3 and DHCP agents. It's not really used for OVS or Linuxbridge agents and it shouldn't also have any effect for OVN drivers. So Kuba will propose RFE with description of what our API should return in case of setting this admin_state_up value for agents for which it doesn't makes sense, * deletion of agents - we decided that for ovn agents it should be possible to delete them in same way how it is done now for other agents. This has some downside when user will delete agent which is still alive. In such case agent will be deleted and immediatelly shown back in neutron agent list. That is because of how OVN is storing data about those "agents" internally and how Neutron OVN driver uses this data. This isn't however big issue because it may happend in exactly same way for example for OVS/DHCP/L3 agents if user will delete them just before it will send new heartbeat message to the Neutron server. ## Stateless security groups support for OVS firewall (and OVN?) Conclusion from this discussion is that there is need and use cases (DPDK, telco) to introduce stateless security groups in openvswitch and ovn firewall drivers. During the discussion we agreed that implementation shouldn't be really thought. Bernard volunteered to open LP to track it for both of those drivers. ## OVN concept of distributed localport ports used for Metadata agent and DHCP Maciek explained us limitations in current implementation of segments in Neutron and how it blocks OVN driver to support that. Basically the problem is that currently Neutron has limitation that one port can be only on one segment. OVN driver is using "special" ports (local ports in OVN) to handle metadata and dhcp. And such port has to have IP address from all segments which belongs to the network. We agreed to introduce new type of device_owner which will mean that port is "distributed". Such kind of port may then be in more than one segment at same time. Basically this concept is similar to how DVR router ports works currently. ## Switching default backend in Devstack to be OVN At the end of the day we discussed possibility to switch Devstack's default backend in Neutron to be OVN instead of OVS agent. We all agreed that this is big step forward and that we want to do that as Neutron team. We want to give with this change clear signal that we believe that OVN backend is future of the Neutron and we want to invest more in that. Hovewer we want to highlight that this means *nothing* for real production environments. We are *not* going to deprecate any backends. All existing drivers will be tested as they are tested now in the Neutron gate. Different deployment tools may still use different backends as default ones. This change will be however pretty big change for all OpenStack projects which will use OVN driver as Neutron's backend in their jobs. Such change was already done in TripleO in Stein cycle and it went pretty smooth so we are not expecting any serious issues there. We would like to do this change which we set for ourselves is Victoria-2 milestone. # Day 3 (Thursday) ## Deprecation of use_veth_interconnection in the ovs-agent It seems after discussion that this config option was introduced very long time ago and was probably related to something like descibed in [6] but later Open vSwitch introduced patch ports and there was another old LP [7] which was saying that ovs-agent should use patch ports instead of veth pairs. And that solution is still recommended today in the Neutron. So we agreed to deprecate this option in the Victoria cycle and remove it completly in W cycle. ## Loki service plugin Service plugin called "loki" is developed to be use in the CI jobs and to add DB deadlock errors to some random DB queries. But for now it's not used at all in the Neutron CI. During the discussion we decided to add new periodic Zuul job which will run neutron-tempest-plugin.api tests with enabled loki service plugin to check if Neutron still can handle properly such random DB Deadlocks. ## SR-IOV ML2 driver support for VLAN trunking Patch related to this discussion is [8] - it's big patch which introduces base trunk driver interface for SR-IOV agent but also implementation of this base driver for Intel cards. During the discussion we agreed that we shouldn't have such vendor specific code in the Neutron tree. Our suggestion was to split this patch into two pieces - base driver which will be in the Neutron repo and Intel specific driver which will be hosted in some other repository. ## Neutron-lib We were discussion couple of different issues related to the neutron-lib in general. * Nate started discussion about future of the neutron-lib and if this is still really needed. His proposal was to relax a bit policies about what should be re-homed from Neutron to the neutron-lib repository. Originally neutron-lib was introduced to help neutron stadium and 3rd-party projects to not import things from neutron but from the neutron-lib only and have less dependencies thanks to that. Currently development of neutron-lib is much slower than it was in the past and we don't see so much need to use neutron-lib from the developers of the stadium or 3rd-party projects. After some discussion we agreed that neutron-lib is still usefull and important to keep e.g. api definitions and highligh base generic interfaces for neutron and other related projects. So we will keep neutron-lib as it is now but we will relax a bit policy of what will be moved to this repo from the neutron. Second outcome from the same discussion was decision that we will change a bit our policy of updating every neutron-lib/neutron consumer when we will re-home things. We will be focused only on Neutron stadium projects. For other projects we will introduce 1 cycle deprecation period for things which are moved out from the neutron to neutron-lib repo. * Adam from the Octavia team started discussion about how to test neutron and neutron-lib changes. Currently all neutron CI jobs are using latest released neutron-lib version. But because of that developers can't use "Depends-On" to test some neutron change together with the related neutron-lib change. After discussion our final decision is that we will propose one additional CI job which will use neutron-lib from master branch. So this job can be used to check neutron and neutron-lib changes together before neutron-lib with required change will be released. # Day 4 (Friday) ## Nova-Neutron-Cyborg cross projects session This was long (2h) session where we discussed couple of important things. * First topic was about scheduling of the routed networks. After some discussion was that Nova team will work on something only on Nova's side as a first step. Later we will see how to move forward with integration of Nova and Neutron there. * Second topic was about updating minimum bandwdith for the ports. We agreed that this should be done on Neutron side and Neutron will update resource allocation directly in Placement. There is no need to involve Nova in this process. We also decided that we will not allow update values of the existing, already associated rules in the QoS Policy. The only possible way to change minimum bandwidth will be to update port to associate it with new QoS Policy. * Last topic on this meeting was related moslty to Cyborg and Nova cooperation. There will be required some changes on the Neutron side as well, like e.g. add new api extension which will add "device profile" to the port object. This new attribute will contain e.g. information about name of the device profile from Cyborg. Details are in doc: [9] ## Future of lib/neutron and lib/neutron-legacy in devstack In Devstack there are currently 2 modules which can configure Neutron. Old one called "lib/neutron-legacy" and the new one called "lib/neutron". It is like that since many cycles that "lib/neutron-legacy" is deprecated. But it is still used everywhwere. New module isn't still finished and isn't working fine. This is very confusing for users as really maintained and recommended is still "lib/neutron-legacy" module. During the discussion Sean Collins explained us that originally this new module was created as an attempt to refactor old module, and to make Neutron in the Devstack better to maintain. But now we see that this process failed as new module isn't still used and we don't have any cycles to work on it. So our final conclusion is to "undeprecate" old "lib/neutron-legacy" and get rid of the new module. ## OVN master and stable CI jobs Currently we are running all Neutron OVN related jobs with OVN installed from packages provided by operating system. Maciek explained us why we should also test it with OVN from master branch. It is like that because often new features added to the OVN driver in Neutron are really dependent on changes in the OVN project. And until such changes in OVN aren't really released we can't test if Neutron OVN changes really works with new OVN code as they should. So we deviced to change "neutron-ovn-tempest-full-multinode-ovs-master" that it will also install OVN from the source. ## CI Status During discussion about our CI jobs we decided to remove from the Neutron check queue 2 non-voting and still not stable jobs: "neutron-tempest-plugin-dvr-multinode-scenario" and "neutron-tempest-dvr-ha-multinode-full" and move those jobs to the experimental queue. This is temporary solution until we will fix those 2 jobs finally. # Team photo It wasn't as great as in other PTGs. But You can find our team photos in the current context at [10]. Credits for photos comes to Rodolfo and Jakub who made them :) Thx a lot! # Etherpads Etherpad from Neutron sessions can be found at [11]. Notes from the Nova-Neutron-Cyborg session can be found at [12]. [1] https://opendev.org/openstack/congress [2] https://opendev.org/x/neutron-interconnection [3] https://bugs.launchpad.net/neutron/+bug/1832526 [4] https://bugs.launchpad.net/neutron/+bug/1817881 [5] https://docs.openstack.org/neutron/latest/ovn/gaps.html [6] https://bugs.launchpad.net/neutron/+bug/1045613 [7] https://bugs.launchpad.net/neutron/+bug/1285335 [8] https://review.opendev.org/#/c/665467/72/ [9] https://docs.google.com/document/d/11HkK-cLpDxa5Lku0_O0Nb8Uqh34Jqzx2N7j2aDu… [10] http://kaplonski.pl/images/Virtual_PTG_2020/ [11] http://kaplonski.pl/images/Virtual_PTG_2020/ [12] https://etherpad.opendev.org/p/nova-victoria-ptg -- Slawek Kaplonski Senior software engineer Red Hat

2 3

[cinder] victoria virtual mid-cycle part 1 poll
by Brian Rosmaita 10 Jun '20

10 Jun '20

Hello Cinder team and fellow travelers, As discussed at today's Cinder meeting, we'll hold a virtual mid-cycle meeting in two two-hour sessions, at weeks R-16 and at R-8. Please indicate your availability to meet for the first session, which will be held during the week of June 22-26: https://doodle.com/poll/4vx4gavsewrkgbyh Please respond before 12:00 UTC on Monday 15 June. thanks, brian

1 0

Idempotency for multiple nics
by Nadarajah, Sathia 10 Jun '20

10 Jun '20

Hi All, We are facing the exact issue that is outlined here, “When a server is created with multiple nics which holds security groups, module was applying default SG to the server & remove SG on the nics.” https://github.com/ansible/ansible/pull/58509 https://github.com/ansible/ansible/issues/58495 And we are on the following version of openstacksdk (ansible) [root@ansnvlonls01 bin]# source /var/lib/awx/venv/mypy3/bin/activate (mypy3) [root@ansnvlonls01 bin]# pip show openstacksdk Name: openstacksdk Version: 0.46.0 Summary: An SDK for building applications to work with OpenStack Home-page: https://docs.openstack.org/openstacksdk/ Author: OpenStack Author-email: openstack-discuss(a)lists.openstack.org License: UNKNOWN Location: /var/lib/awx/venv/mypy3/lib/python3.6/site-packages Requires: netifaces, iso8601, keystoneauth1, os-service-types, PyYAML, cryptography, six, requestsexceptions, decorator, pbr, jmespath, appdirs, munch, jsonpatch, dogpile.cache When can we expect to have this fix factored into openstacksdk ? Thanks. Regards, Sathia Nadarajah Security and Enterprise Engineering CH2 Networks and IT, Telstra [Telstra] P 0386946619<tel:+61-3-8694-6446> M 0437302281<tel:+61-407-843-045> E Sathia.Nadarajah.2(a)team.telstra.com<mailto:Sathia.Nadarajah.2@team.telstra.com> W www.telstra.com<http://www.telstra.com>

2 2

[ops][telemetry] OpenInfra Labs discussion on cloud monitoring
by Jeremy Stanley 10 Jun '20

10 Jun '20

The OpenInfra Labs project is starting a discussion on their mailing list to try and find commonalities across open cloud monitoring approaches, beginning by assembling user stories and requirements from a diversity of organizations. If anyone has any feedback for them, I recommend following up to that ML thread (and subscribe even, their list is very low-volume). http://lists.opendev.org/pipermail/openinfralabs/2020-June/000061.html -- Jeremy Stanley

1 0

[oslo] PTG Wrapup
by Ben Nemec 10 Jun '20

10 Jun '20

I wrote up a slightly wordy summary of the Oslo PTG discussions: http://blog.nemebean.com/content/oslo-virtual-ptg-victoria Hopefully I didn't forget anything in the week+ since then, but if I did let me know. :-) -Ben

1 0

[kolla-ansible] Some proposals based on my work with kolla-ansible
by Klemen Pogacnik 10 Jun '20

10 Jun '20

HI! I’ve worked with kolla-ansible for over the year, currently on rocky version. I’ve done some work which can maybe be intersting to community. 1. Proposal - Adding additional functionality to kolla-ansible playbook For functionalities which are not officially supported by kolla-ansible group, but are done by any individual or a group and are interesting for a community. Each additional functionality has its own GIT project. It consists of one or more ansible roles. The structure of project is very similar to the kolla-ansible project. addfunct-name / README.md / etc / kolla / globals.yml / passwords.yml / ansible / inventory / all-in-one / multinode / group_vars / all.yml / roles / addmodule_role1 / … / addmodule_role2 / … / destroy.yml / kolla-host.yml / post-deploy.yml / site.yml / stop.yml Configuration parameters of functionality are put to globals.yml and all.yml. Passwords are put to passwords.yml. Inventory data are added to all-in-one and multinode files. Roles variables, tasks, handlers, templates are added to ansible/roles. Activation of roles are included to destroy.yml, kolla-host.yml, post-deploy.yml, stop.yml and/or site.yml. Not all steps are compulsory. Merging additional module project to kolla-ansible is quite simple with basic shell commands: cat $ADD_MODULE/etc/kolla/globals.yml >> $KOLLA_ANSIBLE/etc/kolla/globals.yml cat $ADD_MODULE/etc/kolla/passwords.yml >> $KOLLA_ANSIBLE/etc/kolla/passwords.yml cat $ADD_MODULE/ansible/group_vars/all.yml >> $KOLLA_ANSIBLE/ansible/group_vars/all.yml cat $ADD_MODULE/ansible/inventory/all-in-one >> $KOLLA_ANSIBLE/ansible/inventory/all-in-one cat $ADD_MODULE/ansible/inventory/multinode >> $KOLLA_ANSIBLE/ansible/inventory/multinode cat $ADD_MODULE/ansible/destroy.yml >> $KOLLA_ANSIBLE/ansible/destroy.yml cat $ADD_MODULE/ansible/kolla-host.yml >> $KOLLA_ANSIBLE/ansible/kolla-host.yml cat $ADD_MODULE/ansible/post-deploy.yml >> $KOLLA_ANSIBLE/ansible/post-deploy.yml cat $ADD_MODULE/ansible/site.yml >> $KOLLA_ANSIBLE/ansible/site.yml cat $ADD_MODULE/ansible/stop.yml >> $KOLLA_ANSIBLE/ansible/stop.yml cp -r $ADD_MODULE/ansible/roles/* >> $KOLLA_ANSIBLE/ansible/roles That way additional roles are executed together with other kolla-ansible roles on hosts which are specified in a common inventory. Tasks can use all available kolla-ansible variables, tools, ansible modules. 2. Proposal – building kolla-ansible container image kolla-ansible can be run in a container. Image is built together with other kolla containers and is available on docker hub. That way it would be easier for somebody to try kolla. It is also possible to build images, which have some interesting additional functionalities included. 3. Proposal – adding ceph as an additional functionality described in previous proposals Ansible roles are developed for external ceph deployment. Cephadm, kolla-ceph or any other tool can be used in role’s plays. Has somebody have a suggestion, what to use? A special kolla-ansible container image is built with included ceph roles. Merging is specified in Dockerfile. I’ve already included three additional functionalities: - docker_settings (docker_bip network is configurable) - resource_reservation (resources – cpu cores and memory can be limited for openstack services) - freeipa_client_install (freeipa client installation – done by my colleague, not finished yet) They are now all included in the same project and can be viewed on: https://gitlab.com/kemopq/addmodules-kolla-ansible/-/tree/master/ansible <http://gitlab.com/kemopq/addmodules-kolla-ansible/-/tree/master/ansible> I’m building kolla-ansible container with those functioanlities included and running kolla-ansible playbook in container. I’m planing to do external Ceph deployment that way in next weeks. I’m open to suggestions how this concept can be improved. Klemen

1 0

[largescale-sig] Next meeting: June 10, 8utc
by Thierry Carrez 10 Jun '20

10 Jun '20

Hi everyone, The Large Scale SIG will have a meeting this week on Wednesday, June 10 at 8 UTC[1] in the #openstack-meeting-3 channel on IRC: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200610T08 Feel free to add topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting A reminder of the TODOs we had from last meeting, in case you have time to make progress on them: - masahito to post initial oslo.metrics code to openstack/oslo.metrics Talk to you all on Wednesday, -- Thierry Carrez

1 1

[cinder] Victoria Virtual PTG
by Brian Rosmaita 09 Jun '20

09 Jun '20

A summary of what happened at the Cinder part of the PTG is available: https://wiki.openstack.org/wiki/CinderVictoriaPTGSummary That page also contains links to the recordings. If you led a discussion, please take a look at your topic to make sure I captured all the important points correctly. cheers, brian

1 0

[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 09 Jun '20

09 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 09 Jun '20

09 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