Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-08-01
17:00:22 gtema can we somewhen introduce something something like 'take this cloud configuration, but get a domain scoped token'? I am tired of doubling lots of my entries in clouds.yaml to differentiate between project and domain scope
17:01:13 gtema best would be that OSC knows itself which kind of token it need to obtain, but in the worst case "openstack --os-cloud my_cloud --scope domain user list"
17:01:25 elmiko later edleafe o/
17:16:45 dtroyer gtema: I've pondered something related for a while, when creating otherwise-identical entries in clouds.yaml save for the username/password. Would a zuul-like inheritance mechanism solve your issue?
17:17:08 dtroyer I have not actually looked in to doing anything like that but it sounds like it might me useful in other cases
17:18:23 gtema honestly I would really love to avoid doubling entries in clouds.yaml. From the user perspective he should not even know why this is different
17:18:50 gtema best way really apps (SDK, OSK, etc) are able to figure out themselves what they need to achieve task
17:19:47 gtema so while inheritance works, I do not think it is easy to implement and would improve experience
17:22:00 gtema overall I think it should be sufficient for the customer to specify domain_name, project_name, user, pass. Everything else should be handled by tools themselves
17:22:47 gtema gophercloud also forces me to give IDs in some cases. I hate this also, since I need to figure out it first
17:26:25 gtema ok, need to finish for today. Will read back tomorrow if anyone have ideas
18:18:12 openstackgerrit Matt Riedemann proposed openstack/python-openstackclient master: Fix description for --block-device-mapping https://review.opendev.org/674105
19:11:53 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Make swift proxy stop trying to version discover https://review.opendev.org/674110
19:13:13 mordred kmalloc: ^^
19:13:24 openstackgerrit Matt Riedemann proposed openstack/python-openstackclient master: Add openstack server create --boot-from-volume option https://review.opendev.org/674111
19:13:36 mriedem mordred: dtroyer: as discussed at the forum ^
19:13:40 mriedem wip until i test it in devstack
19:13:57 mordred kmalloc: we were too good in keystoneauth with the discovery and I cannot for the life of me figure out a better way to get things to not try to find another url for swift
19:14:13 mordred kmalloc: I mean - it's functional - it's just an additional roundtrip that we know is never going to work
19:14:23 kmalloc lol
19:14:38 kmalloc yeah.... probably
19:29:42 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Allow services to override proxy creation. https://review.opendev.org/674110
19:29:51 mordred kmalloc: ok. that might actually not be terrible
19:30:43 kmalloc gnn,
19:30:47 kmalloc hmm even
19:30:57 kmalloc but yeah ksa is pretty damn good at this point at doing that discovery bit
19:31:37 mordred yeah
19:31:52 mordred so - really, from the sdk layer saying "hi, just skip it" is, I think, better
19:32:43 mordred kmalloc: re: gtema's question from above - the actions that need domain scoped tokens are generally well-known, right?
19:33:08 mordred kmalloc: it's not liek a thing where a user is going to generally be thinking to themselves "I really want to boot a server, but I want to do it with a domain scoped token"
19:33:12 mordred right?
19:34:36 mordred what I'm thinking is we could make a version of the connect_as method in sdk that's like "connect_as_domain" (or named something better) - which creates a new Connection stripping the project info out so that it can be domain scoped (hand waves details)
19:34:50 mordred and then we can use that or something liek it in the specific calls that need a domain scoped vs. project scoped
19:35:03 mordred and it can exist for the programming cases where someone wants to do something more complex
19:35:21 mordred because I agree with gtema - it's a bit hard to deal with ATM
19:38:27 kmalloc mordred: and really not many domain-scoped things are needed
19:38:35 kmalloc mordred: mostly simply in keystone
19:38:43 mordred yeah - that's what I thought
19:38:49 kmalloc iirc a domain scoped token cannot boot a server
19:39:00 mordred I mean - most things don't know what a domain is
19:39:01 kmalloc and for sure will not be able to in the future when the scope is locked to "project"
19:39:18 mordred can you say more words about that last sentence?
19:39:30 kmalloc policy has explicit scopes (in the future)
19:39:36 kmalloc it's the whole "system scope" enhancement
19:39:42 kmalloc three scope types are project, domain, system
19:40:02 kmalloc APIs will declare (via enforcement) what scopes are allowed
19:40:21 kmalloc and policy will explicitly reject anything not allowed.
19:40:43 kmalloc so coming to an API that says "i accept project scope" with a domain-scoped token, you'd get a 403
19:41:09 mordred neat!
19:41:23 kmalloc yup :) we thought so
19:41:38 kmalloc so connect_as_domain should be 100% fine to implement
19:42:09 kmalloc and as long as domain information is available, ksa should attempt to scope to the domain instead of the project information
19:42:36 kmalloc now, if there is no domain information in the clouds.yaml... i expect it to fail and tell the user as much
19:42:52 kmalloc duplicated clouds.yaml sounds amazingly gross.
19:43:36 mordred kmalloc: well - I think connect_as_domain can look into the auth structure that exists and see if there is domain info or not
19:43:44 kmalloc absolutely
19:43:54 mordred and/or check that this is over auth v3 and vomit if not
19:44:25 kmalloc i was thinking from a standpoint of unauthenticated, no token yet
19:44:59 kmalloc if you say "uh, connect_as_domain" the flow of "auth as project then rescope" is almost a bit more than I'd like to see in ksa, but as i type this out it probably is fine.
19:45:24 kmalloc if it's v2, it can just barf.
19:47:57 kmalloc mordred: commented on https://review.opendev.org/#/c/674110/2, this feels like something that should go in service-types.
19:48:07 kmalloc mordred: rather than hard-coded in SDK (long term)
19:48:20 kmalloc mordred: but as it stands, worth landing until enhancements to service-types happens.
19:53:42 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: Make configuration show not require auth https://review.opendev.org/673110
19:59:26 mordred kmalloc: oh - I meant more putting it in sdk not in ksa (the connect_as_domain bit) ...
19:59:47 kmalloc ah
19:59:54 kmalloc sure, that makes WAY more sense :P
20:00:02 mordred :)
20:00:08 mordred BUT - it makes me wonder ...
20:00:23 mordred should we also make an update to the clouds.yaml format to allow you to say something like:
20:00:41 mordred "this is my user that exists in this domain. these are the various projects I might want to use"
20:00:45 kmalloc it might be clunky unless KSA has a clear re-scope-to-domain or "duplicate session and rescope to domain"
20:01:33 kmalloc maybe. if you want to define projects that are interesting, but remember we can already query what projects a user can scope to
20:01:35 mordred I keep pondering a clouds.yaml v2 format (obviously with automatic upconversion or similar) ... but the kubeconfg file I think gets this right with the context stuff
20:01:55 mordred kmalloc: right - but a user has to say what project they want to use in the normal case
20:02:07 kmalloc honestly, i kindof like duplicate session and rescope
20:02:13 mordred yeah
20:02:21 kmalloc so you can take an action on domain but not impact anything else
20:02:30 mordred I think it's easier to code - since we already have a "I want a connection just liek this one but with a different user context"
20:02:36 kmalloc if you have some deep-in-workflow that the session already is being consumed for
20:03:11 kmalloc ++
20:32:22 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add CloudRegion helper method for arbitrary endpoints https://review.opendev.org/674130
21:24:58 openstackgerrit Matt Riedemann proposed openstack/python-openstackclient master: Add openstack server create --boot-from-volume option https://review.opendev.org/674111
21:54:03 openstackgerrit Merged openstack/python-openstackclient master: Support IPv6 addresses better https://review.opendev.org/524420
21:56:42 openstackgerrit Merged openstack/python-openstackclient master: Mention compute service set --up|--down requires 2.11 or greater https://review.opendev.org/672554
21:56:43 openstackgerrit Merged openstack/python-openstackclient master: openstack port create support --extra-dhcp-option https://review.opendev.org/657519
22:07:24 openstackgerrit Merged openstack/openstacksdk master: Update links https://review.opendev.org/673401
22:12:15 openstackgerrit Alex Schultz proposed openstack/keystoneauth master: Cleanup session on delete https://review.opendev.org/674139
22:41:59 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Fix resource layer object interactions with weird chars https://review.opendev.org/674142
22:53:16 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add CloudRegion helper method for arbitrary endpoints https://review.opendev.org/674130
22:53:17 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Allow services to override proxy creation. https://review.opendev.org/674110
22:53:17 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Fix resource layer object interactions with weird chars https://review.opendev.org/674142
22:57:45 mordred Shrews: ^^ that stack came out of the work corvus was doing with uploading things to swift
22:58:04 mordred Shrews: I should add tests - I'll do that tomorrow
#openstack-sdks - 2019-08-02
06:26:17 openstackgerrit pengyuesheng proposed openstack/osc-lib master: Sync Sphinx requirement https://review.opendev.org/674192
06:47:24 openstackgerrit pengyuesheng proposed openstack/osc-lib master: Sync Sphinx requirement https://review.opendev.org/674192
07:02:09 openstackgerrit pengyuesheng proposed openstack/osc-lib master: Sync Sphinx requirement https://review.opendev.org/674192
08:11:24 dtantsur thanks kmalloc, this is useful feedback!
08:12:39 kmalloc dtantsur: this is where we did the work
08:12:56 kmalloc https://github.com/openstack/keystone/blob/master/keystone/server/flask/application.py#L165-L167

Earlier   Later