Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-01-22
14:18:21 dtantsur yeah, my parents stayed there once. they seemed to like it, and reviews are quite good
14:19:36 elmiko now i just gotta sit through 11 hours of travel...
14:20:20 openstackgerrit Merged openstack/os-api-ref master: Fix UnicodeDecodeError https://review.openstack.org/516788
14:21:24 dtantsur elmiko: ouch! well, yeah. it's 7 hours by train for me :) I guess I'd prefer to fly
14:34:41 elmiko dtantsur: that's a decent train ride!
14:35:43 elmiko will you at least get the train with internet the whole way there?
14:35:52 dtantsur elmiko: I doubt it
14:36:07 elmiko =(
14:55:35 openstackgerrit Chen Hanxiao proposed openstack/python-openstackclient master: Add --image-property parameter in 'server create' https://review.openstack.org/535664
15:16:40 slaweq frickler: hi
15:17:07 slaweq frickler: I don't know if You saw but I did patches for find_best_address() as we talked last week: https://review.openstack.org/#/c/536062/
15:17:16 slaweq frickler: and https://review.openstack.org/#/c/536060/
15:18:32 slaweq mordred: hi, is there any "procedure" how such patches like ^^ should be ported from shade to openstacksdk now?
15:19:00 slaweq or should I just do same/similar patches to openstacksdk repo now?
15:25:46 openstackgerrit Chen Hanxiao proposed openstack/python-openstackclient master: Add --image-property parameter in 'server create' https://review.openstack.org/535664
15:25:58 mordred slaweq: I should write a quick note on that for the dev docs ... the tl;dr is...
15:27:51 mordred slaweq: assuming you have git repos of each in git.openstack.org/openstack-infra/shade and git.openstack.org/openstack/python-openstacksdk ... in the python-openstacksdk dir, do 'git fetch ../../openstack-infra/shade ; git cherry-pick $sha ; git review'
15:28:34 mordred slaweq: we merged the whole git history from shade into openstacksdk, so fetching and cherry-picking and whatnot should just work most of the time
15:30:10 slaweq mordred: thx a lot
15:30:27 slaweq mordred: I will try it today with my last 2 patches done for shade :)
16:27:16 mordred sweet! and thanks for reminding me, we should go through and make sure we've done that for all of the shade patches
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.

Earlier   Later