18:03:29 <dtroyer> #startmeeting OpenStackClient
18:03:29 <openstack> Meeting started Thu Feb 26 18:03:29 2015 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:03:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:03:33 <openstack> The meeting name has been set to 'openstackclient'
18:03:39 <dtroyer> anyone here for the first annual OSC meeting?
18:03:55 <stevemar> o/
18:04:30 <stevemar> dtroyer, rounding up the troops
18:04:38 <stevemar> sigmavirus24, might be interested
18:04:46 <sigmavirus24> oh yes
18:04:47 <sigmavirus24> sorry
18:04:52 * sigmavirus24 never added a reminder for this
18:05:20 <stevemar> sigmavirus24, i have a notification go off for 'openstackclient'
18:05:30 <dhellmann> o/
18:05:35 <briancurtin> hello
18:05:51 <lhcheng> o/
18:05:54 <stevemar> dtroyer, i think we have enough trouble makers / people
18:05:58 <dtroyer> ok, let's get started
18:06:01 <dtroyer> #topic meeting time
18:06:42 <dtroyer> first off, stevemar and I picked this time and I'd like to just confirm that with everyone...
18:06:53 <dhellmann> thursdays are generally bad for me; it just happens that I had a free slot today
18:07:09 <dhellmann> maybe we can set up a doodle?
18:07:17 <sigmavirus24> Thursdays are my "meeting" day usually 8-12 so I can do 8-1 if necessary
18:07:27 <dtroyer> me too, this is the third in a row…
18:07:52 <dtroyer> a doodle sounds fine, I've not done one, can yo do that dhellmann?
18:07:55 <dhellmann> I could probably make it work later in the day if thursday is the day others prefer
18:07:58 <dhellmann> sure
18:08:06 <dhellmann> #action dhellmann set up doodle for meeting times
18:08:32 * sigmavirus24 isn't too picky
18:08:36 <dtroyer> thanks
18:08:46 <dtroyer> #topic project status
18:09:10 <dtroyer> this is a bit vague, I know, but specifically I'm talking about 'official OpenStack project' status
18:09:12 <dhellmann> what's the relationship/overlap between this group and the sdk group? there's an sdk meeting on tuesday, should we consider merging? or are there really different teams?
18:09:51 <dtroyer> dhellmann: there is overlap, maybe that would work, but it personally doesn't work for me during non-DST times
18:09:52 <briancurtin> there's some overlap in teams, but we've been having meetings go 50-60 minutes
18:09:59 <dhellmann> dtroyer: ok
18:10:11 <dhellmann> briancurtin: ok, sounds like we should keep those separate, then
18:10:30 <dhellmann> sorry, dtroyer, carry on :-)
18:11:04 <dtroyer> on project status, our plan is to go ahead and apply for officialdom with the TC Real Soon Now and finally end the nearly three year limbo
18:11:35 <dtroyer> I put together https://etherpad.openstack.org/p/osc-project to summarize where I think we are and what needs to happen
18:11:39 <stevemar> infra brought up the projects status last week i think? dtroyer made this etherpad https://etherpad.openstack.org/p/osc-project
18:12:02 <dtroyer> this meeting was the last major piece of that
18:12:39 <dtroyer> anyway, other than information I don't have much more to say there unless there are questions or concerns?
18:13:02 <stevemar> i don't anticipate much push back on the proposal
18:13:10 <stevemar> helps that we've been around
18:13:29 <dhellmann> dtroyer: do you want to shift ownership of cliff to this team at the same time?
18:13:31 <dtroyer> me either, mostly looking for a sanity check or other missing things
18:13:46 <dhellmann> the reviewers and contributors are mostly out of this group anyway, and we just stuck it into oslo because it needed a home at the time
18:13:55 <dtroyer> dhellmann: leading to the next agenda point then
18:14:02 <dtroyer> #topic cliff repo
18:14:05 <dhellmann> oops, sorry, first I'm behind now I'm ahead :-)
18:14:09 <dtroyer> np
18:14:36 <dtroyer> I am fine with taking ownership of cliff, I really wasn't sure how much it is used elsewhere
18:14:49 <dhellmann> it is used outside of openstack and in the neutron command line client
18:15:16 <dhellmann> we would want to have the oslo team agree, obviously, but I don't expect objections
18:15:29 <dhellmann> and of course it would depend on whether this team wants to do it :-)
18:15:34 <stevemar> kinda like how pycadf was off-loaded to keystone
18:15:37 <dhellmann> that's right
18:15:46 <sigmavirus24> dtroyer: that etherpad looks good to me
18:15:46 <dtroyer> unless there are objections I'll add that to the project proposal and we can go from there
18:15:49 <dhellmann> and hacking to qa
18:16:26 <stevemar> i'm okay with it, more responsibility to review things, but the code base is small
18:16:40 <dhellmann> at those hand-off points we extended invitations to the existing core reviewers to be kept on the review team, and it would be nice to do that for cliff as well (they are there as part of the oslo-core team now)
18:16:55 <dhellmann> stevemar: up until very recently it hasn't changed that much, either
18:17:25 <dtroyer> ok, seems good to go then
18:17:37 <dtroyer> #action dtroyer to add cliff repo ownership to project proposal
18:17:38 <dhellmann> I'll bring it up with the oslo team
18:17:50 <dhellmann> #action dhellmann discuss cliff ownership change with oslo team
18:17:55 <dtroyer> thanks dhellmann
18:18:18 <dtroyer> #topic release schedule
18:18:54 <dtroyer> I'd like to talk a bit about release frequency
18:19:27 <dtroyer> we've historically gone way too long between releases, and I think roughly once a month would be better for $REASONS
18:19:55 <stevemar> as much as i'd love to see osc have a regular release every X weeks, i will always have trouble around this time, (the crunch time for the third milestone for a release)
18:20:24 <dtroyer> I don't want to be rigid, and this is actually a good time to not to anything radical anyway
18:20:44 <dtroyer> but was looking for other thoughts about that
18:20:54 <dhellmann> dtroyer: do you think once a month is a minimum, or a maximum? or average?
18:20:56 <lhcheng> how about once a month *only if there are major features added?
18:21:28 <dtroyer> I was thinking average, weighted by the quantity of features/bugs contained
18:21:47 <dhellmann> ttx has put together some release models as part of the ongoing big-tent governance changes: https://review.openstack.org/#/c/157322/
18:22:07 <stevemar> there usually is one cool new feature that gets added per month, usually a new command
18:22:10 <stevemar> or new options
18:22:23 <dhellmann> it sounds like we would be "independent", although we should also address whether we're going to do stable branches
18:22:39 <lhcheng> once a month is about right then..
18:23:05 <dtroyer> I don't want to do stable branches, except maybe for major releases.  and maybe that's part of how we define a najor release
18:23:39 <dhellmann> major as in X.y.z or x.Y.z?
18:24:02 <dtroyer> X.   based on the recent conversations, IIUC
18:24:27 <dhellmann> ok, so that's X.Y.z in practice, which is similar to what oslo is doing
18:25:04 <dhellmann> (we only maintain one version of a given stable branch, and it tends to be the X.Y because we haven't had backwards-incompatible releases yet)
18:25:19 <dtroyer> the sorts of things I think will trigger an X release is adding support for os-client-config, which will have a major impact on the global command options
18:25:26 <stevemar> ++ for X changing for major releases
18:25:40 <stevemar> dtroyer, agreed
18:25:45 <dtroyer> even though it will be largely compatible.  also, things like changing out the underlying libs would probably do that too
18:26:03 <stevemar> like removing requirements and leveraging sdk?
18:26:04 <dhellmann> that's not necessary, based on semver, if our API is the command line interface
18:26:08 <stevemar> trying to read between the lines here
18:27:13 <dtroyer> yes, I consider our primary API the comamnd line.  But I also think major changes inside the code are good times for major relases too just for maintenance sanity
18:28:01 <dtroyer> looking back, the introduction of the auth plugins might have caused that had we been past 1.0 then
18:28:25 <dhellmann> yeah, I guess it would depend on what those are. If we're changing implementation someone else would use in a plugin that should be a major bump, for example.
18:28:28 <dtroyer> one reason is that these are times when plugins will likely be affected
18:28:34 <dhellmann> exactly
18:28:42 <dhellmann> ok, I think we're saying the same thing
18:29:36 <dtroyer> so averaging one release a month, give or take, will be our target
18:29:39 <dtroyer> any objections?
18:29:50 <sigmavirus24> seems like a good cadence
18:30:05 <dhellmann> +1
18:30:13 <stevemar> +1
18:30:29 <dtroyer> #agreed OSC releases will be roughly one per month or as required
18:30:30 <lhcheng> +1
18:31:19 <dhellmann> devstack is using osc, right? do we need stable branch support for that to continue to be safe?
18:32:02 <dtroyer> it is.  we're pinning OSC on stable branches of DevStack, so unless something arises there I don't think so
18:32:46 <dhellmann> I suppose we can always create them retroactively if we find we need to fix a bug and can't update to a newer minor version
18:33:54 <dtroyer> right.  and that's one place where we may not be able to stick to the major-only stable branch because of transient deps.  the current pin is because of the changes in one of the second (or more) order dependencies
18:34:36 <dtroyer> #topic bug review
18:34:56 <dtroyer> I'm moving rather quickly because I need to leave a bit early, so stop me if I go too fast...
18:35:26 <dtroyer> are there any current bugs that need attention?  I haven't been through the list in a while…
18:37:07 <dtroyer> is there a /crickets emoji?
18:37:19 <stevemar> neither have i, i've been trying to deflect bad ones away quickly
18:37:19 * dhellmann is looking at the bug list
18:37:38 <stevemar> i *try* to stay on top o fit
18:37:39 <dtroyer> some fo them are really more feture requests, and need to implement more stuff
18:37:57 <dtroyer> volume v2 for example should be converted to a bp
18:38:04 <stevemar> 2 new ones came in, action-list from tim, and volume v2
18:38:22 <stevemar> and a neutron functionality one, which should be a BP, also
18:38:33 <stevemar> terrylhowe, will have some interest in ^
18:38:34 <dtroyer> yup
18:38:56 <stevemar> lhcheng, has reviews up for 1423748
18:39:08 <terrylhowe> there used to be bp/neutron
18:39:19 <stevemar> and 1421328 need to specify domain with role list - is ughhhh valid
18:40:20 <stevemar> the rest a spill over from things thta didn't make 1.0.2
18:40:25 <stevemar> terrylhowe, the BP still existsw
18:41:05 <dtroyer> I'm hoping I can get back to more OSC work soon…and get caught up.
18:41:52 <stevemar> dtroyer, i'll dive back in post-keystone-FF
18:42:04 <dtroyer> I've got about 10 min…
18:42:08 <dtroyer> stevemar: thanks
18:42:10 <dtroyer> #topic open discussion
18:42:20 <stevemar> dtroyer, lets give terrylhowe a few minutes for neutrony stuff
18:42:21 <dtroyer> anything?
18:42:27 <dtroyer> ok
18:42:30 <stevemar> whats the direction here
18:43:08 <stevemar> at one point terrylhowe had a bunch of patches for stuff, but i think there is a knowledge gap (at least I know nothing about neutron)
18:43:21 <stevemar> and now we have some APIs for neutron
18:43:23 <terrylhowe> I have to follow up on dtroyer latest comments and make subnet crud less neutrony :)
18:43:27 <dtroyer> my entire hesitation with those reviews was the amount of neutronclient practices they contained
18:44:14 <stevemar> right, is there anything we can do to mitigate the neutronclient practices (aside from using our built-in API requests)
18:44:38 <dhellmann> "practices"? as in the way the client library works, or the neutron API works?
18:44:50 <dtroyer> actually, yes.  I did a couple that were very similar to the other command classes.
18:45:07 <stevemar> dhellmann, let me find you an example
18:45:25 <dtroyer> as in how the client library is structured.  and the amount of class composition and inheritance going on.
18:45:46 <terrylhowe> I think I got rid of all that dtroyer
18:46:11 <terrylhowe> I assumed you were talking about the way the parameters were being handled not being to OSC standards
18:46:29 <dtroyer> terrylhowe: ok, good.  last I remember there was still a bunch of calls into their class discovery stuff and whatnot
18:46:36 <terrylhowe> at least with the subnet crud
18:47:25 <dtroyer> ah, right, one of the things I wanted to talk about was specifying begins and end values for a thing, that was one example
18:47:48 <dtroyer> and terrylhowe, if you;ve done anything to it in the last (almost) week I haven't looked
18:47:55 <terrylhowe> https://review.openstack.org/#/c/84782/
18:48:17 <stevemar> dhellmann, for instance, this has to be done for all returned data: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/network/v2/network.py#L28-L42
18:48:40 <terrylhowe> no changes since 2/11, but it is high priority after I get my current work item out of the way
18:49:00 <dtroyer> ok…I'll make time over the weekend to catch up here.
18:49:05 <terrylhowe> I should be freed up to put more effort in general to OSC  soon
18:49:10 <dhellmann> stevemar: thanks
18:49:19 <dtroyer> and let's talk about my complaint with the —allocation-pools format next we
18:49:24 <dtroyer> week
18:49:43 <stevemar> dhellmann, just look at that file, seems we need to create a lot of helper functions for neutron
18:50:06 <terrylhowe> yeh, that’s a good example stevemar
18:50:27 <dtroyer> and I need to run.   I'll endmeeting and you guys can keep talking, will catch up in a few hours
18:50:36 <dtroyer> #endmeeting