| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-01-12 | |||
| 16:12:16 | waj334 | I'm gonna proceed with the implementation of Cinder v3.3 (implements messages api) and maybe I'll be able to tackle this microversion problem | |
| 16:12:55 | dtroyer | waj334: cool. I think it is safe to use 412614 as the base for that now | |
| 16:14:12 | stevemar | waj334: dtroyer not sure if you guys saw this, but diana_clarke pushed https://review.openstack.org/#/c/419108/ which starts microversion support for nova stuff | |
| 16:14:25 | stevemar | mriedem was saying they'll be looking at it in pike, i think | |
| 16:14:35 | dtroyer | saw but have not really read it yet | |
| 16:16:27 | waj334 | stevemar: It doesn't seem to do much of anything | |
| 16:18:39 | mordred | dtroyer, stevemar: do we have any time at the PTG that we can sit down together and talk through / work through where we want the osc/occ config ownership and handoff to be? I think we keep wanting to talk about it and never quite getting to it ... | |
| 16:19:50 | dtroyer | mordred: we have a room mon/tues, it's just a matter of arranging the schedule | |
| 16:20:48 | mordred | dtroyer: woot | |
| 16:21:22 | openstackgerrit | Pavlo Shchelokovskyy proposed openstack/python-openstackclient: Fix flavor create help re swap size units https://review.openstack.org/419549 | |
| 16:23:47 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient: Fix image member unit tests occasional failures https://review.openstack.org/419528 | |
| 16:27:25 | waj334 | The microversion issue is gonna be a bigger problem than I thought. Any ideas on how to handle 2 versions of the same function, but with different parameters? lol | |
| 16:27:39 | waj334 | * not so lol * | |
| 16:28:02 | openstackgerrit | Pavlo Shchelokovskyy proposed openstack/python-openstackclient: Fix flavor create help re swap size units https://review.openstack.org/419549 | |
| 16:29:24 | dtroyer | waj334: we've talked about a couple of strategies for handling those. #1 is user-breaking changes are bad and we have to abide by semver at the CLI level so if you're talking about CLi-visible differences we need to consider that and time it properly | |
| 16:30:05 | dtroyer | most of what we've talked about though is handling the differences internally, which is basically writing multiple versions and branching as required. No magic, copying code is not bad here | |
| 16:36:47 | waj334 | dtroyer: So, with the messages api in Cinder v3.3 and v3.5 I'll end up with 2 separate files is what you're saying? Like messages_3_3.py, messages_3_5.py? Or, just different versions of various methods, just named slightly different? | |
| 16:39:14 | waj334 | I may be overthinking this | |
| 16:41:44 | dtroyer | we only split fies by major version so far, I suppose if it's a huge change that might be easier, but there is no mechanism to handle minor version changes at the stevedore/entry-point level | |
| 16:42:02 | dtroyer | so we'll still wind up with a common entry point. | |
| 16:42:22 | dtroyer | my thinking is of a microversion is so different that it's a total re-work, then something went wrong somewhere | |
| 16:46:17 | waj334 | Well, luckily what I'm seeing in this messages api is where optional params were added in v3.5 so that's easier to deal with. How important is maintaining consistency of command parameters if they are allowed to change between versions? | |
| 16:47:01 | Serlex | Hi, can someone post an example of "add_gateway_to_router(router, **body)" cheers | |
| 16:50:17 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient: Fix image member unit tests occasional failures https://review.openstack.org/419528 | |
| 16:56:08 | waj334 | dtroyer: Would it be wise to check the client version first before adding arguments? That way I could set up the command properly for that specific microversion by just a few if statements. | |
| 16:56:46 | waj334 | Provided that I know about the client before commands are set up that is | |
| 16:59:04 | dtroyer | we don't do version discovery until the very last minute, ie the first actual API call to the service. So we'll only know the specific API version if the user has specified it. | |
| 16:59:22 | dtroyer | otherwise we have to make multiple calls (auth, discovery) to even build help | |
| 17:00:13 | dtroyer | for that, and the fact that we don't want incompatible changes to begin with, we should go to a good bit of work internally to not expose unnecessary changes to the user | |
| 17:01:25 | elmiko | LOL | |
| 17:06:38 | waj334 | It seems that I'm defeated | |
| 17:13:17 | stevemar | mordred: handoff? you ditching occ and leaving it on our laps? :) | |
| 17:14:33 | Serlex | sooo | |
| 17:15:23 | stevemar | Serlex: you're using openstacksdk? | |
| 17:16:02 | Serlex | yes | |
| 17:16:25 | Serlex | I want to add external network to a router | |
| 17:16:44 | Serlex | "add_gateway_to_router(router, **body)", got my router...how do I apply the body bit | |
| 17:17:57 | stevemar | Serlex: -- briancurtin huanxuan or reedip might be able to help you out, i'm not familiar with that command and my googling hasn't turned up anything | |
| 17:18:28 | briancurtin | Serlex: apply the body bit? | |
| 17:21:50 | cdent | elmiko, edleafe I forgot to mention I can't run the meeting next week, can one of you? | |
| 17:22:06 | elmiko | cdent: i should be able to | |
| 17:22:14 | elmiko | i'll be out the following week though | |
| 17:22:18 | briancurtin | Serlex: i don’t see that in the neutron API docs so i don’t know what’s expected there. hopefully someone who worked on it is in here because as usual things are undocumented | |
| 17:22:19 | cdent | cool, thanks, it's the last day my parents are in country | |
| 17:22:29 | elmiko | ooh nice, say hi for me =) | |
| 17:24:48 | edleafe | cdent: elmiko: I'll be around too | |
| 17:24:52 | Serlex | briancurtin: thanks, complete noob, hoping example will set me off | |
| 17:25:01 | elmiko | edleafe: cool | |
| 17:25:12 | stevemar | Serlex: briancurtin sounds like it's this API? http://developer.openstack.org/api-ref/networking/v2/?expanded=add-interface-to-router-detail#add-interface-to-router | |
| 17:25:28 | briancurtin | Serlex: looking at https://github.com/openstack/python-openstacksdk/blob/master/openstack/tests/unit/network/v2/test_router.py#L177 you would just pass kwargs that correspond with what’s expected by the server. they pass network_id=3, enable_snat=True there | |
| 17:25:36 | dtroyer | stevemar: my hacky-test for the image bits passed unit tests: https://review.openstack.org/419528 want to go with that (unrolled 1 test into 3) or shall I fix up huanxuan's? I know what bit we both missed the first time thought, just not why it is inconsistent | |
| 17:25:59 | stevemar | briancurtin: Serlex sounds like you need to pass one of subnet_id or port_id as kwargs | |
| 17:26:18 | briancurtin | Serlex: it might be similar but it’s not the same. the method you asked about isn’t listed there in the API docs | |
| 17:26:24 | cdent | edleafe, elmiko: proof please: https://etherpad.openstack.org/p/api-wg-newsletter | |
| 17:26:34 | briancurtin | it’s an interface-to-router not gateway-to-router | |
| 17:27:39 | Serlex | ok thanks | |
| 17:27:43 | Serlex | this what I was looking at http://developer.openstack.org/sdks/python/openstacksdk/users/proxies/network.html | |
| 17:27:52 | elmiko | cdent: +1 from me | |
| 17:29:51 | edleafe | cdent: looks good, except I'm not sure how moral my support can be :) | |
| 17:30:29 | cdent | how's that edleafe ? | |
| 17:31:08 | edleafe | heehee | |
| 17:31:23 | edleafe | I think the earlier version would be clearer to the masses | |
| 17:31:45 | elmiko | lol | |
| 17:34:05 | cdent | damn | |
| 17:34:18 | cdent | hoisted on my typos, again and again | |
| 17:37:41 | ankur-gupta-f1 | dtroyer: stevemar: link for todays meetings agenda etherpad? | |
| 17:41:13 | dtroyer | ankur-gupta-f1: the etherpad is at https://etherpad.openstack.org/p/osc-weekly-meeting, but the meeting was a few hours ago…it an even week | |
| 17:41:32 | ankur-gupta-f1 | well shit. k thanks | |
| 18:46:29 | mordred | stevemar: oh good golly no - I mean working through a plan for dealing with the duplication of concerns between osc and occ that we're all happy with | |
| 18:53:23 | mordred | cdent, johnthetubaguy sorry I missed the second half of the api meeting - had to run to the airport | |
| 18:53:59 | cdent | as ya do | |
| 18:54:38 | mordred | cdent: in answer to your question, the sorts of things that would be useful from an occ/shade perspective as discoverable capabilities are the "Does this cloud support volume deletion" sorts of things | |
| 18:55:04 | cdent | what about "does this volume right here support deletion"? | |
| 18:55:37 | mordred | that's maybe useful, but less urgent than the first thing | |
| 18:56:25 | mordred | a better direct example is things like "this cloud requires floating ips for external access" | |
| 18:56:45 | cdent | that sounds more like a warning than capabilities discovery | |
| 18:56:55 | mordred | or "this cloud requires v2 tasks for image uploads" - or "this cloud requires images to be in VHD format" | |
| 18:57:16 | mordred | cdent: maybe I should phrase that differently... | |
| 18:57:56 | stevemar | dtroyer: let go with https://review.openstack.org/#/c/419528/3 instead, ship it! | |
| 18:58:06 | mordred | "this cloud supports floating ips" "this cloud supports direct attached public ips" "this cloud supports ipv6" "this cloud supports uploading image via PUT" - all of which are deployment choices | |
| 18:58:08 | cdent | I think your phrasing is pretty important because it represents one of the differences in the ways people are describing capabilities | |
| 18:58:10 | stevemar | dtroyer: huanxuan is fast asleep :) | |
| 18:58:23 | dtroyer | stevemar: shipped | |
| 18:58:29 | stevemar | dtroyer: woo hoo | |
| 18:59:28 | mordred | cdent: let me compile you a list of the things we either do a lot of work to figure out / infer or have to punt to config files | |
| 18:59:48 | dtroyer | stevemar: so my inability to successfully get a neutron devstack running again has borked my attempt to validate https://review.openstack.org/418650 with sdk 0.9.12. it sez devstack installed it, but the functional log sez 0.9.10 | |
| 19:00:06 | cdent | mordred: if you wanna do it right on the review that would be awesome: https://review.openstack.org/#/c/386555/ | |
| 19:00:13 | stevemar | dtroyer: hehe | |
| 19:00:22 | mordred | cdent: will do! | |
| 19:00:23 | dtroyer | fwiw, amazon will deliver my solution to the devstack VM problem Saturday… | |
| 19:00:28 | stevemar | dtroyer: let the CI do it | |
| 19:00:29 | cdent | mordred: awesome thanks | |
| 19:00:42 | stevemar | dtroyer: new laptop or workstation? | |
| 19:00:44 | dtroyer | cdent: what mordred sez +++ | |
| 19:00:45 | mordred | dtroyer: does AWS provide devstack as a service now? | |
| 19:00:55 | stevemar | mordred: i was going to go there lol | |
| 19:00:57 | dtroyer | mordred: via NUC, yes | |
| 19:01:04 | dtroyer | on-premises | |
| 19:01:13 | dtroyer | unfortunately, it isn't going to run OpenStack | |
| 19:01:13 | mordred | dtroyer: mmm. devstack-nuc on-prem | |