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

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

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

16 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

Re: [Release-job-failures] release-post job for openstack/releases failed
by Thierry Carrez 15 Mar '19

15 Mar '19

zuul(a)openstack.org wrote: > Build failed. > > - tag-releases http://logs.openstack.org/5c/5ce46e390be04b19145d1f316e8283c09abb628d/relea… : POST_FAILURE in 3m 15s > - publish-tox-docs-static publish-tox-docs-static : SKIPPED Issue: ------ All release post-jobs today had a failure in the cleanup phase while cleaning up the signing keys. The 'shred -u ~/.gnupg/*' command fails with: shred: /home/zuul/.gnupg/private-keys-v1.d: failed to open for writing: Is a directory It is likely due to the switch to use bionic hosts for trusted release jobs. Impact: ------- The tagging happens before that failure, so the release itself is not impacted. It does prevent the documentation post-job from running though, so releases.openstack.org is currently out of date. -- Thierry Carrez (ttx)

2 2

[requirements][ffe][os-brick] Need an exception for os-brick please ...
by Jay Bryant 15 Mar '19

15 Mar '19

Requirements team, We, unfortunately, found some more last minute issues with os-brick. It required yet another release. We are currently working to determine if the version should be 2.8.1. The patch requesting that is here: [1] We also need to ensure that 2.8.0 is not used by anyone. Eric has a patch for that here: [2] Sorry for the trouble late in the game here. Thanks for your help! Jay [1] https://review.openstack.org/#/c/643588 [2] https://review.openstack.org/#/c/643065

2 1

[neutron] Cancelling drivers meeting
by Miguel Lavalle 15 Mar '19

15 Mar '19

Hi Neutrinos I will be in an airplane at the time of the meeting this week. So let's skip it and we will resume normally on the 22nd Best regards Miguel

1 0

[nova][stable] Thoughts about backporting fix for bug 1378904?
by Matt Riedemann 14 Mar '19

14 Mar '19

Andrey fixed a bug [1] that we've talked about fixing forever which is to disallow AZ renames while the AZ has instances in it. This is a change in API behavior but it's really a "don't let admins shoot themselves in the foot" kind of thing. As such, it didn't have a microversion because users should not have to opt out of broken behavior, but I'm a bit hesitant about backporting the fix [2]. It has a release note so there would be some warning, but what do others think about backporting this? [1] https://launchpad.net/bugs/1378904 [2] https://review.openstack.org/#/c/641351/ -- Thanks, Matt

3 2

[nova][ptl][election] Start the battle
by Jens Harbott 14 Mar '19

14 Mar '19

We are having two excellent PTL candidates now, making it very difficult for me - and probably others - to decide between them. So I would like to ask the candidates for some statements explaining why they would be the better PTL, lest the election ends up in a tie.

5 4

[nova][dev] Train community goals seeking review/feedback
by melanie witt 14 Mar '19

14 Mar '19

Hi all, As mentioned in the nova meeting today, the TC has two community goals proposed for the Train cycle, available for review and feedback from developers. Please take a look and add your comments to the reviews, if you're interested in helping decide our community goals for Train. * Project Deletion: https://review.openstack.org/639010 * Move legacy client CLIs to OSC: https://review.openstack.org/639376 Cheers, -melanie

1 0