- openstack-discuss - lists.openstack.org

[OSH][Infra] Open UDP port 111 on test nodes
by Clark Boylan 18 Dec '19

18 Dec '19

Hello, One of our contributing test node clouds has discovered that occasionally one of our test nodes will have udp port 111 open. The concern with this is that the RPC portmap service can be used in reflection DDoS attacks. Upon further investigation we've discovered that this seems to happen in OSH jobs (like openstack-helm-multinode-temp-ubuntu) [0] that run OSH's setup-firewall role [1]. These jobs do indeed disable the host firewall which would leave any running port mapper service exposed. It looks like these jobs run with multiple nodes in their nodeset, but do not use the multinode base job. I point this out because the multinode base job aims to set up networking and firewalls such that the nodes can talk freely among themselves while still blocking out the outside world. If we need to enable network communicate between hosts in these jobs this seems like a good place to start. That said there is a good chance that kubernetes may need additional open traffic. Additionally, I expect those specific depend on the CNI plugin that has been chosen? >From an infrastructure perspective we'd like to be good stewards of the resources donated to us and in this case that means preventing unwanted network traffic. We are more than happy to help set up more appropriate firewall rules if we can get details on what is needed. I expect the Zuul project is also interested and we can bake some of these common network needs for kubernetes into Zuul's zuul-job standard library. Can the OSH project work with us to fix this problem? Perhaps other kubernetes users/devs/operators can chime in on how they have reconciled host firewalls with kubernetes network needs? Any help that can be provided here would be much appreciated. [0] http://zuul.opendev.org/t/openstack/build/6fc5285fdb76484b894f0d288facdbb2/… [1] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/roles/… Thank you, Clark

2 1

[all] Volunteer mailing list administrators
by Jeremy Stanley 17 Dec '19

17 Dec '19

This is a long-overdue request. It's been more than a year since we combined openstack, openstack-dev, openstack-ops, openstack-sigs, openstack-tc and a number of other lower-traffic mailing lists into this new openstack-discuss mailing list. In that time, I've been serving as the sole administrator and moderator for the combined list. As I'm about to take an extended vacation away from regular Internet access for the first time since the list migration, I will be unable to check the moderation queue on a daily basis, and so would appreciate a bit of help from some of you. If there's anyone interested in helping out as additional administrators for the openstack-discuss mailing list, please reply to this message on-list (so other subscribers know who is volunteering) and I'll help bring you up to speed. In the immediate term I need at least one person willing to check the moderation queue a few times in the second half of December while I'm unavailable (daily would be awesome but a couple times a week is probably fine really). If you're expecting to be around and able to help with that, please respond on Monday or Tuesday of this week and I'll sync up to get you a copy of the Mailman administrator password for it and a quick walk-through of the moderator interface (if you already moderate other Mailman lists, all the better!). Moderation queue volume is typically on the order of twenty to fifty messages a day, most of which are spam of course, but one or two a day on average are legitimate messages either from non-subscribers with a question or sometimes slightly over the size limit because of attached logs. The spam and non-spam are pretty easy to tell apart if you've been around our community for a while: if the subject of the message has a recognizable topic tag in it or mentions the name of some OpenStack project then it's quite likely legitimate and can be approved. Spam on the other had usually either has a subject which is not in English (the required language for messages to this list) or is clearly someone selling something or running a scam. When in doubt though, you can quickly check the message body to be sure. I tend to spend at most 5 minutes a day looking through the moderation queue (and usually far less). Longer term, I'd like to see anywhere between 3-5 admins for the openstack-discuss list. No need to coordinate workload or vacations that way, we can just each check the queue when we think about it and that should be plenty often. Also while keeping on top of the moderation queue is the primary need, it would be great for these folks to know/learn a bit about how Mailman mailing lists are configured and how to troubleshoot them from the WebUI and message headers. Better still, if anyone wants to get even more involved, the OpenDev sysadmins would always welcome new recruits willing to help manage and run our mailing list servers and our infrastructure overall, I'm happy to make introductions! -- Jeremy Stanley

8 14

