| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-08-01 | |||
| 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 | |
| 08:13:37 | kmalloc | dtantsur: and our API base https://github.com/openstack/keystone/blob/master/keystone/server/flask/common.py | |
| 08:14:32 | kmalloc | as you can see, it's doable, it just takes extra code. each of our paths (e.g. /v3/users) is a blueprint and would be found in keystone.api.users (all resource handlers under /v3/users goes in keystone.api.users even if it's something that historically lived elsewhere) | |
| 08:14:59 | kmalloc | since we lean on json home we have some extra construction bits for that | |
| 08:16:59 | kmalloc | keep in mind the blueprint/resource class (we use flask restful) doesn't exist until it is called, so sometimes self.XXX may not work since you're in a class context. | |
| 08:28:36 | dtantsur | okay, cool! | |
| 08:28:52 | dtantsur | now my biggest problem is how to gradually replace wsme without doing everything at once | |
| 08:54:09 | dtantsur | mordred: hi! opinion needed on https://github.com/dtantsur/rust-osauth/pull/7 | |
| 10:08:20 | cdent | death to wsme! | |
| 10:22:20 | dtantsur | \o/ | |
| 11:46:51 | mordred | dtantsur: responded | |
| 11:50:46 | dtantsur | thx | |
| 11:56:10 | mordred | dtantsur: also - it makes me sad that there are deployments out that which don't expose those urls properly. it's largely because python-novaclient and friends never used them (hardcoding url manipulations instead) - so nobody noticed | |
| 12:01:33 | dtantsur | yep, pretty sad | |
| 12:01:55 | dtantsur | see, my small and young project is already getting ugly hacks because of nova! | |
| 12:01:57 | dtantsur | :D | |
| 12:49:26 | openstackgerrit | Dmitry Tantsur proposed openstack/openstacksdk master: baremetal.configdrive: tolerate user_data as a string https://review.opendev.org/674298 | |
| 13:39:42 | frickler | mordred: seems you commented as opendevadmin instead your personal account, I'm assuming that wasn't intended? | |
| 14:44:30 | openstackgerrit | Bence Romsics proposed openstack/openstacksdk master: Add router add/remove route operations https://review.opendev.org/674324 | |
| 14:47:36 | openstackgerrit | Bence Romsics proposed openstack/python-openstackclient master: Add command: router add/remove route --route https://review.opendev.org/674325 | |
| 15:05:31 | gtema | mordred: Houston - we have a problem. Ansible is not capable in resolving resource objects. Latest merged released change for Keypairs results in Ansible not properly getting keypair attributes | |
| 15:05:41 | openstackgerrit | Riccardo Pittau proposed openstack/openstacksdk master: Sort output of functional test trait https://review.opendev.org/674328 | |
| 15:17:17 | openstackgerrit | Matt Riedemann proposed openstack/python-openstackclient master: Add openstack server create --boot-from-volume option https://review.opendev.org/674111 | |
| 15:28:39 | openstackgerrit | Riccardo Pittau proposed openstack/openstacksdk master: Sort output of functional test trait https://review.opendev.org/674328 | |
| 15:43:52 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Enable ansible module test for keypair to check return data https://review.opendev.org/674333 | |