| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-01-21 | |||
| 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) :) | |
| 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 | |