[nova][metadata] EC2 compatible metadata deprecation
by Mikhail Fedosin 17 Dec '19

17 Dec '19

Hello! In the documentation I noticed that EC2 metadata may soon be removed from Nova [1]. Currently, we use EC2 metadata in our product to obtain public and private IP addresses, as well as the instance-type (flavor). Therefore, I would like to ask you a couple of questions. 1. Do you plan to ensure compatibility before removing EC2 metadata from the system, i.e. to add these fields to the OpenStack metadata, which is not yet available? 2. When is it expected that EC2 metadata will be removed from the system? Best regards, Mikhail Fedosin [1] https://docs.openstack.org/nova/latest/user/metadata.html#general-guidelines

5 6

[ops] openstack ops meetup team meeting 2019-12-17
by Chris Morgan 17 Dec '19

17 Dec '19

Meeting minutes from today's meeting of the openstack ops meetups team on #openstack-operators : Meeting ended Tue Dec 17 15:35:22 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:35 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:35 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:35 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… the next meetup is in London on Jan 7,8 and registration is still open ( https://go.bloomberg.com/attend/invite/openstack-operators-meetup-london202… ) Regular updates on meetups are posted to the notification twitter account (see https://twitter.com/osopsmeetup) There will be an openstack ops meetup at the next summit (rumored to be in vancouver) and then later in 2020 in south korea. See the above-linked minutes for more details. Chris Morgan (on behalf of the openstack ops meetups team) -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[Neutron][QoS] Next IRC QoS meeting 14/1/2020
by Rodolfo Alonso 17 Dec '19

17 Dec '19

Hello Neutrinos: We'll cancel next QoS meeting and meet again on the 14th of January. Happy holidays to all! Regards.

1 0

[kolla] Kolla and Kolla Ansible 9.0.0 released for Train
by Mark Goddard 17 Dec '19

17 Dec '19

Hi, I'm pleased to announce the availability of the Kolla and Kolla Ansible 9.0.0 releases for the Train cycle! Train brings a number of interesting new features, including Masakari and Qinling support, the ability to deploy multiple Nova cells and TLS encryption of the internal API network. Full details are in the release notes which are available here: https://docs.openstack.org/releasenotes/kolla/train.html https://docs.openstack.org/releasenotes/kolla-ansible/train.html We anticipate significant changes during the Train release series to support a migration to CentOS 8. We will communicate which releases are affected. The first official release of kolla-cli should be available in the next few days. Release notes will be available here: https://docs.openstack.org/releasenotes/kolla-cli/train.html The first official release of Kayobe is making some finishing touches, and should be released by the end of the year, or early next year. Thanks to everyone who contributed to this release, it adds a lot of useful features. A great way to end the year. Cheers, Mark

1 0

[goals][Drop Python 2.7 Support] Week R-22 Update
by Ghanshyam Mann 17 Dec '19

17 Dec '19

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" for R-22 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… * I am adding this in Ussuri schedule page[1] Highlights: ======== * We crossed the Milestone-1 and with that, we are in phase-2 of py2 drop which targets all the common libraries and testing tools can start dropping the py2 support. * All the services should drop the py2 but this time. Patches are already up, review and merge them before gate starts failing due to cross projects py2 drop. * I pushed the patches on specs repo to cleanup py2 specific requirement or tox or zuul changes. many projects were running 'openstack-tox-py27' which I have changed to 'openstack-tox-pep8' instead of moving them to py3. pep8 job is enough for Specs repo. * I saw many spec repo failing their docs job due to oslosphinx and incompatible version of yasfb[2]. We need to fix this along with py2 drop patches if existing spec repo running py2 job. NOTE: Phase-2 is for Library (including client library), QA tooling. Phase-3 is mainly for openstack/requirement and audit to all repo. (we can always adjust the schedule to make it smooth migration. For example, dropping a few testing jobs from phase-2/3 candidates if any cross-testing jobs are failing due to phase-1 candidates dropping the support[3].) Summary: ======= The OpenStack services have not merged the py2 drop patches: * Adjutant * Barbican * Designate * ec2-api * Glance * Neutron (stadium projects) * Freezer * Kolla * Karbor * Congress * Storlets * Sahara * Blazar * Masakari * Tacker * Trove (trove-dashbaord patch is not mergd) * Zaqar * Qinling * Tricircle * openstack-helm * python-openstackclient How you can help: ============== - Review the patches. Push the patches if I missed any repo targetted for phase-1. [1] https://review.opendev.org/#/c/699008/ [2] https://review.opendev.org/#/c/698998/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011392… [4] https://review.opendev.org/#/q/topic:drop-py27-support

