19:02:12 <dtroyer> #startmeeting OpenStackClient
19:02:13 <openstack> Meeting started Thu Jan 28 19:02:12 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:16 <openstack> The meeting name has been set to 'openstackclient'
19:02:16 <dtroyer> Anyone here?
19:03:34 <Megan> o/
19:04:15 <dtroyer> Hi Megan!
19:04:42 <Megan> Hi
19:04:51 <rtheis> o/
19:04:55 <Megan> If it is just me, then it is going to be a very short meeting!
19:04:59 <Megan> oh - saved!!
19:06:10 <dtroyer> well, it still may be short ;)
19:06:38 <dtroyer> rtheis: what is on your mind today?
19:06:40 <Megan> I promise not to complain  :)
19:07:23 <rtheis> I was thinking about https://bugs.launchpad.net/python-openstackclient/+bug/1537856 as we start to roll out more network commands
19:07:25 <openstack> Launchpad bug 1537856 in python-openstackclient "Deletes with nargs should follow a consistent pattern" [Undecided,New]
19:07:52 <rtheis> There was some discussion in related review that terrylhowe had
19:08:23 <dtroyer> yeah, we should be consistent there…
19:08:56 <dtroyer> I'm not sure I have a strong opinion (yet?)
19:09:00 <terrylhowe> I’m not sure the best implementation or maybe just copy/pasta to each command
19:09:05 <rtheis> ok
19:09:09 <dtroyer> but we should write it up and add to the deveoper docs when it is sorted
19:09:37 <rtheis> so maybe start the issue with a patch set to developer docs on the approach and then start to implement?
19:10:25 <dtroyer> that's a good idea, although working it out in code the first time is fine too
19:10:30 <dtroyer> or both together even
19:10:35 <rtheis> sounds good
19:10:51 * dtroyer caught up reading
19:11:00 <dtroyer> I think I'm on board with the conclusions there
19:11:11 <dtroyer> let's see if I have it:
19:11:28 <dtroyer> a) delete as many resources as possible (don't abort on a failure)
19:11:46 <dtroyer> b) show a message on individual failures so the user knows which ones
19:12:01 <dtroyer> c) return non-zero for any failures
19:12:07 <terrylhowe> yes
19:12:10 <rtheis> yep
19:12:27 <dtroyer> cool, lets head that direction
19:13:01 <dtroyer> what else?
19:13:37 <dtroyer> I started going through merged reviews and making release notes for user-visible changes that didn't have them
19:13:50 <dtroyer> https://review.openstack.org/273686
19:14:09 <rtheis> thanks, I'll take a look
19:14:10 <dtroyer> hoping to do a release early next week
19:14:30 <dtroyer> it's been long enough, even though there are not as many of the network commands merged as we hoped
19:14:50 <rtheis> ok
19:14:51 <terrylhowe> there are a lot of new features
19:14:59 <dtroyer> also, did we decide that the SDK introduction required a major bump? or not?
19:15:11 <dtroyer> I just thought of that now
19:15:25 <rtheis> I don't recall.
19:16:01 <dtroyer> for dependency changes we add openstacksdk, remove neutronclient
19:16:22 <dtroyer> otherwise no CLI-breaking changes occurred
19:16:23 <terrylhowe> 3.x or 2.1 you mean?
19:16:27 <dtroyer> right
19:16:45 <dtroyer> dhellmann: around?   ^^^^^
19:16:46 <terrylhowe> it isn’t a major change from the user perspective
19:16:56 <terrylhowe> other than new features
19:17:01 <dhellmann> dtroyer : o/
19:17:02 <terrylhowe> so, tought call for me
19:17:02 <dtroyer> I don't think so, but I recall hearing that the dep change forced it
19:17:39 <dtroyer> dhellmann: summary: we added the openstacksdk to OSC since the 2.0.0 release in Dec.  For some reason I'm wondering if that triggers a major bump
19:17:49 <dhellmann> for dep changes we encourage a minor version bump at least, to indicate to packagers and deployers that they may not be able to just drop the new version in place
19:17:57 <dtroyer> otherwise we didn't do anything that I think requires a major
19:18:04 <dhellmann> if the API of OSC doesn't change when the SDK is added, that shouldn't require a major version bump
19:18:19 <dtroyer> ok, we would do 2.1 otherwise, so it sounds like we're good with that
19:18:20 <dtroyer> thanks
19:18:30 <dhellmann> yep, that should be good
19:18:39 <dtroyer> fortunately, the SDK changes (so far) are all additive
19:19:29 <dtroyer> anything else?
19:19:44 <dtroyer> I do need to leave a bit early anyway, and don't have more on my list
19:19:47 <rtheis> Nothing else here
19:20:12 <terrylhowe> only thing here is LingXian was going to take a shot at some subnet commands
19:20:41 <dtroyer> subnet list was merged
19:20:44 <terrylhowe> I showed him the patch that had all the commands implemented and it is a matter of making up tests, etc
19:21:00 <terrylhowe> yeh, so just need the rest of the crud
19:21:07 <dtroyer> ok.  at this point I don't think we should block a release on those
19:21:14 <dtroyer> if they're ready, great
19:21:14 <terrylhowe> agreed
19:22:12 <dtroyer> ok, if there isn't anything else, I'll release the meeting lock early…
19:22:17 <terrylhowe> that’s all from me
19:22:42 <dtroyer> cool
19:22:47 <dtroyer> thanks everyone!
19:22:50 <dtroyer> #endmeeting