Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-01-08
14:49:05 lbragstad :(
14:49:20 lbragstad we did overhaul some docs to try and make things more clear
14:49:24 lbragstad https://docs.openstack.org/keystone/latest/admin/tokens-overview.html
14:51:25 frickler "openstack --os-system-scope system registered limit create ..." works for me with the devstack-admin user and unsetting all OS_PROJECT/TENANT env
14:52:18 mordred ah - --os-system-scope
14:52:20 mordred neat
14:53:12 frickler would be nice to give a warning when it still does project-scope, instead of silently ignoring the system-scope request in that case
14:54:31 mordred I think it would be better if --os-system-scope overrode the project settings -- unsetting env vars is a bit of a pita
14:54:45 dtantsur lbragstad: this actually helps. I don't think i saw it when I started rust-openstack.
14:56:08 mordred frickler: because the osc test cases are all run with env vars set ...
14:57:37 frickler mordred: yeah, having cli options override other env vars would be neat, too, but not so easy I fear
14:57:43 lbragstad frickler it does.. but since the registered limit and limit apis are still experimental, we didn't deprecate the policies
14:58:03 lbragstad https://gist.github.com/lbragstad/ad744f1a5acb4f4dc3387383514ab33f is an example of defining different scopes in clouds.yaml
14:58:27 lbragstad if you had different users with different roles on the system (one of them being a read-only role)
14:58:33 frickler mordred: maybe setting things like --os-project-name="" to set overrides to the env via cli might work in the meantime
14:59:00 lbragstad dtantsur if you have questions about how all that works, you should bug me :) I'm happy to help
14:59:02 mordred frickler: yeah, I'll try that
14:59:21 dtantsur lbragstad: thanks! I will when I start extending authentication support there
14:59:30 frickler lbragstad: I'm not talking about policies, a simple "openstack --os-system-scope system token issue" will still issue a project-scope token without warning when e.g. OS_TENANT_NAME is set
14:59:44 lbragstad ahh
14:59:53 lbragstad got it - i misread that
15:00:11 cmurphy lbragstad: it seems like this is pointing out an issue in our backwards compatibility?
15:00:37 lbragstad with the policies or with osc?
15:00:48 cmurphy with the policies
15:01:22 lbragstad they are backwards compatible when we deprecate them - due to the logic in the oslo.policy library
15:01:42 lbragstad the only reason we didn't with the registered limit and limit policies is because the api is experimental
15:01:53 cmurphy oh I see
15:02:08 cmurphy I assumed we went through the same process with those
15:02:30 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Set system-scope parameter for registered_limits tests https://review.openstack.org/629203
15:03:08 mordred ok - there is a stab ... I'm not sure that'll fix it or not
15:03:12 lbragstad cmurphy wxy brought it up here - https://review.openstack.org/#/c/621016/2
15:03:40 cmurphy got it
15:03:45 mordred what we might need to do is add support for registered_limit in sdk and have the sdk force the system-scope auth regardless of what parameters are otherwise set then update osc to use sdk for these calls
15:04:19 mordred but - let's see if that works first
15:07:48 frickler mordred: doesn't work in my local tests, you cannot use an empty string at that location
15:08:00 mordred blerg
15:08:44 mordred a potentially easier fix would be to update the test runner to not source the env vars but instead to add an --os-cloud command line option to self.openstack in the tests
15:09:18 mordred frickler: do you have the ability to test if --os-project-id='' works if the project-id is coming from clouds.yaml instead of from env vars?
15:09:23 mordred oh - you know what?
15:09:32 frickler mordred: but that sounds ... modern
15:09:45 mordred we could make a new devstack user in clouds.yaml - devstack-system - that would not have project stuff set in teh first place and have system-scoped: all
15:09:55 frickler mordred: also, you could simple use a different cloud ... yeah
15:10:04 mordred I think that sounds like the best bet to me
15:10:19 mordred I'm going to start by changing the func test setup to use --os-cloud instead of env var
15:10:44 mordred and then work on getting an additional clouds.yaml entry for devstack
15:10:51 frickler mordred: the different cloud user should probably be in devstack by default
15:10:54 mordred yah
15:10:57 mordred totally agree
15:11:08 mordred I think it'll be a nice addition to devstack for folks
15:11:54 frickler o.k., I'm away for a bit, I can do reviews later
15:14:07 lbragstad frickler mordred yeah - that's what i do
15:14:18 lbragstad super handy for switching profiles
15:15:24 lbragstad i used it a bunch in a demo, trying to explain scopes https://youtu.be/A1vP6be1U5U?t=353
15:19:05 openstackgerrit Merged openstack/openstacksdk master: Skip block storage v2 functional tests for a minute https://review.openstack.org/629162
15:22:03 mordred gtema: did you see dtantsur's comment on https://review.openstack.org/#/c/621153/ - it came on a +A and was a suggestion for followup, just wanted to make sure you didn't miss it
15:22:41 gtema mordred: yupp, have seen but have a "disaster" at work which I need to take care of
15:22:59 mordred gtema: ugh. "disasters" are the worst. have fun with that
15:23:09 gtema thanks
15:23:22 mordred gtema: is the "disaster" caused by someone else's lack of planning? I really love those
15:24:02 gtema no, it is caused by someone leaving the company and others on a long vacation and suddenly certificates stoped working
15:31:04 mordred gtema: oh double ugh
15:31:19 mordred lbragstad, frickler: remote: https://review.openstack.org/629235 Add a devstack-system cloud for system scoped actions
15:37:35 lbragstad mordred nice, thanks
15:46:06 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Use devstack-system cloud for limit tests https://review.openstack.org/629203
15:46:07 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Use os-cloud instead of OS env vars for functional tests https://review.openstack.org/629243
15:46:33 mordred lbragstad, frickler: ^^ and there's the OSC update to use clouds.yaml - and then to use devstack-system for the limits tests
15:48:25 mordred mmm. donuts. is there nothing they can't do?
16:01:53 openstackgerrit Bruno HALEBLIAN proposed openstack/openstacksdk master: implement identity v3 Proxy "unassign_project_role_from_user" https://review.openstack.org/629073
16:09:11 dtroyer to temporarily unset an env var
16:52:24 frickler dtroyer: I've been testing whether that works, so the idea sounds plausible, but I'm not sure whether it would be worth the code complexity. maybe a global --ignore-environment option instead? but then, using all these options should be deprecated in favor of --os-cloud anyway, so probably let's just work with the latter
17:07:20 dtroyer frickler: my reasoning for the precedence we have (cli options > env vars > clouds.yaml) is because of exactly this case, where you generally want your environment to contain the "normal" setup and can override on the command line for the exceptions.
17:07:46 dtroyer I'm not sure a global 'ignore env' is right, I might only want to change one or two things, project being the one I run into myself most
17:09:42 mordred dtroyer: I thinkm --no-project would be a great addition
17:10:39 mordred dtroyer: although ultimately I'd like for people to be able to use these limit commands without needing to always set --os-system-scope --no-os-project-id --no-os-project-name --no-domain-id --no-domain-name ... because that just seems like we're abusing people :)
17:10:47 mordred that'll be a longer effort though
17:11:51 mordred be I definitely think being able to blank out specific things is a good idea
17:12:18 dtroyer mordred: I think I am behind on the keystone/ksa stuff around system scope, is that a thing we can (or should?) just assume for commands like this?
17:25:02 mordred dtroyer: I think for _this_ one it is? like - from this morning's interaction I'm pretty sure we want to make the sdk automatically system-scope these calls
17:25:19 mordred dtroyer: but - it's also fairly new information - so I could be totally wrong about it
17:44:22 openstack Launchpad bug 1809691 in senlin "Memory leak with senlin-engine sdk drivers" [Undecided,New]
17:44:22 dtruong mordred: Have you seen an issue with openstacksdk reporting too many files open? https://bugs.launchpad.net/senlin/+bug/1809691
17:47:37 mordred dtruong: yeah - I think that's been reported by someone else too? there's one leak that exists that we added a connection.close() method to handle (although there is a patch in flight that should make the need for that go away)
17:47:48 mordred dtruong: that was a thread leak though
17:48:21 mordred but maybe it's the same cause
17:49:40 dtruong the person who reported this bug in senlin proposed a patch set to set 'Connection' to 'Close' in the session header: https://review.openstack.org/#/c/627215/7/senlin/drivers/sdk.py
17:50:05 dtruong Is that the correct way to work around the issue?
17:57:07 openstackgerrit Merged openstack/openstacksdk master: Fix pagination key detection https://review.openstack.org/628977
17:57:31 mordred hrm. that I do not know about ... I'm not sure what that does - but seems to be a manipulation of the low-level requests session
17:57:39 mordred cmurphy, lbragstad: ^^ any chance you know?
17:59:06 mordred dtruong: it seems like that will close the remote connection, yeah - so that could certainly help with a connection/socket leak
17:59:33 mordred I'm a little surprised that would be needed because requests is supposed to be doing connection pooling
18:18:43 openstackgerrit Merged openstack/openstacksdk master: fix typos https://review.openstack.org/627258
18:18:44 openstackgerrit Merged openstack/openstacksdk master: Fix the misspelling of "configuration" https://review.openstack.org/627477
18:30:09 openstackgerrit Monty Taylor proposed openstack/cliff master: Pin cmd2 back to <0.9 on all versions https://review.openstack.org/629283
18:30:22 mordred dhellmann: ^^ there's the cliff patch with a depends-on
18:34:46 openstackgerrit Merged openstack/openstacksdk master: Rework orchestration to add update preview https://review.openstack.org/621154
18:34:46 openstackgerrit Merged openstack/openstacksdk master: Add possibility to override base_path for resource operations https://review.openstack.org/621153
18:46:43 dhellmann mordred : see the "conflicts with" list there; it looks like someone else proposed a similar change and it failed a test. let's see how yours does...
18:47:01 dhellmann oh, he's lacking the depends-on so that's probably why
18:59:01 mordred dhellmann, dtroyer: also - dmsimard was asking about an osc-lib release the other day

Earlier   Later