3 3

[neutron][devstack] Future of lib/neutron and lib/neutron-legacy
by Slawek Kaplonski 17 Dec '19

17 Dec '19

Hi, Few years ago (I don’t know exactly when it started as I wasn’t very active upstream than for sure) Neutron team started work on new neutron module for Devstack. See [1] for details. But since then this new module is still not ready to use. For example in gate jobs we are still using lib/neutron-legacy module as this new one is always causing some problems. Things in its current shape may be confusing for new Devstack users as in fact to deploy Neutron properly they should use lib/neutron-legacy instead of lib/neutron now. Personally I never really checked exactly what issues are there in fact but I do remember some issues with using lib/neutron e.g. on subnodes in multinode jobs - see [2]. So I would like to ask a question what do You think we should do with it. Is there maybe any volunteer who would like to continue this work on adopting lib/neutron and to finally use it in gate jobs? Or if there is no anyone and we are all fine with using old module, maybe we should remove this lib/neutron and “undeprecate” and rename lib/neutron-legacy? [1] https://github.com/openstack/devstack/commit/2a242519f71e86416e78541826cac2… [2] https://review.opendev.org/#/c/662480/ — Slawek Kaplonski Senior software engineer Red Hat

3 2

Re: [OpenStack Foundation] [tc][board][all] - Adding OpenStack community support to the savedotorg campaign
by Graham Hayes 17 Dec '19

17 Dec '19

On 26/11/2019 16:44, Alan Clark wrote: > Who owns savedotorg.org? I see EFF references on the page but when I look it up the domain it appears to all be "REDACTED". >From https://savedotorg.org/index.php/about/ - it is ran by NTEN (https://www.nten.org/) It is supported by the EFF (among others) > >> -----Original Message----- >> From: Graham Hayes [mailto:gr@ham.ie] >> Sent: Tuesday, November 26, 2019 9:35 AM >> To: Jimmy McArthur <jimmy(a)openstack.org> >> Cc: openstack-discuss(a)lists.openstack.org; foundation- >> board(a)lists.openstack.org; foundation(a)lists.openstack.org >> Subject: Re: [OpenStack Foundation] [tc][board][all] - Adding OpenStack >> community support to the savedotorg campaign >> >> On 26/11/2019 16:16, Jimmy McArthur wrote: >>> From my reading of the situation, it’s a done deal. It seems like ICAAN just >> crammed it through. Is there new info out that could reverse it? >>> >>> Thanks, >>> Jimmy >> >> My understanding is it looks bleak, but there is a chance to shame the owners >> into halting the sale. >> >> I think ICAAN can still block the same (until December 13th, 30 days after they >> were notified), and through pure poor marketing, and raising our voices, this >> could help convince the current owners of PIR (who is ISOC) to re-consider the >> idea. >> >> >>>> On Nov 26, 2019, at 8:50 AM, Amy <amy(a)demarco.com> wrote: >>>> >>>> I agree with the OSF submitting on behalf of OpenStack and the other projects. >> I also like the idea of individuals signing as contributors. >>>> >>>> Amy Marrich (spotz) >>>> >>>>>> On Nov 26, 2019, at 8:17 AM, Sean McGinnis <sean.mcginnis(a)gmail.com> >> wrote: >>>>>> >>>>>> On Tue, Nov 26, 2019 at 7:00 AM Graham Hayes <gr(a)ham.ie> wrote: >>>>>> >>>>>> Hey All, >>>>>> >>>>>> I am not sure if this has been seen by everyone or not - but there >>>>>> is a change in how the .org top level domain is being ran in the >>>>>> works, in a way that may not be in the best interests of the non >>>>>> profits that it was created to facilitate. [1] >>>>>> >>>>>> A lot of well known non profits have already joined, and as a >>>>>> community that has an interest in the internet as a whole, and uses >>>>>> a .org domain, I think we should add our voice in support. >>>>>> >>>>>> What do people think? Are we happy to have the TC use its voice on >>>>>> behalf of the OpenStack project, or do we think the board should >>>>>> use its voice on behalf of the entire foundation? >>>>>> >>>>>> - Graham >>>>>> >>>>>> >>>>>> 1 - https://savedotorg.org/ >>>>>> >>>>> >>>>> I agree this is a Foundation level thing (though individuals can add >>>>> their names to the petition as well). I would support adding OSF to >>>>> the list of organizations. >>>>> >>>>> Sean >>>>> >>>> >>>> _______________________________________________ >>>> Foundation mailing list >>>> Foundation(a)lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation >>> >> >> >> _______________________________________________ >> Foundation mailing list >> Foundation(a)lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

