December 2019 - openstack-discuss

[kolla] No more meetings in 2019
by Mark Goddard 16 Dec '19

16 Dec '19

Hi, We'll cancel the next 3 weeks meetings, and meet again on the 8th January. I'll be away from tomorrow until 2nd January. Cheers, Mark

1 0

[keystone] Meeting time change
by Colleen Murphy 16 Dec '19

16 Dec '19

As discussed in today's meeting[1], I would like to propose we move the team meeting to one hour later, 17:00 UTC, same day same channel. Everyone in attendance today was okay with the change but I wanted to give anyone who couldn't attend today the chance to object. Let me know if this change would prevent you from attending the meeting. If there are no objections this week, I'll propose a change to the eavesdrop calendar. For the moment, assume the meeting next week (December 17) will be at 17:00. Colleen [1] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-12-10-1…

1 1

[all] Which will be the first OpenStack release to require Python 3 ?
by Neil Jerram 16 Dec '19

16 Dec '19

I think the answer is Ussuri (and hence that Train can still be run with Python 2), but have not been able to find a clear statement of this, hence asking here. (Suggest also updating https://wiki.openstack.org/wiki/Python3 with the answer.) Thanks, Neil

2 2

[neutron] bug deputy report for the week of Dec 9th
by Takashi Yamamoto 16 Dec '19

16 Dec '19

hi, here's the list of the bugs reported in the week. RFE: https://bugs.launchpad.net/neutron/+bug/1855123 Neutron ovs agent still fails vlan transparency check https://bugs.launchpad.net/neutron/+bug/1855854 [RFE] Dynamic DHCP allocation pool Critical: https://bugs.launchpad.net/neutron/+bug/1856156 Constraints file is not considered during doc build * backports probably need some investigations. https://review.opendev.org/#/q/Iea61238f37fdf24c0264f96d104ee0b3b6aec8e2 High: https://bugs.launchpad.net/neutron/+bug/1855759 neutron.plugins.ml2.drivers.agent._common_agent KeyError: 'gateway' . ERROR * a proposed patch: https://review.opendev.org/#/c/698287/ https://bugs.launchpad.net/neutron/+bug/1855888 ovs-offload with vxlan is broken due to adding skb mark * a proposed patch, blocked by gate: https://review.opendev.org/#/c/698336/ https://bugs.launchpad.net/neutron/+bug/1855912 MariaDB 10.1 fails during alembic migration https://bugs.launchpad.net/neutron/+bug/1856319 [SRIOV] Agent is reporting "resources_synced=True" when restarted and placement is down Low: https://bugs.launchpad.net/neutron/+bug/1855919 broken pipe errors cause neutron metadata agent to fail https://bugs.launchpad.net/neutron/+bug/1856152 Vm`s tap bound to br-int，When cfg.CONF.OVS.integration_bridge is configured as another bridge

1 0

[nova][ptg] Continue QoS port support
by Balázs Gibizer 14 Dec '19

14 Dec '19

Hi Novas! Here is my summarized plans for Ussuri about continuing the work on supporting qos neutron ports (those that has bandwidth resource request) in nova. What is missing: * Tempest coverage is missing for migrate and resize support that is merged in Train. This work is already underway and bugs has been caught [1][2] * Support evacuate, live migrate, unshelve. The work is described in [3][4] and the first set of patches for the evacuation support is up for review [5] * Support for cross cell resize with qos port needs some work. Matt prepared the cross cell resize code already in a way that no new RPC change will be needed [6] and I have a plan what to do [7]. * InstancePCIRequest persists parent_ifname during migration but the such change is not rolled back if the migration fails. This is ugly but I think it does not cause any issues [8]. I will look into this to remove the ugliness. The bandwidth support for the nova-manage heal_allocation tool was merged in Train. Originally I planned to backport that to Stein but that patch grown so big and incorporated may refactors along the way that I'm not sure any more that it is reasonable to backport it. I'm now thinking about keeping it as-is and suggesting operators to install Train nova in a virtualenv to run heal allocations for bandwidth aware servers if needed in Stein. I do have to run some manual tests to see if it actually works. Any feedback is welcome! cheers, gibi [1] https://bugs.launchpad.net/nova/+bug/1849695 [2] https://bugs.launchpad.net/nova/+bug/1849657 [3] https://blueprints.launchpad.net/nova/+spec/support-move-ops-with-qos-ports… [4] https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/supp… [5] https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:ma… [6] https://review.opendev.org/#/c/635080/43/nova/compute/manager.py@5375 [7] https://review.opendev.org/#/c/633293/49/nova/compute/manager.py@4742 [8] https://review.opendev.org/#/c/688387/6/nova/compute/manager.py@3404

2 3

[tc] Concluding the "2019 TC vision" exercise
by Thierry Carrez 13 Dec '19

13 Dec '19

Hi everyone, Back in 2016-2017, TC members participated in stewardship training at Zingerman's. Part of their framework relies on the concept of "visioning": how describing in details a desirable future helps you get there. As a result of that training, TC members in 2017 created such a "vision"[1], set in 2019. As the sole TC survivor of these ancient times and as we close the 2019 year, it sounds appropriate to reflect back on this exercise and discuss if anything more should be done in that area. [1] https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html The first part of the vision, "Navigating with Constellations", was describing efforts to make OpenStack components combinations more easy to understand for specific use cases, and individual components more easily reusable in other types of deployments. The "constellation" concept never really took off, and product management is still very much done downstream of OpenStack. The "vision for OpenStack Clouds" living document[2] helped us refine our scope and better answer the "What is OpenStack" question. The OpenStack Map[3] helps navigate the ecosystem, and content on the software pages on openstack.org is now more directly driven[4] from the project teams, but overall making OpenStack easier to navigate is still very much a work in progress. That said, individual components are now generally easier to reuse in other contexts, as seen with Ironic reuse in Metal³. The second part of the vision, "Working with Adjacent Communities", was describing how we should interact and combine our work with components produced by adjacent communities, rather than beginning and ending with OpenStack. While the specific outcomes mentioned in the vision never happened, several efforts resulted in OpenStack having a more definite scope and place in the general technology landscape. Success of Kubernetes as an interoperable application deployment API helped position OpenStack more as an infrastructure provider. Our technical and non-technical experience was shared with adjacent communities like the cloud-native communities, but also with new open infrastructure projects under the OSF. The third part, "Embracing Community Diversity", is probably where we've seen the less progress in the last 3 years. It describes efforts to get a more diverse contributor base and TC representation. I feel like we still have a long way to go in that area, although things are gradually improving: we have seen more and more users of OpenStack step up and lead project teams, we are also seeing people with more of an operator background be elected to the TC, and this year the TC saw its first APAC-based member. The last part of the vision, "Growing New Leaders" describes facilitating inter-project work. Several initiatives have been put in place in that area since 2017. Community goals[5], SIGs[6], and more recently pop-up teams[7] (a concept which was described in the vision) all try to facilitate forming cross-disciplinary groups to advance complex inter-project issues in OpenStack. In summary, little of the specific plans described in the vision have actually been put in place, and the topics mentioned in there are all still work in progress. That said, the vision was a useful exercise in that it defined areas of focus for the TC stewardship of the community, and it did definitely inspire several of the plans we put in place those last 3 years. It was a time-consuming exercise though, so I'm not sure we should go through that exercise again and painting a vision for 2023. Comments, thoughts? [2] https://governance.openstack.org/tc/reference/technical-vision.html [3] http://www.openstack.org/openstack-map [4] https://opendev.org/osf/openstack-map/ [5] https://governance.openstack.org/tc/goals/index.html [6] https://governance.openstack.org/sigs/ [7] https://governance.openstack.org/tc/reference/popup-teams.html -- Thierry Carrez (ttx)

2 1

[Security SIG] Security SIG Newsletter - December 2019
by Gage Hugo 13 Dec '19

13 Dec '19

Hope everyone is having a good December so far, here's the update for this month from the Security SIG. Starting this month, this newsletter will be released on a monthly basis rather than a semi-weekly due to the sporadic activity and my availability. Also just a heads up, the next two weeks of meetings will be canceled for the Security SIG, we will resume on Jan 02nd. Have a Happy Holidays everyone! #Month Dec 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Updates - https://bugs.launchpad.net/keystone/+bug/1855080 was reported and a corresponding OSSA was released - This newsletter to be moved to a monthly release, rather than semi-weekly. #VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - OSSA-2019-005 was released: https://security.openstack.org/ossa/OSSA-2019-006.html

1 0

[openstacksdk][nova] distinguish image and boot from volume instances
by Blom, Merlin, NMU-OI 13 Dec '19

13 Dec '19

Hey, I wrote a function for distinguishing an image instance from an boot from volume instance for billing purpose. But it does not work this way, it seems as if BfV Instances also have the Image property set. Is there an elegant solution other than analyzing the volume attachment state? This cloud be a problem, because an image instance cloud also have volumes. def getBootFromVolInstances(serverId): '''Determines wether an instance is a boot frome volume instance''' server = conn.compute.find_server(serverId, ignore_missing=True) if server: if server.image: return False else: return True return False Merlin Blom Cloud System Engineer E-Mail: <mailto:merlin.blom@bertelsmann.de> merlin.blom(a)bertelsmann.de <https://www.arvato-systems.de> arvato-systems.de

3 3

Finding configuration values
by Albert Braden 13 Dec '19

13 Dec '19

This thread consists of 6 emails, all from me: http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011465… This illustrates a problem I've seen in Openstack. Many of the configuration settings are undocumented, or the documentation is obscure. The only way for an openstack operator to know the correct setting is to be told by an openstack developer. Sometimes I get lucky and someone tells me the answer on IRC, or here on the list. Sometimes nobody does, and then it seems that I am stuck. I have to keep bugging the developers until they tell me the answer. In this case, after searching for a week, I opened a Neutron bug, and then one of the Neutron developers told me how to fix my config. What am I doing wrong? Is there a document I should be reading, that tells how to configure openstack? Why are there no answers in #openstack? Does everyone else have this same issue, or is it only me? How can Openstack operators find out how to configure Openstack, besides begging the developers for the answer?

4 5

[neutron] Drivers meetings cancelled
by Slawek Kaplonski 13 Dec '19

13 Dec '19

Hi neutrinos, As there is Christmas holidays season comming, we decided on today’s drivers meeting, we will cancel next meetings this year. We will meet as usual on January 10th. Happy holidays and see You all in January :) — Slawek Kaplonski Senior software engineer Red Hat

1 0