19:04:00 <dtroyer> #startmeeting openstackclient
19:04:00 <openstack> Meeting started Thu Feb  4 19:04:00 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:04:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:04:04 <openstack> The meeting name has been set to 'openstackclient'
19:04:16 <MeganR> Hi
19:04:36 <dtroyer> Hi MeganR, who else do we have here?
19:05:58 <dtroyer> courtesy ping: dhellmann, stevemar, terrylhowe, lhcheng, dstanek
19:08:00 <dtroyer> quiet day...
19:08:21 <dtroyer> #topic release
19:08:34 <singhj> hi
19:08:50 <MeganR> not a bad thing - sometime coming up I will reach out to you offline to discuss the Product WG roadmap - and make certain we are on the same page
19:08:58 <dtroyer> I sent the review to release 2.1.0 this morning, stevemar did the u-c update that I missed a little while ago
19:09:10 <dtroyer> MeganR: ok, sounds good
19:10:21 <dstanek> hi all
19:11:16 <dtroyer> 2.1.0 is the first release with the SDK as a prereq and the new network commands
19:12:28 <dtroyer> We should have at least one more release before we designate our Mitaka stable branch, with the hurdle of the SDK integration done, we will be able to do more frequent releases again
19:12:46 <MeganR> interesting, thank you for the information
19:12:49 <rtheis> sounds good
19:13:19 <dtroyer> #topic reviews
19:13:33 <dtroyer> Are there reviews anyone wants to discuss?
19:14:04 <rtheis> I don't have any
19:14:25 <dtroyer> I saw Tang abandon and re-propose a bunch for his job change.
19:14:50 <dtroyer> That really wasn't necessary, and we lost some comment history doing that.
19:15:14 <rtheis> yeah, exactly...I was trying to restore some of that history/comments
19:15:23 <dtroyer> So anyone with comments in the earlier reviews needs to see if they still aplly to the current ones
19:15:30 <dtroyer> rtheis: right
19:17:00 <dtroyer> Also, I mentioned that it seemed like there were a lot of tightly related small reviews.  I find it clumsy to have to bounce back and forth to compare the set when they could have easily been done in a single review.
19:17:22 <dtroyer> Finding the balance here is totally a personal opinion
19:17:56 <dtroyer> For example, early on we would do an entire set of resource CRUD commands in a single review, rather than one per.
19:18:28 <dtroyer> That may seem too big to some, as recently it seems like they are one command per review.
19:19:11 <dtroyer> I think those are the two edges of acceptable…
19:19:30 <rtheis> dtroyer: ok, do you have a preference?
19:20:06 <dtroyer> My guideline is around what I need to keep in my head to review the code
19:20:21 <MeganR> dtroyer: is this documented, thinking of having something to refer to in the future.
19:20:36 <dtroyer> so adding a command, its tests, fakes/fixtures, docs, etc at once is the minimum
19:20:36 <MeganR> not just what you need to keep in your head
19:21:14 <dtroyer> I don' tknow where it is documented, most projects eventually settle on what is acceptable to them
19:21:45 <dtroyer> we have slowly drifted toward smaller and smaller chunks
19:22:06 <MeganR> ok, I am working on bringing in one or two people, and was thinking about preferences/process
19:22:44 <dtroyer> I hate to say it is just common sense, because 'common' doesn't mean the same thing to everyone
19:22:52 <MeganR> so true!
19:23:30 <dtroyer> Akihiro recently had a review that had a huge number of files in it, but it was all to do the same thing across the project, I found that fine
19:24:08 <dtroyer> and I know stevemar likes them small
19:24:25 <dtroyer> since he isn't here to argue with me about it ;)
19:24:38 <rtheis> :)
19:24:44 <MeganR> good timing  :)
19:25:36 <dtroyer> I just looked at some of the long outstanding reviews in the dashboard… rtheis is https://review.openstack.org/256070 still good to go?  I think we just lost track of it over the holidays
19:25:58 <rtheis> dtroyer: yes it is.
19:26:21 <dtroyer> ok, thanks… +A
19:26:34 <rtheis> thanks
19:27:16 <dtroyer> and we missed terrylhowe's log levels review https://review.openstack.org/#/c/211682/, we should bump that back up
19:28:03 <rtheis> ok
19:28:28 <dtroyer> anything else?
19:29:04 <rtheis> nothing else from me
19:29:11 <MeganR> I'm good.
19:29:19 <terrylhowe> just lurking, nothing from me
19:29:29 <dtroyer> #topic bugs
19:29:39 <dtroyer> anything here?
19:30:51 <dtroyer> ok...
19:30:53 <terrylhowe> https://bugs.launchpad.net/python-openstackclient/+bug/1541905
19:30:54 <openstack> Launchpad bug 1541905 in python-openstackclient "identity common find throws excetion" [Undecided,New]
19:31:41 <dtroyer> I know we handle that error in at least some places, but I think it is in the commands themselves
19:31:43 <terrylhowe> Seems like this topic has come up before, but I was trying to do an image share and I didn’t have keystone access to projects
19:32:02 <stevemar> oh my, i forgot all about this, was out to lunch
19:32:14 <dtroyer> and my recollection is because sometimes it is an error in find and sometimes it can be worked around
19:34:12 <stevemar> dtroyer: i do like small reviews! i'm not that smart, so the smaller the better for my small brain
19:34:36 <anteaya> ++ small reviews
19:34:55 <dtroyer> I bet I could make some that were too small for even you stevemar ;)
19:35:16 <stevemar> terrylhowe: dtroyer the error is... well we have to do that for all the possible look ups
19:35:32 <stevemar> terrylhowe: do you have any metrics on how often we hit that code?
19:35:50 <terrylhowe> I just added a note to what I was doing and leave it out there
19:36:04 <stevemar> ideally the get(id) get(name) and list(name=name), should hit most of the common cases
19:36:19 <stevemar> the find call shouldn't happen too often
19:37:07 <stevemar> dtroyer: mfisch opened a bug yesterday
19:37:22 <stevemar> out help output is a bit janky
19:37:29 <dtroyer> a bit?
19:37:44 <stevemar> https://bugs.launchpad.net/python-openstackclient/+bug/1541651
19:37:46 <openstack> Launchpad bug 1541651 in python-openstackclient "confusing options when using the admin token" [Undecided,New]
19:38:01 <stevemar> he had to go to the docs to find the os-url & os-token combination
19:38:09 <stevemar> oh another help related bug..
19:38:10 <dtroyer> o-c-c will fix all of this, right?  'cause it now owns the auth plugin interface...
19:38:17 <stevemar> https://bugs.launchpad.net/python-openstackclient/+bug/1541047
19:38:19 <openstack> Launchpad bug 1541047 in python-openstackclient "openstack --help fails if clouds.yaml cannot be read" [Medium,New]
19:38:45 <stevemar> dtroyer: that's the goal :)
19:39:17 <terrylhowe> there is another bug related to Matt’s
19:40:04 <dtroyer> stevemar: a bad goal but oh well
19:40:18 <stevemar> dtroyer: don't be hatin'
19:41:22 <dtroyer> terrylhowe: this one? https://bugs.launchpad.net/python-openstackclient/+bug/1538804
19:41:22 <openstack> Launchpad bug 1538804 in python-openstackclient "Default install of latest python-openstackclient fails to recognize the OS_DOMAIN_NAME environment variable" [Undecided,Confirmed]
19:42:09 <terrylhowe> that too, I thought I created one, but can’t find it now, either way, I think it is a problem
19:42:19 <terrylhowe> It may be an occ issue for sure
19:42:36 <dtroyer> I have on my list to create a big pile-o-tests in o-c-c for our use case
19:43:02 <stevemar> i'll admit i haven't had much time for osc dev this cycle, otherwise i'd jump in and fix it all up
19:43:23 <dtroyer> I don' tknow where your time has gone <cough>keystone</cough>
19:43:23 <stevemar> but it seems like it's just not big enough of a problem, just yet
19:43:40 <dtroyer> my problem there is building an env to dupe/test it
19:43:44 <stevemar> on the plus side, we're making awesome headway with neutron commands!
19:43:48 <stevemar> dtroyer: pfft who cares abotu keystone
19:44:12 <dtroyer> IKR?
19:44:54 <dtroyer> any other bugs?
19:45:50 <dtroyer> #topic open discussion
19:46:03 <dtroyer> what else shall we kick around here?
19:46:47 <stevemar> dtroyer: i'm excited about the new release
19:47:07 <stevemar> dtroyer: i'll be releasing a new keystoneclient eventually, as we approach m3 deadline
19:47:31 <terrylhowe> definitely a lot of awesomeness in the next release
19:47:59 <dtroyer> it is a milestone for us, for sure
19:48:01 <stevemar> so i'll be looking to flip the switch on this https://review.openstack.org/#/c/255363/ and ask for another osc release (eventually)
19:48:31 <dtroyer> k
19:48:37 <stevemar> i'm assuming we have one more osc relase before we close up mitaka
19:48:52 <dtroyer> at least one more, yes
19:49:08 <rtheis> I have a question about list command filtering options...
19:49:14 <dtroyer> I think we're out of the wait-for-big-thing-to-happen phase of our releases now
19:49:25 <dtroyer> rtheis: go
19:49:32 <rtheis> Take for example "neutron router-port-list"
19:49:51 <rtheis> This is basically "neutron port-list" with a filter on the router's ports
19:50:04 <dtroyer> ok
19:50:12 <rtheis> in osc, would that translate to "port list --router <router>"
19:50:28 <dtroyer> maybe?
19:50:38 <dtroyer> is our 'port' resource really 'router port'?
19:51:14 <rtheis> 'port' resource is a generic port with router being a specific device
19:51:50 <terrylhowe> or generic —query router=123 ?
19:52:00 <stevemar> i say `osc port list --router <router` works for now
19:52:22 <rtheis> yeah, I think is query on the list request
19:52:34 <dtroyer> assuming there might also be 'port list —foo <foo-name>' down the road for other port types?
19:52:50 <rtheis> there could be
19:53:21 <dtroyer> when I first saw this my thought was we should flip it and use 'router list —port' to get a list of a specific router's ports
19:53:43 <terrylhowe> that would be confusing to list ports there
19:53:50 <dtroyer> but that fails in the 'what resource is being shown' test
19:53:58 <dtroyer> yeah
19:54:25 <dtroyer> rtheis: I think you are on the right track
19:55:12 <rtheis> dtroyer: sounds good, singhj (Jas) and I will go down that road
19:55:54 <dtroyer> cool
19:55:57 <dtroyer> anything else?
19:56:13 <rtheis> nothing else
19:57:06 <terrylhowe> nada
19:57:22 <dtroyer> well alrighty then
19:57:25 <dtroyer> thanks everyone!
19:57:29 <dtroyer> #endmeeting