5 6

[tc] Follow up on action tems
by Jean-Philippe Evrard 16 Dec '19

16 Dec '19

Hello TC members, - There are still business opportunities merging for 2019. The process for 2020 need to start soon. Any takers? - We have pending action items from the last meeting: - ricolin: contact to Infra team to see if we got more ARM server in our Nodepool - ricolin/ttx: track the merger of the SIGs self-healing and auto- scaling - mnaser: static hosting story: Is it restarting? Where are we now? - ttx: Work on technical vision reflection update - ricolin/evrardjp: Expect/Request an update from Telemetry team. As mentioned in our channel [7], Rong Zh (PTL for Telemetry) will provide a Telemetry status report (high chance to send it out next week). - jungleboyj: analysis of the user survey. The patch is out for TCs to review [6] - ttx: make sure to start the discussion about uc/tc merge in January after the ops meetup - mnaser: write documentation in governance to clarify what was discussed about stable policy - We have new action items: - We need to update our charter for the election terms, to be more flexible. Who is okay with starting this? - We have plenty of things which are not reviewed, or WIP. Could you update (y)our patches please with either changes or votes? - aprice has asked me (JP) to write a report for the TC and SIG activities of 2019. If you want to know what I am cooking, or want to help on the text, please join here [5] - In the next elections, we'll be reducing our (=TC) size temporarily due to the current elections timing proposal. In order to not have this happen again, we should propose a charter change as soon as possible. Can someone tackle this? Please see the conversations here [1] and here [2] - We still have long action items from PTG: - For community goal `Drop Python 2.7 Support`, you can find the status update on the ML [9]. React there if you need. - The community goal `project specific PTL and contributor guides` proposal patch is under review [8] and will be merged soon. - gmann is sending an official goal schedule plan [3] . We need TC members to review this as well, as soon as possible. We also need to discuss when should we start the first step for next cycle in schedule during next meeting (if/when patch landed). - Please also review other patches, like [4] . And finally, some things to keep in mind: - We need to promote the first contact sig to organisations that might need help on getting things achieved in OpenStack. Regards, JP & Rico [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011396… [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011155… [3] https://review.opendev.org/#/c/698299 [4] https://review.opendev.org/#/c/691737 [5] https://etherpad.openstack.org/p/2019-openstack-foundation-annual-report-dr… [6] https://review.opendev.org/#/c/698582/ [7] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019… [8] https://review.opendev.org/#/c/691737 [9] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011432…

2 2

