Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-01-22
13:55:19 dtantsur elmiko: which devconf, .cz?
13:57:58 elmiko dtantsur: yeah, .cz, i thought i saw you had a talk there?
13:58:12 dtantsur elmiko: right, so see you there ;)
13:58:21 elmiko haha, yeah!
14:02:35 dtantsur elmiko: so I'll be travelling as well, arriving to Brno 4-5pm. and you? where do you stay?
14:03:30 dtantsur cdent: so FYI ^^^ we both probably out on Thu
14:03:36 elmiko dtantsur: i'll arrive in brno tomorrow at around 2-3pm, stating at the grandezza
14:03:40 cdent noted!
14:03:46 elmiko thanks cdent
14:03:56 dtantsur tomorrow, wow :)
14:04:10 elmiko dtantsur: when do you get there?
14:04:19 dtantsur elmiko: Thursday afternoon
14:04:23 elmiko ah, cool
14:04:35 elmiko dtantsur: yeah, me and Will were going out early to do some work at the office there
14:04:36 dtantsur my train arrives at 4 something, but it will probably be delayed, as always :)
14:04:41 elmiko ouch...
14:04:42 dtantsur neat!
14:05:08 dtantsur I'm staying not so far from downtown, but in a less fancy hotel :)
14:05:34 elmiko i stayed at the avanti last year, but some of our brno colleagues recommended the grandezza
14:09:50 dtantsur more that twice more expensive than one that I have
14:12:58 elmiko where are you stayung?
14:15:22 dtantsur elmiko: Hotel Europa https://www.booking.com/hotel/cz/europa.html
14:16:35 elmiko cool
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'

Earlier   Later