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

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

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

11 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 10 Jun '20

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

10 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