19:00:50 <dtroyer_zz> #startmeeting openstackclient 19:00:50 <openstack> Meeting started Thu Apr 7 19:00:50 2016 UTC and is due to finish in 60 minutes. The chair is dtroyer_zz. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:54 <openstack> The meeting name has been set to 'openstackclient' 19:00:55 <stevemar> o/ 19:00:59 <dtroyer_zz> I'm here in spite of my nick 19:01:02 <baumann> Hello 19:01:08 <rtheis> o/ 19:01:19 <jgregor> Hello 19:01:23 <stevemar> hello osc'ers 19:02:57 <stevemar> bump? 19:03:17 <dtroyer_zz> hey hey 19:03:32 * stevemar pokes dtroyer_zz with a stick 19:03:43 <baumann> The 'zz's are real 19:03:47 <dtroyer_zz> we have another agenda, what is this, a regular team now: :) 19:04:08 <dtroyer_zz> #topic multiple API ooutputs 19:04:27 <stevemar> given how much we're commiting to our repo, it would seem like it 19:04:36 <dtroyer_zz> https://bugs.launchpad.net/python-openstackclient/+bug/1566090 19:04:37 <openstack> Launchpad bug 1566090 in python-openstackclient "Cannot determine network, or pool, a floating ip belongs to without multiple commands" [Undecided,New] - Assigned to Reedip (reedip-banerjee) 19:04:59 <dtroyer_zz> is reedip here? 19:05:15 <dtroyer_zz> or Carlos (not sure of his nick) 19:05:43 <stevemar> i think he is meteorfox... who doesn't seem to be online 19:06:10 <stevemar> he is in -sdks, i asked him to join here 19:06:48 <stevemar> he left a pretty good explanation in the bug report 19:06:49 <dtroyer_zz> k. I haven't studied this in depth, but it seems like priority one is to make both versions of the command output the same as much as reasonable. or at least predictable 19:07:58 <stevemar> dtroyer_zz: i think he's asking for the pool column to come back 19:08:31 <rtheis> yeah 19:08:39 <stevemar> meteorfox: o/ 19:08:45 <dtroyer_zz> right. what I'm saying is the solution needs to do essentially that without calling nova-net if Neutron is present 19:09:04 <stevemar> dtroyer_zz: we have a meteorfox now :O 19:09:07 <rtheis> agreed 19:09:10 <dtroyer_zz> meteorfox: welcome! 19:09:21 <dtroyer_zz> we;re discussing https://bugs.launchpad.net/python-openstackclient/+bug/1566090 19:09:23 <openstack> Launchpad bug 1566090 in python-openstackclient "Cannot determine network, or pool, a floating ip belongs to without multiple commands" [Undecided,New] - Assigned to Reedip (reedip-banerjee) 19:09:48 <dtroyer_zz> and the short summary is that the pool colum should return, correct? 19:09:48 <meteorfox> hi all, thanks for looking at this 19:10:23 <meteorfox> yeah, pool name or the network id it belongs to 19:10:31 <dtroyer_zz> the cause is the difference between nova-net and neutron AIUI 19:10:46 <dtroyer_zz> so we need to go to a bit of work to produce that, correct? 19:11:47 <meteorfox> yes 19:11:50 <stevemar> dtroyer_zz: not sure how to add that, my neutron knowledge is sad 19:12:34 <dtroyer_zz> meteorfox: your last comment in the bug (#4) is close, except that we need to do it without calling any Nova APIs, as nova-net is suppsoed to go away someday 19:12:36 <rtheis> meteorfox: shouldn't floating_network_id have what you want if the command displayed that? 19:12:49 <meteorfox> basically, my usecase is that I have the name of the floating IP pool, I want to know what floating IP address are available in that pool, if any 19:13:23 <meteorfox> floating_network_id should work 19:14:08 <rtheis> meteorfox: assuming you have the network id then you could use https://review.openstack.org/#/c/298870/ to get availability 19:14:43 <dtroyer_zz> for that specific use case I'd be looking for a —pool option to the list command to do the filtering, but that's a follow-on issue 19:14:52 <dtroyer_zz> we have to have the info first 19:15:20 <meteorfox> yes looks like that might work, when implemented 19:16:05 <dtroyer_zz> if Neutron's list doesn't have an option for full details then this could be painful to generate 19:16:46 <dtroyer_zz> what I think we can do here though is clarify what the expected solution looks like 19:18:52 <meteorfox> Ideally I would like that each floating ip that is listed with 'ip floating list' have an extra column either showing the floating_network_id or the pool name it belongs to, that way I can filter the output for only those I'm interested 19:18:55 <rtheis> I think that the CLI should have the floating_network_id information so it should be able to display it 19:19:00 <dtroyer_zz> I'll leave a note in the bug regarding not using nova-net to fix this, can someone summarize if waiting for the availability spec works or do we need to move ahead with bringing the pool column back? 19:19:21 <dtroyer_zz> ok, that answers my question 19:20:22 <dtroyer_zz> anythign else on this? 19:20:34 <meteorfox> nope :) 19:20:43 <rtheis> thanks 19:21:14 <dtroyer_zz> #topic new meeting time proposal 19:22:17 <dtroyer_zz> sheel started the ML trhead: http://lists.openstack.org/pipermail/openstack-dev/2016-April/091207.html 19:22:17 <stevemar> what are the results of the mailing list? 19:22:28 <dtroyer_zz> and it split here: http://lists.openstack.org/pipermail/openstack-dev/2016-April/091440.html 19:22:50 <dtroyer_zz> there isn't a unanimous choice here 19:23:18 <dtroyer_zz> The even week time is right against the API WG which I'd rather not do 19:24:00 <dtroyer_zz> and Tang wants to move the odd week time from now to the morning (north america) 19:24:47 <dtroyer_zz> of those here, who presumably can make this time, what is the feeling about moving to 1400 UTC? 19:25:34 <rtheis> 1400 on which day? 19:25:40 <dtroyer_zz> it seems that we should maintain more of a separation between the two 19:25:56 <dtroyer_zz> ugh, the agenda says Tuesday 19:26:04 <dtroyer_zz> I can't do more meetings on Tuesday 19:26:20 <rtheis> that conflicts for me with neutron meetings 19:26:28 <rtheis> on Tuesday morning 19:26:51 <rtheis> but I could make it work 19:27:56 <dtroyer_zz> I would rather move the even week earlier yet to help him timezone-wise 19:28:08 <reedip__> sorry 19:28:26 <dtroyer_zz> so it seems we need to keep going, I'll summarize and propose that to the thread… 19:28:53 <reedip__> just woke up 19:29:32 <dtroyer_zz> ok, let's move on 19:29:43 <dtroyer_zz> #topic reviews 19:30:02 <dtroyer_zz> What needs attention? There's been a bunch of traffic this week, nice 19:31:13 <rtheis> I don't have any specific reviews to bring up 19:31:25 <stevemar> i put in a request to release a new KSA version, should happen on monday, it'll push this forward: https://review.openstack.org/276350 19:31:48 <dtroyer_zz> I think we should do a release next week, we have a bunch of stuff in the queue 19:31:57 <stevemar> dtroyer_zz: absolutely 19:32:02 <rtheis> sounds good 19:32:12 <dtroyer_zz> I've started cleaning up release notes, and youse huys jumped on it and I have two more fixes already ;) 19:32:41 <rtheis> thank you for doing the cleanup 19:32:58 <stevemar> dtroyer_zz: next release will be 2.4.0, i don't see a reason for a major version jump 19:33:04 <dtroyer_zz> one thing I've noticed that we need to sort, or I just need to understand better, is we released 2.3.0 on stable/mitaka, but master is still on 2.2.0 so the next has to skip 19:33:21 <stevemar> huh? 19:33:31 <stevemar> what do you mean by master is still on 2.2.0? 19:33:33 <dtroyer_zz> stevemar: no, I want to talk about that in Austin, refresh on the steps and plan what all needs to go in then (breakage, etc) 19:33:54 <dtroyer_zz> 2.3.0 was released on the stable/mitaka branch, to handle a constraints change. 19:34:08 <dtroyer_zz> we can't use it. Look at the current version on master, it reports 2.2.1-devNNN 19:34:14 <stevemar> wtf 19:34:32 <stevemar> how did that happen 19:34:43 <stevemar> oh ... i think i remember 19:34:47 <stevemar> the oslo constraints 19:34:50 <dtroyer_zz> we had to increment Y due to the requirements change 19:34:55 <dtroyer_zz> yup 19:35:00 <stevemar> we should be able to clear that up before austin 19:35:10 <dtroyer_zz> this is why I wish we didn't branch until we actually release 19:36:03 <stevemar> dtroyer_zz: i think it's still 2.4.0 regardless 19:36:14 <stevemar> if we cut from master 19:36:17 <dtroyer_zz> anyway, we have a couple of review series that should either all go in together or wait until after the release, I don't want incomplete things that may need fixing to go in at the last minute 19:36:30 <dtroyer_zz> stevemar: right 19:36:50 <rtheis> ok 19:37:04 <dtroyer_zz> RDO's master packaging is AFU because of this, but I don't really care about that, it's wrong to begin with ;) 19:37:32 <stevemar> what incomplete things are you referring to? 19:37:49 <dtroyer_zz> the ip fixed/floating chain, maybe the server group chain 19:38:29 <stevemar> hmm okay 19:38:29 <dtroyer_zz> we had a number of fixes/updates to options for new commands this release, fortunately the comamnds were new so the compat bits actually don't need to be there 19:38:57 <stevemar> cause we're going to have all of that + the ksa patch (which i think justifies a major version bump) 19:39:00 <dtroyer_zz> putting premature commands in a release doesn't feel right to me 19:39:32 <stevemar> the KSA patch alone justifies a major version bump, cause i don't trust that things won't break 19:39:38 <dtroyer_zz> what we may do is get things cleaned up this week, and release on a SHA from this week, but to it next week 19:39:47 <dtroyer_zz> but do it next week 19:39:52 <stevemar> could do that 19:40:11 <dtroyer_zz> that's why I'm cleaning now. but want to slow down on totally new commands 19:41:07 <dtroyer_zz> more on releases or reviews? 19:41:25 <rtheis> dtroyer_zz: one more thing... 19:41:45 <rtheis> we should be getting sdk bumped soon... is it okay to push those command through that need it? 19:41:58 <dtroyer_zz> new commands? 19:42:01 <rtheis> https://review.openstack.org/#/c/302885/ 19:42:12 <rtheis> https://review.openstack.org/#/c/289716/ 19:42:20 <rtheis> https://review.openstack.org/#/c/281694/ 19:42:27 <rtheis> https://review.openstack.org/#/c/281691/ 19:42:33 <rtheis> https://review.openstack.org/#/c/297063/ 19:42:58 <reedip__> There are actually several of them :) 19:43:03 <dtroyer_zz> this isn't the SDK 1.0 with the new resource stuff, right? 19:43:19 <rtheis> correct 19:43:41 <rtheis> This is 0.8.4 which provides address scopes and router interface enhancements 19:44:04 <rtheis> no new resource stuff 19:44:13 <dtroyer_zz> ok. these are still new commands, but presumably have had a bit more looks that should not need further tweaking 19:44:22 <dtroyer_zz> right? 19:44:34 <rtheis> right 19:45:28 <rtheis> I'm okay with holding them too if you want to 19:45:54 <stevemar> i say do it ;) 19:45:58 <dtroyer_zz> we should be careful about getting sets together, such as the add/remove from the first link rtheis posted 19:46:25 <rtheis> stevemar: do it means merge or hold for next release ? 19:46:32 <stevemar> merge! 19:46:53 <dtroyer_zz> lets move forward with the one that feel complete and should not put us in a position to need to fix them right after the release 19:47:00 <dtroyer_zz> that's my worry 19:47:05 <stevemar> we're behind on parity for basic network functionality, so anything that pushes us forward is good to me 19:47:12 <rtheis> ok 19:47:28 <dtroyer_zz> stevemar wants quantity, I want quality. ;) 19:47:29 <stevemar> (but i'm not ptl, so i don't have to worry about fallout) 19:49:25 <dtroyer_zz> how about… 19:49:28 <dtroyer_zz> #topic bugs 19:50:25 <dtroyer_zz> any hot ones? it looks like there are a bunch of new-ish ones on formatting and messaging 19:50:55 <stevemar> yeah, some guy went happy go lucky and opened a bunch related to keystone servce 19:50:55 <rtheis> https://bugs.launchpad.net/python-openstackclient/+bug/1560157 19:50:57 <openstack> Launchpad bug 1560157 in python-openstackclient ""openstack network list" fails with "An SSL error occurred."" [Medium,Confirmed] 19:51:23 <rtheis> still haven't been able to reproduce this one, but will take another look today 19:51:51 <rtheis> If you have any suggestion, please post to bug. Thanks 19:53:00 <dtroyer_zz> if feels liek we're not setting up the SDK session with a proper verify argument 19:53:32 <rtheis> yeah, I'll check that 19:53:39 <dtroyer_zz> We should see who low we have to go to use the same session for the SDK and KSA/others 19:53:41 <rtheis> https://bugs.launchpad.net/python-openstackclient/+bug/1564447 19:53:42 <openstack> Launchpad bug 1564447 in python-openstackclient "Subnet set removes existing values for repeated options" [Medium,Confirmed] - Assigned to Reedip (reedip-banerjee) 19:53:43 <rtheis> https://bugs.launchpad.net/python-openstackclient/+bug/1564453 19:53:44 <openstack> Launchpad bug 1564453 in python-openstackclient "Port set removes existing values for repeated options " [Medium,In progress] - Assigned to Reedip (reedip-banerjee) 19:53:58 <rtheis> It would be nice to fix these for next release since the commands are new 19:54:08 <dtroyer_zz> these set commands are fun that way. 19:54:15 <rtheis> :) 19:54:31 <dtroyer_zz> is this a case of needing to have all of the items for the POST/PATCH call? 19:54:44 <rtheis> yes, I think so 19:54:56 <dtroyer_zz> but yes, we should push that up before release if possible 19:55:19 <rtheis> we should have them all, just need to append with options specified 19:55:55 <rtheis> reedip__: do you think you'll have time to handle both? 19:56:11 <reedip__> rthies: WIll share the updated patch in a few hours 19:56:19 <dtroyer_zz> cool, thanks 19:56:22 <rtheis> thanks 19:56:32 <dtroyer_zz> 4 minutes, any other bugs? 19:56:40 <rtheis> nothing else from me 19:57:10 <reedip__> I can discuss my queries on #sdk 19:57:28 <dtroyer_zz> #topic open discussion 19:57:38 <dtroyer_zz> time is short, but anything else we should hear about? 19:57:47 <reedip__> discussed with stevemar yesterday 19:58:02 <reedip__> wanted to know how to implement clientcommand extension of neutronclient in OSC 19:58:16 <reedip__> rtheis has some patches, but I was confused in the implementation 19:58:39 <dtroyer_zz> do you mean OSC plugins in neutronclient? 19:58:50 <reedip__> correction: rthies has some patches detailing some information in python-neutronclient * 19:59:11 <reedip__> dtroyer_zz : OSC plugins for projects, which use Neutronclient extensions 19:59:34 <reedip__> for example : Tap-as-a-service, networking-sfc, l2gw 19:59:38 <rtheis> reedip__: neutronclient could use its own python bindings or the sdk binding already available 19:59:42 <reedip__> should I move this to the #sdk as well ? 19:59:54 <dtroyer_zz> yes, there will be time there 20:00:01 <reedip__> okay, moving 20:00:31 <dtroyer_zz> and that's time 20:00:35 <dtroyer_zz> thanks everyone! 20:00:39 <dtroyer_zz> #endmeeting