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