- openstack-discuss - lists.openstack.org

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

19 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 19 Mar '19

19 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 19 Mar '19

19 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

[glance][swift][devstack] Glance with Swift backend how to specify CACERT
by Vladislav Kuzmin 18 Mar '19

18 Mar '19

I found this comments in devstack https://github.com/openstack-dev/devstack/blob/master/lib/glance#L180-L181 and I'm trying to reproduce this not implemented behavior, because I want to implement it with CACERT. > # NOTE(dims): Currently the glance_store+swift does not support either an > insecure flag > # or ability to specify the CACERT. So fallback to http:// url I installed devstack with the following local.conf file: > [[local|localrc]] > ADMIN_PASSWORD=supersecret > DATABASE_PASSWORD=$ADMIN_PASSWORD > RABBIT_PASSWORD=$ADMIN_PASSWORD > SERVICE_PASSWORD=$ADMIN_PASSWORD > enable_service tls-proxy > enable_service s-proxy s-object s-container s-account > SWIFT_REPLICAS=1 > SWIFT_HASH=1234123412341234 > USE_PYTHON3=True > HOST_IP=10.0.2.15 After that I changed http to https in /etc/glance/glance-swift-store.conf for auth_address and restarted g-api service. In the next step I upload an image, but everything working good. Does anybody know how to reproduce it with CACERT ?

1 0

[nova] Project key pair handling (was Re: [nova] Does anyone remember why server_group_members quota is enforced at the user rather than project level?)
by Tim Bell 17 Mar '19

17 Mar '19

We also encounter this problem when a user creates a VM in a project (with multiple project administrators) and the user then leaves CERN. This then means the user's keypair is removed. Not sure what the best solution for this is but having a project keypair list which could contain keypairs for the project administrators would be interesting possibility. However, adding new administrators (and updating the keypair list) is not obvious. (I'd also be in favour of no per-user quotas, BTW) Tim -----Original Message----- From: Lance Bragstad <lbragstad(a)gmail.com> Date: Thursday, 14 March 2019 at 16:16 To: <openstack-discuss(a)lists.openstack.org> Subject: Re: [nova] Does anyone remember why server_group_members quota is enforced at the user rather than project level? On 3/14/19 9:18 AM, Zane Bitter wrote: > On 13/03/19 5:28 PM, Chris Friesen wrote: >> On 3/13/2019 8:41 AM, Jay Pipes wrote: >> >>> Yep, and IMHO, keypairs is the one and only valid user-specific limit. >> >> Even that is a bit sketchy, since instances are owned by projects. > > Came here to say this :) > > I assume the reason is that it allows a user to upload their public > key once and use it in every project they are a member of. That's > nice, but IMHO not worth the pain of having one thing in OpenStack > that is scoped completely differently to everything else. > >> Currently if a user starts up an instance and then leaves without >> sharing the keypair, other users in the same project would >> potentially need to rebuild the instance to update the keypair before >> they can log in to it. > > It's an even bigger problem for Heat because we have an > OS::Nova::Keypair resource but everything breaks if a different user > updates the stack, because the keypair that Heat created suddenly > becomes invisible. > >> I think an argument could be made that keypairs should be owned by >> projects, and users should get allocated single-user projects for >> instances they want to keep private. > > Even that is irrelevant as far as keypairs are concerned. Let's not > kid ourselves that there's any "pair" involved in a keypair. You can > create one without providing the private key, and if you do have Nova > generate a private key, it doesn't store it. So a 'keypair' is > actually just a public key. If a user has an instance they don't want > other people to log into, they should not share their private key with > anyone, end of story. I agree that you shouldn't need another project if password authentication is disabled on the server and keep private keys private. I can think of a use case that I find useful and have needed in the past that would be easier with public keys being project-scoped. As a team of developers, we had access to a project and we mostly used it for development instances. Often times we would want to debug things together on the same server, or peer program (remotely using ssh/mosh + tmux + $EDITOR). To do this, I'd add all the public keys for my team to the project, but I was the only one who could view them. If someone else joined the team, I'd need to get their public key and import it (along with anyone else on the team). My team members likely had their public keys associated to the project already for their own development instances. If things like public keys were project-scoped, I could specify a list of public keys associated to the project when I create the server. Then, I only need to manage my public keys but I get access to public keys associated to the project without having to bloat my own key pair quota. Sorry for a tangent on public keys when this thread is specific to server_group_members, but comments about key pairs tripped that use case for me. > > (Obviously if you don't want other users to be able to update/delete > the server through the Nova API then it should be in a project that no > other users have permissions for. But this is true independently of > the scope of keypairs.) > > cheers, > Zane. >

1 0

[ptg][neutron] PTG planning
by Miguel Lavalle 17 Mar '19

17 Mar '19

Hi OpenStackers, The Train cycle PTG , scheduled for May 2 - 4, is fast approaching. As a consequence, I have started the following etherpad to kick off the OpenStack Networking family of projects brainstorming on the topics we want to discuss in Denver: https://etherpad.openstack.org/p/openstack-networking-train-ptg Please add your name at the top of the etherpad if you are attending the PTG, along with your irc handle and whether you are attending the team social event on the evening of May 3rd. Feel free to propose topics whether you are attending or not the PTG. In either case, add your name and irc handle next to the proposed topic, along with enough background information so the discussion can start and move along. At this point, the format for topics is completely free. As we get closer to the PTG date, we will organize the topics in the format of an agenda. Best regards Miguel

1 0

[dev][keystone] Keystone Team Update - Week of 11 March 2019
by Colleen Murphy 16 Mar '19

16 Mar '19

# Keystone Team Update - Week of 11 March 2019 ## News ### RC1 As mentioned in the latest release countdown email[1], RC1 and stable/stein will be cut next week. I've targeted some bugs in our backlog for RC1[2]. Development effort should be focused on these bugs. Please also report Stein regressions ASAP if you find any. While it may not be feasible to close all of these by RC1, we still have time for an RC2 if we need. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003851.ht… [2] https://launchpad.net/keystone/+milestone/stein-rc1 ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 19 changes this week. This includes some of the base work for application credential access rules, although we are postponing merging the API changes for that work until Train. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 34 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. This includes several changes to implement domain-reader policies for some APIs which require a change in tempest[3]. [3] https://review.openstack.org/642102 ## Bugs This week we opened 4 new bugs and closed 4. Bugs opened (4) Bug #1819957 (keystone:High) opened by Morgan Fainberg https://bugs.launchpad.net/keystone/+bug/1819957 Bug #1819299 (keystone:Low) opened by sam.lee https://bugs.launchpad.net/keystone/+bug/1819299 Bug #1819453 (keystone:Undecided) opened by James Page https://bugs.launchpad.net/keystone/+bug/1819453 Bug #1819957 (keystonemiddleware:High) opened by Morgan Fainberg https://bugs.launchpad.net/keystonemiddleware/+bug/1819957 Bugs closed (1) Bug #1754723 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1754723 Bugs fixed (3) Bug #1816927 (keystone:Low) fixed by Pavlo Shchelokovskyy https://bugs.launchpad.net/keystone/+bug/1816927 Bug #1819299 (keystone:Low) fixed by Chason Chan https://bugs.launchpad.net/keystone/+bug/1819299 Bug #1718945 (keystonemiddleware:High) fixed by Tin Lam https://bugs.launchpad.net/keystonemiddleware/+bug/1718945 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html Next week is RC1 target week. ## Shout-outs Thanks to Lance for being a great PTL for all these years :) ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0