| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-08-01 | |||
| 16:13:10 | dtantsur | nope (I'm remotee), rather personal | |
| 16:13:18 | gtema | ok | |
| 16:16:27 | dtantsur | API related story: ironic is slowly (really slowly) starting a move to Flask. any tips and tricks are welcome! | |
| 16:16:56 | gtema | Flask for what? API serving? | |
| 16:17:22 | elmiko | i guess it depends on what kind of tips and tricks you are looking for, but my main tip is to use MethodView classes for routing | |
| 16:17:33 | edleafe | I don't see how using Flask would change the approach to API design | |
| 16:17:41 | elmiko | ++ | |
| 16:17:56 | gtema | me too, was having nice experience with Blueprints | |
| 16:18:12 | elmiko | yeah, ++ to blueprints as well | |
| 16:18:38 | elmiko | i think the flask docs get you up and running quickly, but the @route decorator pattern is sub-optimal imo | |
| 16:19:05 | gtema | ++ | |
| 16:19:29 | dtantsur | I'm not looking for anything specific, just a quick poll of opinions | |
| 16:20:12 | gtema | opinion - worth a try | |
| 16:20:49 | dtantsur | okay cool. next question: who could lend me a human cloning machine? | |
| 16:20:57 | edleafe | I love FLask, but only have a few simple apps that @route serves well | |
| 16:21:03 | elmiko | yeah, i'm ++ on flask. i love it | |
| 16:21:41 | dtantsur | same. and I don't like the wsme+pecan pair a lot | |
| 16:21:50 | gtema | I wish I had one - need it myself | |
| 16:21:57 | elmiko | yeah, i have very mixed feelings about pecan | |
| 16:22:03 | gtema | wrt to clone-maching | |
| 16:22:04 | edleafe | You could always use my insect cloning machine - just be sure to clean it well first | |
| 16:22:09 | dtantsur | lol | |
| 16:22:34 | dtantsur | my motivation to work on that is that I'm one of the two unfortunate people keeping wsme (barely) floating | |
| 16:23:14 | edleafe | I can give you a concrete block to help it sink faster! | |
| 16:25:23 | dtantsur | it does pretty good job sinking on its own :D | |
| 16:53:56 | mordred | dtantsur|afk: I also think kmalloc may have done something something flask something something over in keystone land - or at least started looking at it | |
| 16:54:09 | kmalloc | ohhai | |
| 16:54:18 | kmalloc | i'm here, let me read up. | |
| 16:54:57 | mordred | dtantsur|afk, gtema: I pushed up a couple of readme fixes - https://review.opendev.org/#/c/674045 and https://review.opendev.org/#/c/674041 if you get bored | |
| 16:55:12 | gtema | bored????????? | |
| 16:55:24 | gtema | there are not enough "?" signs on my keyboard | |
| 16:57:10 | mordred | gtema: :) | |
| 16:57:11 | kmalloc | dtantsur|afk, gtema: we moved 100% over to flask in Keystone from the home-brewed WSGI framework. We use blueprints and wired up a mechanism to auto-populate routes (now, we had another challenge, we also aimed for zero test changes to make the conversion, and mostly succeeded). I am really against @route, but you can directly call the underlying functions/methods to populate the routes. (I prefer explicit vs decorator | |
| 16:57:11 | kmalloc | magic in route/etc) | |
| 16:57:29 | edleafe | Take care everyone - gotta head out for a bit | |
| 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 |
|
| 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) ... | |