[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 15 Dec '19

15 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

Upgrade: Juno -> Pike (or maybe later)
by Ken D'Ambrosio 13 Dec '19

13 Dec '19

Hey -- I've run a number of OpenStack clouds from multiple vendors for several years, now. But I've *never* done an upgrade. I've read some of the docs, but they don't really make it clear (at least, the ones I've thus-far found): * If going from Juno to something pretty recent is even feasible * If I have to do intermediate steps along the way * How likely it is to "just work:" complexity, common issues, etc. The fact that there's a clearly codified fallback procedure, while an inherently good thing to have, does concern me some. Any insights would be much appreciated. Thanks! -Ken

5 4

[all][tc] What happened in OpenStack Governance recently
by Jean-Philippe Evrard 13 Dec '19

13 Dec '19

Hello folks! We've finally made up our mind with the release naming process. We got a majority of the TC voting positively for a simplified release naming process [0]. Talking about naming, V-release naming poll already started [6]. Go pick your favorit now! Voting will officially end December 16, 2019 at 23:59 UTC! So... pick now! Thanks for Colleen Murphy (cmurphy) and Ghanshyam Mann (gmann) starting a policy pop up team [2]. Please raise your hand if you're interested to participate. devstack already migrated to Python3 and most of our non-python2 specific jobs are also migrated. Your test jobs (like grenade jobs) could need migration, like [1]. Also, if you want to know a full status update of the `Drop Python 2.7 Support`, you can find the status update in [9]. The ansible-sig has new repositories! ansible-collections-openstack [4], ansible-plugin-container-connection will be joining soon [5] There is a new charm charm-cinder-backup-swift-proxy [3] SIG guideline [8] is landed, so if you're maintaining or starting a SIG. Please check it out and provide your feedback to make it getting better. Thanks to Graham Hayes, the last OpenStack Foundation board meeting has officially approved to the savedotorg campaign [7]. Have a good week-end, enjoy your end of year holidays (assuming you have some soon), and merry Christmas/happy new year for those who celebrate them! :) Regards, JP & Rico [0] https://review.opendev.org/#/c/695071/3 [1] https://review.opendev.org/#/c/695088/ [2] https://governance.openstack.org/tc/reference/popup-teams.html#secure-defau… [3] https://review.opendev.org/696723 [4] https://review.opendev.org/684740 [5] https://review.opendev.org/696737 [6] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011477… [7] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011155… [8] https://governance.openstack.org/sigs/reference/sig-guideline.html [9] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011432…

1 0

[nova] live migration with the NUMA topology
by Brin Zhang(张百林) 13 Dec '19

13 Dec '19

Hi folks:: About http://specs.openstack.org/openstack/nova-specs/specs/train/approved/numa-a… this spec in Train. I have a question, if the destination server's NUMA topology (e.g. nume_node=2) < source server's NUMA topology (e.g. numa_noed=4) in a instance. If I am living migration *this* instance, what will be happened? Rollback and keep the instance to the original status? Or make it to ERROR? In that SPEC I had not find the details about the red description in "Third, information about the instance’s new NUMA characteristics needs to be generated on the destination (an InstanceNUMATopolgy object is not enough, more on that later)", or lack of careful reading :). Anyway, I want to know how to deal with this NUMA topology during live migration? Thanks.

3 3

[dev] Counting the chaff
by Jeremy Stanley 12 Dec '19

12 Dec '19

It happens with some regularity that I or others are asked for code change volume numbers on OpenStack to compare its activity level against similar numbers published by other open-source projects, and I pretty much always wind up needing to couch my answers with the fact that commit counts published by projects following different workflows aren't directly comparable. Most often, these other projects employ an additive pull request model common to GitHub and similar platforms, which causes many times more commits to appear in their branch histories than happens with a rebase or squash model. (Note that there *are* plenty of high-profile projects on GitHub like Kubernetes using more of a rebase model, with PR owners typically force-pushing changes to address reviewer comments or CI results, and also projects where it's their custom to squash all commits in a PR before merging, so in those cases our normal change counts are more applicable for ~1:1 comparisons.) In order to be able to provide more useful data, I decided to try and find a way of approximating the "chaff" we discard when we merge the "wheat" of our rebased code changes. The Gerrit API provides information on the revision count for changes, so adding the number of revisions for each merged change basically gives us the answer. OpenStack's election tooling already tallies counts of changes merged, so adding an aggregate revision counter to that was fairly trivial: https://review.opendev.org/698291 A word on merge commits: While a direct count of Git commits will be additionally inflated by the merge commits used to stitch changes into a branch, and approach a 1:1 ratio with the number of changes merged in higher-volume projects (except possibly in projects squashing or cherry-picking/rebasing at merge time), GitHub's commit counts explicitly exclude merge commits in order to provide more useful metrics, therefore we don't need to factor them into our calculations: https://developer.github.com/v3/repos/statistics/#statistics-exclude-some-t… So with all that explanation out of the way (and thanks to those of you who read this far!), it's time for some numbers. Looking at the past five years, here's the breakdown... 1409697 revisions / 459770 changes ~= 3 Now this was calculated using the current OpenStack governance data so the exact change counts aren't official numbers because they could include data from a slightly different set of Git repositories than were official in those years, but the goal of this exercise was to obtain a rough coefficient so I think that's a reasonable simplification. This "GitHub coefficient" of 3 is then a number by which OpenStack change volume can be multiplied to provide a rough approximation for comparison with activity numbers for projects following the common GitHub iterative PR workflow (at least for projects which see similar levels of PR updating to OpenStack's change revision frequency). Out of curiosity, I also took a look at how that coefficient has evolved over time... 2015: 3.35 2016: 3.12 2017: 3.05 2018: 2.77 2019: 2.76 It's interesting to note that OpenStack's overall chaff-to-wheat ratio has been trending downward. This could be due to a number of factors. Are contributors getting better instruction and feedback to help them understand what reviewers expect? Is our project gating automation catching more errors and wasting less developer time on each change? Are reviewers possibly becoming more lax and fixing nits in subsequent changes rather than demanding more revisions to otherwise "good enough for now" changes? Are we seeing a rise in projects with lower affiliation diversity resulting in changes merging with minimal or no review? It could be any or all of these. I tried to dig back even farther to see if this pattern was consistent. What I found, in retrospect, should perhaps not be all that surprising... 2011: 1.79 2012: 2.12 2013: 2.72 2014: 3.18 Okay, so 2011/2012 are much lower, perhaps because contributors were still for the most part getting used to the ideas of code review and pre-merge testing in the first few years of the project. The data we have in Gerrit about this earlier period is also somewhat less reliable anyway, but it's worth pointing out that the curve for revisions-per-change roughly follows the curve for total change volume (peaking around 2014-2016). So maybe the answer is that when we try to move faster we become less efficient? Additional rebases due to a higher incidence of merge conflicts could be an explanation there. The patch which adds revision counting makes it possible to calculate change revisions for deliverables of different teams as well. These are the five teams with the highest and five with the lowest coefficients for this year... 12.5: I18n 5.58: Nova 5.33: OpenStack Helm 5.15: Cyborg 4.27: Storlets ... 1.74: SIGs (constructed "team" encompassing all SIG-owned repos) 1.73: Murano 1.64: Release Management 1.56: Puppet OpenStack 1.56: Requirements You can of course draw all sorts of conclusions from a comparison like this. Clearly there's something about the I18n team's changes which result in a very high revision count, but it's not immediately clear to me what that is (they only have a two repositories, one of which is basically unused and the other mostly just merges infrequent bot-proposed changes). It's also possible that the Nova team's reputation for being thorough reviewers is a well-deserved one. On the other hand some teams like Release Management and Requirements with well-structured, policy-oriented changes tend to merge at the first or second iteration on average. Hopefully some of you find this useful. For me, it's an interesting way to see evidence of some of the additional work our community is doing when it comes to making changes to its software, which isn't necessarily evident from the basic change counts we normally see published. It likely raises more questions than it answers, but I think the introspection it drives is also a healthy exercise for the community. One final note, I've got a trimmed-down and compressed archive of the data from which the above numbers were extracted I can forward to anyone wants to do their own digging, just let me know if you would like a copy. I was going to attach it to this analysis but that would have resulted in a >300KB message to the mailing list, so I thought better of that plan. -- Jeremy Stanley

4 4

[nova] No more meetings til 2020
by Eric Fried 12 Dec '19

12 Dec '19

Next nova meeting is January 2nd (2100 UTC), though I don't expect it to be heavily attended. efried .

1 0