December 2019 - openstack-discuss

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

17 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 16 Dec '19

16 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 16 Dec '19

16 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