Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-01-22
16:27:28 mordred piddle
17:00:10 jeremyfreudberg mordred, about your saharaclient patch - what's the next step? is there something else i need to do to sahara to make your patch work as it should, or is it really an incompleteness of keystoneauth
17:30:17 mordred jeremyfreudberg: ah - just saw your last comment there ... interesting question
17:30:54 mordred SO - there's a few options I think (this is off the top of my head - I'll probably want to ponder a little longer)
17:31:25 mordred the first one is the one that's likely the largest amount of work for you but is the thing that's likely the most resilient
17:32:16 mordred which is to update your v1 service in sahara to make the project-id in the URL optional (nova did this a couple of years ago)
17:33:09 mordred I don't know enough about your API server implementation to know how much work that is for your v1 codebase, but it would get you into a good forward-compatible place
17:34:35 jeremyfreudberg mordred: it's not much work, but that solution also seems a bit sad
17:34:53 jeremyfreudberg i'd like to hear the other options for sake of completeness
17:35:32 mordred ksa will keep the project-id if it finds it on the endpoint in the catalog, even if it finds a different endpoint via version negotiation
17:37:21 mordred SO - that way if you have an existing deployment that has versioned endpoints with project-ids in their catalog already, then they update to a new version of sahara that has v2 available, and the user requests that they want to use v2, version discovery can get from sahara.example.com/v1/{project-id} to saraha.example.com/ for discover, discover saraha.example.com/v2 exists, then append {project-id}
17:37:23 mordred because it was on the original url
17:37:29 mordred k. that's about enough for that option :)
17:38:55 jeremyfreudberg argh, pushed the wrong button in the irc client
17:39:04 jeremyfreudberg i'm paying attention
17:39:05 mordred jeremyfreudberg: :)
17:39:36 mordred another option is we could potentially add a flag to ksa to tell it to append project-id to discovered endpoints regardless of whether it found a project-id originally
17:40:16 mordred that shouldn't be terribly hard - but I worry about what the impact is on non-python/non-ksa users
17:41:03 mordred actually - let's back up real quick ...
17:42:16 mordred there's a few cases: existing deployments that already have v1/project-id in the catalog, new deployments that are going to register unversioned endpoint in the catalog ... and existing deployments that have v1/project-id in the catalog who want to upgrade to having v2 be the default
17:42:34 mordred jeremyfreudberg: are there any use-cases we're missing there ^^?
17:43:21 jeremyfreudberg mordred: i believe that's all of them
17:43:34 mordred for the first one, you should be set with no changes - existing catalogs have appended project-id, ksa will do version discovery, find v2, append project-id, all should be fine, so existing users should be fine
17:44:44 jeremyfreudberg i'm not sure about that
17:44:52 mordred for the second one, v2 will work via discovery properly if it doesn't require project-ids in the url, but v1 will not work if it does continue to require project-ids (and v2 will also not work if it requires project ids in the urls)
17:44:58 jeremyfreudberg or sorry, yes i am sure, got confused
17:45:22 jeremyfreudberg yes, so far the first two your analysis is correct
17:46:28 mordred for the third, if the deployer switches to a versioned endpoint in the catalog with /v2/{project-id} the existing setup will work for both versions - although users with old versions of saharaclient would be broken since they wouldn't understand the /v2 in the catalog
17:47:39 mordred (sorry for all the words, basically thinking out loud) :)
17:47:49 jeremyfreudberg mordred: right, but putting /v2/{project_id} in the catalog would be an undesirable hack
17:47:57 jeremyfreudberg although it would work
17:49:01 mordred so - quick question - when you say "that solution also seems a bit sad" - is that because you desire keeping project-ids in the urls? or a different reason?
17:50:15 mordred (making sure before walking down other options we grok all the inputs)
17:52:51 jeremyfreudberg mordred: hmm, no, i don't desire to keep project-id in the url, but that solution seems to introduce an even tighter coupling of sahara version vs saharaclient version vs catalog antics
17:54:47 jeremyfreudberg hmm, but that might just be how it feels in my mind
17:54:56 jeremyfreudberg trying to think if there is actually a difference in practice
17:54:59 mordred gotcha. so - I think it *should* help to decouple those
17:55:13 mordred for cases 2 and 3, a consumer is going to need a new/updated client no matter what
17:55:49 mordred the old client isn't going to grok unversioned urls or v2 urls, but it's a new deployment so requiring a newer client sohuld be ok, yeah?
17:56:13 mordred for case one- the existing deployment with v1/{project-id} in the catalog
17:56:31 openstackgerrit Merged openstack/python-openstackclient master: Check that Glance returns image data before processing it https://review.openstack.org/531201
17:56:32 openstackgerrit Merged openstack/python-openstackclient master: Replace assert with condition https://review.openstack.org/536300
17:56:59 mordred old saharaclient should work since it's got v1/project-id in the catalog like it expects, and old client will still send project-id in urls to saraha which will continue to work
17:57:09 openstackgerrit Merged openstack/python-openstackclient master: Updated from global requirements https://review.openstack.org/535769
17:57:51 jeremyfreudberg mordred, alright, i guess i'm convinced
17:57:55 mordred I think what can be gained by making project-id in the url optional is that a user with an updated saharaclient could use v1 on a catalog with unversioned endpoint as well
17:58:41 mordred NOW - other options would be to update saharaclient to pre-pend project-ids for v1 if it does't have them already - your API docs already indicate project-id is a required part of the API call
17:59:21 mordred that would also get you people being able to use unversioned catalog endpoints with newer saharaclient
17:59:48 mordred and non-python things are going to need to deal with unversioned endpoints to be ableto consume those *anyway*
18:01:05 mordred so the biggest issue with doing appending in saharaclient itself would be, amusingly enough, python consumers who are using ksa but not python-saharaclient
18:01:20 mordred (like openstacksdk)
18:01:26 jeremyfreudberg mordred: right
18:01:45 jeremyfreudberg ok, so i guess making project-id optional on the server-side is the best way forward
18:02:06 mordred yah- I think it enables the largest number of people
18:02:46 mordred we could also talk to cdent and edleafe and elmiko about adding an optional field to the version discovery document specification
18:03:21 mordred so that a discovery doc with an endpoint could have an optional field 'requires-project-id'
18:03:34 jeremyfreudberg mordred: yes, i was thinking of that too, to extend version discovery (and have keystoneauth understand those new extensions), but i'm also assuming that situations like Sahara's are only getting rarer as time goes on
18:03:40 jeremyfreudberg so it might be a lot of work for nothing
18:03:49 mordred and we could update the consumption docs and ksa to look for that field and know to append a project id to any endpoint it finds that has that field
18:04:29 mordred jeremyfreudberg: yah. it might be - otoh, I haven't looked to see how many services we have in a similar place to where sahara is now ...
18:05:21 mordred and if we made it a systemic flag like that, we could update things at a base layer in ksa, gophercloud, fog, etc and then people wouldn't necessarily need sahara-specific logic in base clients
18:05:33 mordred like - maybe it's a one-two punch
18:06:19 mordred do 'make project-id optional for sahara v1' and also look in to adding an optional field to version docs and getting base clients updated to understand it
18:06:42 jeremyfreudberg indeed
18:06:50 mordred it wouldn't be much work to add to ksa or to add to the version spec (other than bikshedding of course)
18:07:32 mordred cdent, elmiko, edleafe: ^^ any thoughts on that?
18:08:15 edleafe mordred: current heads-down on placement, with feature freeze this week
18:08:49 mordred edleafe: kk. I guess that's important :)
18:09:43 edleafe :)
18:09:48 jeremyfreudberg mordred: i agree it's not too much work. and happy to have contributed to circumstances that lead to its inspiration
18:09:53 jeremyfreudberg should be interesting to see if it goes somewhere
18:17:00 elmiko mordred: about to leave for the airport, but i'll catch up on the plane
18:19:04 cdent mordred, jeremyfreudberg : nova made it optional but I don't recall the details on how that was managed service catalog or version-wise. sdague will probably know
18:19:18 cdent my preference would be to _not_ add something to version discovery
18:19:53 cdent but then I have a pathalogical problem with project id in uris
18:20:05 cdent (except where they actually mean something)
18:23:39 mordred cdent: yah - I think we're all in strong agreement about them going away (except where they mean something)
18:24:22 mordred cdent: I *think* nova just made them optional, and then over a period of time convinced people to stop putting them into catalog entries
18:26:15 cdent mordred: I would fear that if we make it easy and non-painful to keep them around, then they'll stay around. Which is unfriendly of me, but I can't. be friendly _all_ the time.
18:27:54 mordred cdent: I reject that premise. you're always friendly :)
18:31:09 jeremyfreudberg mordred: thanks again. i'll ping you again if needed (but it looks like we're good)
19:15:26 sdague it was made optional but deprecated. There is a microversion used for signaling that the code can support it
19:27:24 openstackgerrit Merged openstack/os-api-ref master: Remove name from project stanza https://review.openstack.org/536126
20:05:18 openstackgerrit Slawek Kaplonski proposed openstack/python-openstacksdk master: Make floating IP to be prefered over fixed when looking for IP https://review.openstack.org/536548
20:11:54 openstackgerrit Slawek Kaplonski proposed openstack/python-openstacksdk master: Make meta.find_best_address() more generic https://review.openstack.org/536553
20:14:58 slaweq mordred: hi, ^^ two cherry-picks from shade to openstacksdk
20:15:13 slaweq mordred: it was as easy as You said me earlier :) thx
20:16:06 mordred slaweq: woot!
20:16:38 mordred slaweq: there's also a topic i've been using 'merge-shade' - and a few outstanding patches we should make sure get in
20:17:15 slaweq ok, I will change topic then
20:49:31 openstackgerrit Lance Bragstad proposed openstack/python-openstackclient master: Add system role functionality https://review.openstack.org/524416
20:54:07 openstackgerrit Adrian Turjak proposed openstack/python-openstacksdk master: Raise error when supplying invalid query params https://review.openstack.org/532723
22:51:39 openstackgerrit Monty Taylor proposed openstack/python-openstackclient master: Rework Network client config for new SDK Connection https://review.openstack.org/524715
22:52:34 mordred dtroyer: could I impose upon you to +A https://review.openstack.org/#/c/524991/ ?
22:52:59 mordred dtroyer: I'm trying to get the osc-tips jobs added to openstacksdk which kind of fell off the radar a bit
22:56:30 mordred amotoki, dhellmann: also, if either of you have a sec to +A a patch from dtroyer ... https://review.openstack.org/#/c/524715
22:56:30 openstackgerrit Ihar Hrachyshka proposed openstack/python-openstacksdk master: DNM testing whether lib/neutron switch breaks this repo https://review.openstack.org/535943
23:00:25 mordred RuiChen: you too re: 524715
23:07:33 openstackgerrit Colleen Murphy proposed openstack/python-openstackclient master: Add CRUD support for application credentials https://review.openstack.org/536163
23:13:03 openstackgerrit Colleen Murphy proposed openstack/python-openstackclient master: Add CRUD support for application credentials https://review.openstack.org/536163

Earlier   Later