March 2019 - openstack-discuss - lists.openstack.org

[ptl][release]Cycle Highlights Reminder-- Due This Week
by Kendall Nelson 18 Mar '19

18 Mar '19

Hello! Friendly reminder that cycle-highlights are due with your rc1. I realize there was a mix up with the stein schedule saying that they were due with your final rc's so there is a patch out to fix that now and I figured an email reminder couldn't hurt either way :) cycle-highlights are important because they are what the Foundation Marketing team (as well as other journalists,marketing folks, and industry outside the Foundation) processes into the press release that they will do for the Stein release. If you have any questions feel free to ask in the #openstack-release channel and we will be able to help you. There's also documentation here[1] that shows how they should be formatted. -Kendall Nelson (diablo_rojo) [1]https://docs.openstack.org/project-team-guide/release-management.html

1 0

[nova][dev] Train PTG etherpad available
by melanie witt 18 Mar '19

18 Mar '19

Hey all, We have an etherpad going for the Train PTG located here: https://etherpad.openstack.org/p/nova-ptg-train Please add topics you'd like to discuss in-person at the PTG, along with your IRC nick, to the topic list. If you're unable to attend the PTG but have a topic you'd like feedback about, you can add it with a note that you're unable to attend, and we can take notes on the etherpad for you to review after we go over the topic. Cheers, -melanie

1 0

[os-brick] Fix multipathd support when 'find_multipaths' is set to 'yes'
by Sahid Orentino Ferdjaoui 18 Mar '19

18 Mar '19

There is an issue in os-brick related to multipath support for iSCSI connector. Basically when multipathd is configured with feature 'find_multipaths' set to 'yes' #1815844 [0]. In this situation, multipathd automatically generate multipath device when it discovers: - There are at least two non-blacklisted paths with the same WWID. - The user manually forces the creation of the device by specifying a device with the multipath command. - A path has the same WWID as a multipath device that was previously created (even if that multipath device does not currently exist). Whenever a multipath device is created, multipath remembers the WWID of the device so that it will automatically create the device again as soon as it sees a path with that WWID. This situation happens as described in bug #1815844 [0] when we attach a volume, detach it and then re-attach it again. openstack volume create pure2 --size 10 --type pure openstack server add volume T1 pure2 openstack server remove volume T1 pure2 openstack server add volume T1 pure2 A patch has been proposed to fix the support [1]. Since we have workaround when 'find_multipaths' is set to 'no'. The question is: do we want to fix it? If not, I suggest to document it, that this feature from multipathd should be disabled. Probably a side-note in the config option 'volume_use_multipath' can help. We could also add a log warning in os-brick when we detect the issue. Thanks, s. [0] https://bugs.launchpad.net/charm-nova-compute/+bug/1815844 [1] https://review.openstack.org/#/c/638639/ [2] https://docs.openstack.org/nova/rocky/configuration/config.html#libvirt.vol…

2 1

[openstack-ansible] updating cores
by Mohammed Naser 18 Mar '19

18 Mar '19

Hi everyone, I wanted to thank the following cores for their service to the project, however, they don't seem to be active anymore and therefore I'd like to propose to remove them. However, should they decide to come back to the project, we'd be happy to fast track them in: - Alexandra Settle - Andy McCrae - Jimmy McCrory - Major Hayden - Robb Romans I'd like to propose to add Guilherme Steinmuller for core, he has done quite a lot of code reviews recently, worked on helping fix our upgrade jobs, did the initial work to help add placement and integrate Mistral into OpenStack Ansible. https://review.openstack.org/#/q/reviewedby:%22Guilherme++Steinmuller+Pimen… With the recent shrink of the OpenStack Ansible team, he'll help increase the bandwidth of getting code merged. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

8 8

Re: [heat] keystone endpoint configuration
by Zane Bitter 18 Mar '19

18 Mar '19

