Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2018-01-21
16:10:10 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Clean up a bit after the mapping inversion https://review.openstack.org/533823
16:10:11 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Fixed a few nits in the README https://review.openstack.org/534453
16:10:11 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Fix typo in the external service loader code https://review.openstack.org/534452
16:10:12 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Remove resource and proxy https://review.openstack.org/533825
16:10:12 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Update type conversion to handle subtypes more better https://review.openstack.org/533824
16:10:13 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Add resource2/proxy2 wrappers with deprecations https://review.openstack.org/535860
16:10:13 openstackgerrit Monty Taylor proposed openstack/python-openstacksdk master: Rename resource2 and proxy2 to resource and proxy https://review.openstack.org/533826
16:48:11 openstackgerrit Merged openstack-infra/shade master: Make floating IP to be prefered over fixed when looking for IP https://review.openstack.org/536060
16:51:11 openstackgerrit Merged openstack-infra/shade master: Make meta.find_best_address() more generic https://review.openstack.org/536062
18:43:35 openstackgerrit Monty Taylor proposed openstack-infra/shade master: Add devel to branches for ansible-devel job https://review.openstack.org/536159
19:03:03 openstackgerrit Colleen Murphy proposed openstack/python-openstackclient master: Add CRUD support for application credentials https://review.openstack.org/536163
19:12:25 openstackgerrit Monty Taylor proposed openstack-infra/shade master: Add devel to branches for ansible-devel job https://review.openstack.org/536159
21:22:21 adriant mordred: I saw! I'll test it out this week and see how it feels to use and see if we've missed anything. I'm so looking forward to the 1.0 release. I've got so many tools and libraries I really want to rewrite to stop using the swiftclient...
#openstack-sdks - 2018-01-22
00:46:03 johnsom When I try to pip install openstacksdk master I get the following error:
00:46:11 johnsom https://www.irccloud.com/pastebin/empvMkm9/
00:46:24 johnsom I'm wondering if the version code is bad...
01:42:30 openstackgerrit chenyb4 proposed openstack/python-openstacksdk master: Fix clustering detach policy describe error https://review.openstack.org/536184
05:27:20 openstackgerrit chenyb4 proposed openstack/python-openstacksdk master: Fix compute keypair functional test error https://review.openstack.org/536206
09:10:32 openstackgerrit chenyb4 proposed openstack/python-openstacksdk master: Add clustering guides cluster file, examples cluster code https://review.openstack.org/536264
09:52:59 openstackgerrit chenyb4 proposed openstack/python-openstacksdk master: Add clustering guides cluster file, examples cluster code https://review.openstack.org/536264
10:43:04 openstackgerrit Pavlo Shchelokovskyy proposed openstack/python-openstackclient master: Replace assert with condition https://review.openstack.org/536300
10:48:08 openstackgerrit Pavlo Shchelokovskyy proposed openstack/python-openstackclient master: Use general py3 env in default tox run https://review.openstack.org/536304
11:27:51 dtantsur elmiko: hey! early heads-up: I'll be out this Thursday
13:05:56 mnaser morning mordred - https://review.openstack.org/#/c/536003/ - i'm not sure if i understand the normalizing code properly but it looks like i ended up with created = None .. should I avoid using pop or get and instead just pass the value directly?
13:23:15 Shrews mnaser: i think you need to remove 'created' from _SERVER_FIELDS b/c that's putting it back into the dict always. But I also don't think we should just remove 'created' from our model, even in strict mode, since it's already part of our model contract.
13:41:17 mnaser Shrews: probably a good discussion item then with mordred ?
13:52:44 elmiko dtantsur: ack, i might not make it either. will be at devconf
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) :)

Earlier   Later