Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2017-01-12
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
19:01:27 dtroyer I'm going to go back to Ganeti for lightweight VM management
19:01:46 dtroyer it just always works
19:02:32 dtroyer so if I could ask nodepool for a VM to use ad-hoc...
19:02:39 dtroyer Nodepool-as-a-service?

Earlier   Later