Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-08-01
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 magic in route/etc)
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: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 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"

Earlier   Later