Sending to the list as I intended the first time... with edit to take into account new info from Rabi. On 27/02/19 5:29 PM, Jonathan Rosser wrote: > Conversely, heat itself needs to be able to talk to many other openstack components, defined in the [clients_*] config sections. It is reasonable to describe these interactions as being "Internal" - I may misunderstand some of this though. Yeah, that is reasonable, and in fact we give you the option in the config file to choose which set of endpoints to use from the catalog. But we assume that there is only one auth_url used to fetch the catalog. > So here lies the issue - appropriate entries in heat.conf to make internal interactions between heat and horizon (one example) work in real-world deployments results in the keystone internal URL being placed in callbacks, and then SoftwareDemployments never complete as the internal keystone URL is not usually accessible to a VM. Do you know which config options affect Horizon? It's surprising to me that anything in *Heat's* config would make a difference to Horizon. The only thing I can think of is that www_authenticate_uri might have to be on the internal network for Horizon to work, but Colleen already said that it should always be on the public network. And in any event it would be overridden for the purposes of signal URLs by setting [clients_keystone]/auth_uri to the public endpoint. > I suspect that there is not much coverage for this kind of network separation in gate tests. Yeah, I suspect only the deployment projects run tests with complex-enough networking setups to be able to verify this, and it's not their job to check that Heat supports this use case. > There are already examples of similar config options in heat.conf, such > as "heat_waitcondition_server_url" - would additonal config items such > as server_base_auth_url and signal_responder_auth_url be appropriate so > that we can be totally explicit about the endpoints handed on to created > VM? Yes, that's along the lines of what I was thinking too (although I think we'd only need one option, for URLs destined to be called from userspace). We already have an endpoint_type option (that defaults to PublicURL), so maybe we just need to be able to specify internal_auth_uri and public_auth_uri and we can select based on the endpoint type when we're using the clients internally, but always use the public one when gathering data to pass to a VM? [Edit: Rabi pointed out that X-Auth-Url is inserted by middleware, and gets its information from the same config options, so the following paragraph is a red herring.] Looking close at the code though, I wonder if part of the problem here is that we use the X-Auth-Url header from the request context whenever it is available (and only fall back to the config options when it is not), which should generally always be the public URL... but possibly is the internal URL if the request comes from Horizon... or Magnum?? In fact, I wonder if that could be the _whole_ problem in terms of the stuff you laid out at the beginning of the thread? Notwithstanding that there are still cases with completely isolated networks that cannot be covered by config options alone. e.g. as discussed in https://storyboard.openstack.org/#!/story/2004524 you can get the 'signal_url' attribute from OS::Heat::ScalingPolicy. That can either be passed to Aodh (should presumably use the internal auth URI) or e.g. given to a VM that might be running the user's own monitoring system (must use the public auth URI). The only way I can see to solve that would be to have separate 'internal_signal_url' and 'public_signal_url' attributes (are ordinary users even supposed to be able to see internal URLs in the catalog?). That's not an ideal experience for users since on the vast majority of clouds where the services are able to access external endpoints then the public URL will continue to work in either case (so extra work to figure out, and people will choose wrong leaving lots of non-interoperable templates floating around out there). But I guess it may be better than what we have now. cheers, Zane.

2 1

[neutron][dev] Pike Extended Maintenance coming soon
by Bernard Cafarelli 18 Mar '19

18 Mar '19

(shamelessly borrowed/inspired from nova mail) Hi Neutrinos, as mentioned in a similar nova email I shamelessly borrowed from, Pike Extended Maintenance is coming soon. Release page says 2019-03-03 but it will probably happen after the Stein release (2019-04-10): http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003745.ht… There were quite a few backports pushed to stable/pike in neutron since last release, so we should probably do a final one (I have not checked yet for neutron-lib and stadium projects). The review queue is in a short/good shape right now: https://review.openstack.org/#/q/status:open+project:openstack/neutron+bran… Please be sure you get your backports proposed that you'd like to land in the final Pike release. After Pike is put into extended maintenance, there will be no more releases, but patches will still be accepted to the branch: https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… (similar to what we did for Ocata release) Regards, -- Bernard Cafarelli

1 0

[oslo] Single approve stein branch patches
by Ben Nemec 18 Mar '19

18 Mar '19

If you've been on the IRC channel today you will see we have a flood of stable/stein patches. Since these are all bot-generated basic branch setup patches, let's single-approve them. Thanks. -Ben

1 0

[OSSA-2019-001] Unsupported dport option prevents applying security groups in OpenStack Neutron (CVE-2019-9735)
by Jeremy Stanley 18 Mar '19

18 Mar '19

========================================================================= OSSA-2019-001: Unsupported dport option prevents applying security groups ========================================================================= :Date: March 13, 2019 :CVE: CVE-2019-9735 Affects ~~~~~~~ - Neutron: <10.0.8, >=11.0.0 <11.0.7, >=12.0.0 <12.0.6, >=13.0.0 <13.0.3 Description ~~~~~~~~~~~ Erik Olof Gunnar Andersson with Blizzard Entertainment reported a vulnerability in Neutron's iptables firewall module. By setting a destination port in a security group rule along with a protocol which doesn't support that option (for example, VRRP), an authenticated user may block further application of security group rules for instances from any project/tenant on the compute hosts to which it's applied. Only deployments using the iptables security group driver are affected. Patches ~~~~~~~ - https://review.openstack.org/640791 (Ocata) - https://review.openstack.org/640790 (Pike) - https://review.openstack.org/640702 (Queens) - https://review.openstack.org/640685 (Rocky) - https://review.openstack.org/640619 (Stein) Credits ~~~~~~~ - Erik Olof Gunnar Andersson from Blizzard Entertainment (CVE-2019-9735) References ~~~~~~~~~~ - https://launchpad.net/bugs/1818385 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9735 -- Jeremy Stanley

1 0

[goal][python3] week R-3 update
by Doug Hellmann 18 Mar '19

18 Mar '19

This is the final update email for the python3-first goal for the Stein development cycle [0]. We have achieved several benefits by completing the goal this cycle. Our documentation, release notes, linter, and release artifact build jobs use python 3 by default, most projects have unit tests running under python 3.6, and most projects have some form of function or integration test using python 3 [1]. All of those allow us to move forward with allowing teams to drop python 2 support after the Train cycle [2]. Besides the python 3 benefits, teams have their Zuul settings in their repository, which relieves a lot of the review burden on the centralized infrastructure team and allows teams to more easily manage their test jobs. Thank you to everyone who contributed to writing and reviewing patches. The community put in an immense amount of work on this goal during Stein. We had over 4000 patches tagged "python3-first" created by 57 contributors and reviewed (and approved) by more than 200 reviewers. I would like to extend a special thank you to our goal champions, Nguyễn Trí Hải (nguyentrihai93(a)gmail.com) Ma Lei (ma.lei(a)99cloud.net) and Huang Zhiping (huang.zhiping(a)99cloud.net) for creating and shepherding so many of those patches. And also to Andreas Jaegar, Clark Boylan, and the rest of the infrastructure team for their assistance in planning the Zuul migration and reviewing so many of the patches. The work on this goal this cycle proves to me that when our community comes together and focuses on a problem, we can make the big changes necessary to solve it. Thank you, Doug As mentioned earlier [3], I have abandoned the python3-first patches that I proposed earlier this cycle and that have not been merged. They're still there in gerrit, so if you find you need them it should be possible for someone to recover them. I left the few patches created by other authors alone [4]. [0] https://governance.openstack.org/tc/goals/stein/python3-first.html [1] https://wiki.openstack.org/wiki/Python3#Python_3_Status_of_OpenStack_projec… [2] https://governance.openstack.org/tc/resolutions/20180529-python2-deprecatio… [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003693.ht… [4] https://review.openstack.org/#/q/topic:python3-first+is:open

1 0

[manila] Stein rc bug scrub meeting
by Tom Barron 18 Mar '19

18 Mar '19

We have six bugs targeted for rc1 [1], i.e. for this coming Thursday, 21 March 2019. Tuesday at 1630 UTC we'll synchronize in #openstack-manila to scrub these and retarget any that won't be fixed in time. If you want to nominate any other bugs for rc let me know right away and I'll add them to the etherpad. If you own one or more of these bugs please come to the meeting Tuesday or send me status update by then. Thanks! -- Tom Barron

2 2