19:02:53 <dtroyer_zz> #startmeeting OpenStackClient
19:02:54 <lhcheng> o/
19:02:54 <openstack> Meeting started Thu Jul 23 19:02:53 2015 UTC and is due to finish in 60 minutes.  The chair is dtroyer_zz. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:57 <openstack> The meeting name has been set to 'openstackclient'
19:03:02 <terrylhowe> o/
19:03:10 <sigmavirus24> o/
19:04:20 <dtroyer_zz> Ok, let's start with the usual bits
19:04:24 <dtroyer_zz> #topic bugs
19:04:43 <dhellmann> o/
19:04:49 <dtroyer_zz> anything needing eyes?
19:06:11 <dtroyer_zz> wow, is this a fast meeting today?
19:06:29 <ajayaa> Hi. Is anyone working on the go client library?
19:06:54 <dtroyer_zz> ajayaa: I was the last one to touch it afaik, we can talk further about it after the OSC meeting is done
19:07:09 <ajayaa> dtroyer_zz, okay.
19:07:57 * stevemar sneaks in late
19:08:05 <dtroyer_zz> so https://bugs.launchpad.net/python-openstackclient/+bug/1477629 is new this morning, I was looking at it and have a question on the output of a security group rule
19:08:06 <openstack> Launchpad bug 1477629 in python-openstackclient "ICMP secgroup rule must have --dst-port -1 to actually allow ICMP" [Medium,Triaged]
19:08:06 <uvirtbot> Launchpad bug 1477629 in python-openstackclient "ICMP secgroup rule must have --dst-port -1 to actually allow ICMP" [Medium,Triaged]
19:08:08 <uvirtbot> Launchpad bug 1477629 in python-openstackclient "ICMP secgroup rule must have --dst-port -1 to actually allow ICMP" [Medium,Triaged] https://launchpad.net/bugs/1477629
19:08:30 <stevemar> there have been a bunch of patches about volume that need love
19:08:39 <dtroyer_zz> right now for ICMP rules, 'port_range' is always present in the output but blank.  should we drop it for ICMP only?
19:08:40 <stevemar> i'm tempted to just take over them
19:08:40 <terrylhowe> I was messing with that one, I believe it, but did not confirm
19:09:04 <sigmavirus24> stevemar: so turn up the volume so they get more love?
19:09:06 <dtroyer_zz> I confirmed it in IRC this morning with jordanp
19:10:01 <stevemar> sigmavirus24: i've already helped out the author(s) on a few patches now, on getting the hang of gerrit and such
19:10:14 <dtroyer_zz> ok, sop lets talk reviews then
19:10:14 <stevemar> i'll help the noobies out again, just need a bit of time away
19:10:18 <dtroyer_zz> #topic reviews
19:10:25 <sigmavirus24> stevemar: I was making a pun
19:10:42 <stevemar> sigmavirus24: yeah, i noticed taht :) but i figured there was a real question in there too
19:10:47 <sigmavirus24> no not really
19:10:48 <sigmavirus24> =P
19:10:53 <stevemar> hue hue
19:11:10 <dtroyer_zz> I figured once he got one sorted out to go back and fix the rest to match
19:11:39 <terrylhowe> question about that volume list one...
19:11:54 <stevemar> we really need another release soon, but at this point it's easier to just wait til all the volume commands are done
19:12:18 <stevemar> heha and jiaxi are doing the last few
19:12:27 <terrylhowe> https://review.openstack.org/#/c/204325/
19:13:06 <stevemar> terrylhowe: what about it/
19:13:07 <stevemar> ?
19:13:20 <terrylhowe> heha had a —name option and another option for query, it seems like it would be good to have a general —query option for lists
19:13:33 <terrylhowe> so OSC doesn’t have to know what is supported
19:13:37 <stevemar> i think he's just going for v1 parity at this point
19:13:41 <terrylhowe> people could use it for limit, marker or fields
19:13:51 <dtroyer_zz> I disagree.  then it is on the user to know what to do
19:14:16 <dtroyer_zz> although the common functions must be the same as much as possible, even if we need to do some work client-side
19:14:26 <terrylhowe> well we could offer —limit and —maker on everything, but they don’t all suport it
19:14:38 <dtroyer_zz> which is why some of that may need to be done client-side
19:14:39 <terrylhowe> and even then, it might not be enabled for a service or something
19:14:48 <dtroyer_zz> with some smart-ish data caching it isn't too painful
19:15:08 <terrylhowe> just bound to be wrong and incomplete is all
19:15:15 <terrylhowe> that is fine though
19:15:19 <dtroyer_zz> any service that makes limit/marker optional and doesn't tell us how to know if it is on or off is broken
19:15:48 <dtroyer_zz> we've been wrong and incomplete since day 1.  always will be.  but it's better than everything else
19:16:26 <stevemar> keep that cheery attitude out of this dtroyer_zz
19:16:50 <terrylhowe> so you think all list commands should have —limit and —marker?
19:17:04 <dtroyer_zz> eventually, in some fashion, yes, they should all support paging
19:17:07 <stevemar> limit yes, marker ... harder to get there
19:17:24 <dtroyer_zz> I'm not convinced that our APIs have that sorted out yet
19:17:28 <stevemar> listing all users, and paging will never work
19:17:31 <terrylhowe> I doubt it
19:17:46 <dtroyer_zz> stevemar: right, which is why I'm hedging with 'some' and not 'all' functionality
19:18:01 <stevemar> ja
19:18:21 <terrylhowe> that is why I like a generic —query option and let the user do what they can, but I’m not attached
19:18:25 <dhellmann> would it make sense to put the options in a base class for list commands, with a class attribute to disable them for APIs that don't support them?
19:18:39 <dhellmann> (the marker and limit options, that is)
19:18:48 <stevemar> dhellmann: thats what i was advising abhide to do
19:18:59 <dhellmann> stevemar: great minds, yadda yadda
19:19:13 <dtroyer_zz> dhellmann: probably, in some fashion.  but the fun of neutronclients over-normalization doing that made me think twice before going too far dopwn that path
19:19:50 <dhellmann> dtroyer_zz: maybe multiple lister base classes, then, for different patterns?
19:20:00 <dtroyer_zz> every API is a special snowflake so we really can't do a lot at the lowest levels common
19:20:03 <dhellmann> and file bugs for whichever APIs we find that use the pattern we don't like
19:20:51 <dtroyer_zz> ya, I'm with you… its doing it in practice…  we started talking about paging in, where, San Diego?  Still nothing common
19:21:14 <dhellmann> yeah
19:21:36 <dhellmann> maybe the new api working group can help with that, if we feed them some specific data
19:21:46 <stevemar> topic? what will 1.6.0 include and not include?
19:22:00 <stevemar> its getting to be a massive release....
19:22:14 <dtroyer_zz> this has been talked about, it's writing the guidelines.  someone may have already started, I haven't looked in a month or so
19:22:30 <dtroyer_zz> stevemar: slow down turbo...
19:22:35 <dtroyer_zz> any other reviews first?
19:22:43 <stevemar> dtroyer_zz: :)
19:23:01 <stevemar> the image create one?
19:23:03 <stevemar> for v2
19:23:13 <terrylhowe> I’ve been a bit manic myself lately too
19:23:53 <dtroyer_zz> I've just looked closely at the user-facing parts, not sure why it is so different
19:24:04 <terrylhowe> https://review.openstack.org/#/c/203280/
19:24:16 <dtroyer_zz> a few of the API changes can be covered for, others just get removed
19:24:56 <dtroyer_zz> but why is the option order different?  makes the help text gratuitously different
19:25:18 <stevemar> the ordering can be changed
19:25:24 <stevemar> tags is weird
19:25:25 <dtroyer_zz> I think stevemar convinced me on enumerating the container and disk types
19:25:37 <stevemar> \o/
19:25:37 <dtroyer_zz> yeah, where did that come from?
19:25:46 <dtroyer_zz> it is entirely possible it came from me long ago
19:25:50 <dtroyer_zz> and I just don't recall
19:26:01 <stevemar> possible
19:26:10 <dtroyer_zz> either way it seems odd
19:26:23 <stevemar> naw
19:26:41 <terrylhowe> should be —property?
19:26:48 <dtroyer_zz> first, is 'tag' or 'tags' the right word?  are users expected to know what that is?
19:27:04 <dtroyer_zz> this is like —property but keys only, no values
19:27:05 <stevemar> i think its supposed to be property?
19:27:13 <dtroyer_zz> no, they have both  ;(
19:27:25 <dtroyer_zz> again with the special snowflakes
19:28:03 <dtroyer_zz> I do recall terrylhowe doing a list of strings somewhere that would be a good precedent to follow, but I can't remember which command that was
19:28:05 <terrylhowe> should be be action=append
19:28:24 <terrylhowe> the thing I did dtroyer_zz was an append for dicts I think
19:28:39 <terrylhowe> kind of like —nic on server create
19:28:55 <dtroyer_zz> hmmm… ok.  I do like allowing multiple —tag options (prefer singular too)
19:28:59 <dtroyer_zz> yeah, that's the one
19:29:03 <terrylhowe> it was for subnet create
19:29:32 <terrylhowe> I think —tag with action=append would be better
19:29:48 <dtroyer_zz> agreed
19:30:01 <dtroyer_zz> was it subnet create where it also accepted a comma-separated list?
19:30:17 <terrylhowe> it may have
19:30:37 <dtroyer_zz> that is what I was thinking of…that didn't merge yet did it…
19:31:46 <terrylhowe> it is still out there, going to be a while before that is ready.  all I see in there is that array of dicts ActionAppender
19:32:08 <dtroyer_zz> ok, they were dicts rather than strings?
19:32:15 <terrylhowe> https://review.openstack.org/#/c/84782/10
19:32:40 <terrylhowe> yeh, neutron just needs them, the appender was nice to validate the values
19:33:02 <terrylhowe> I’d like to bring that in someday, it would work for —nic as well in server create
19:33:53 <dtroyer_zz> as much as I don't like the idea of strings of AVPs, I think you're right we need to do it.
19:34:03 * dtroyer_zz still a wee bit grumpy
19:34:27 <dtroyer_zz> anyway, back to —tag
19:34:53 <dtroyer_zz> I like terrylhowe's suggestion of —tag and action-append
19:35:36 <stevemar> next review?
19:35:43 <dtroyer_zz> sure!
19:35:45 <stevemar> https://review.openstack.org/#/c/203185/
19:36:01 <stevemar> i say no to dropping py26
19:36:08 <stevemar> not sure why terrylhowe proposed to remove it
19:36:12 <dtroyer_zz> my gut agrees
19:36:28 <stevemar> as a client lib we should be very flexible
19:36:33 <dtroyer_zz> at least not until one of our dep libs makes it impossible to run there
19:36:57 <stevemar> then we get the TC to bust out the big stick and what the dependency
19:37:02 <stevemar> whack*
19:37:02 <terrylhowe> fair enough, I just like to simplify
19:37:23 <stevemar> sorry mr howe
19:37:28 <dtroyer_zz> who said "as simple as possible, but not too simple?"
19:37:34 <terrylhowe> ouch!
19:37:39 <dhellmann> I'm actually with terrylhowe on this one, but I'm not in a big rush
19:37:58 <dtroyer_zz> dhellmann: is there a schedule for oslo libs to drop it?
19:38:18 <dhellmann> dtroyer_zz: I think when juno falls out of support?
19:38:23 <dhellmann> actually, belay that
19:38:27 <terrylhowe> I kind of like the idea of taking compatibility patches, but just not regularly testing it
19:38:32 <dhellmann> we've talked about doing it for master, now that we have stable branches
19:39:16 <dhellmann> there was an email thread about it not too long ago, but I think no one is motivated to drop them so it hasn't been done yet
19:39:34 <dhellmann> if we don't do it now, it will probably happen early in  mitaka
19:39:45 <stevemar> cool cool
19:39:48 <dtroyer_zz> I still like the idea that clients need to be as compatible as possible
19:40:06 <dtroyer_zz> if it isn't costing us much in coding or tech debt, I'd like to leave it in for now
19:40:06 <dhellmann> yeah, I think the conclusion was that most of the platforms we've been supporting have actually moved on from 2.6
19:40:10 <stevemar> dtroyer_zz: yep
19:40:31 <dhellmann> yeah, I imagine the infra team will be pushing us to drop it when they want to stop supporting 2.6 images in the gate
19:40:48 <dtroyer_zz> I'm certain there is still RHEL6 in the wild, even RHEL5, but I do not know if it is places we should care
19:41:02 <dtroyer_zz> that's a fine time to do it then
19:41:20 <dhellmann> right, we're not actively supporting even running openstack on those platforms much longer, and I think that was the trigger for oslo to drop these jobs
19:41:38 <dtroyer_zz> again, though, clients run in places servers never would...
19:42:19 <dtroyer_zz> can you tell I'm hearing a lot about 'entrprise' these days?  and they're the worst for this kind of thing…
19:42:21 <dhellmann> I don't care enough to argue against you now, but I would be on infra's side when they want to stop having to maintain 2.6 images for CI
19:42:57 <dhellmann> I'm content to let those folks pay someone to maintain compatibility, but don't see the need for the entire project to take on the burden
19:43:01 <dtroyer_zz> sure, that works for me.  unless it;s costing someone a lot in time or resource, though, I'd prefer to keep it
19:43:12 <dhellmann> yeah, I think we're agreeing, for now :-)
19:43:17 <dtroyer_zz> yup
19:43:20 <stevemar> someone who isn't us will probably make a call that will keep or remove the job :P
19:43:45 <dtroyer_zz> other reviews?
19:43:49 <stevemar> the other interesting review is this one: https://review.openstack.org/#/c/186720/4
19:44:04 <stevemar> terry already +2'ed it, and i am +2 once my comments are addressed
19:44:18 <stevemar> if you call, it was one of the few user requests we had in YVR
19:44:32 <dtroyer_zz> right, that's why I rebased it to see where it was at
19:44:54 <stevemar> and the dudes from fujitsu actually did a great job with the feedback we gave them (base it on occ)
19:45:00 <dtroyer_zz> I think it is actually close
19:45:05 <terrylhowe> I like it mostly because some code gets pulled out shell.py
19:45:11 <stevemar> theyre a bit slow with turn around, but i like it
19:45:30 <dtroyer_zz> I don't think we'd hold up a release for it though
19:45:43 <stevemar> guess not
19:45:59 <dtroyer_zz> did we cover volumes already?
19:47:07 <stevemar> there are 3 patches left for volume
19:47:09 <stevemar> the list one
19:47:23 <stevemar> this one: https://review.openstack.org/#/c/204364/ (volume type set and unset)
19:47:38 <stevemar> and this one: https://review.openstack.org/#/c/187480/
19:48:15 <stevemar> all are reviewed with feedback, but it'll be cool to announce full v1 and v2 support for volume in the next release
19:48:52 <terrylhowe> set/unset needs docs
19:49:07 <dtroyer_zz> that would be nice; at this point it looks like you'll be making the release call without me
19:49:17 <terrylhowe> missing ‘volume type show’ I think
19:50:12 <dtroyer_zz> 10 min warning…
19:50:14 <stevemar> terrylhowe: i proposed VT show
19:50:29 <stevemar> dtroyer_zz: when are you gone?
19:50:52 <terrylhowe> ahh, thanks stevemar been so many changes around there lately
19:50:54 <dtroyer_zz> Monday.  this is my last meeting of any kind for maybe a month or so
19:51:42 <dtroyer_zz> #topic open discussion
19:51:56 <stevemar> yowza
19:52:03 <dtroyer_zz> So that was my reminder of me being gone for a while
19:52:13 <stevemar> good luck!
19:52:33 <dtroyer_zz> y'all will be grump-free unless someone asks for my magic stick
19:53:04 <stevemar> dhellmann: you cool if i bug you when we need to release?
19:53:17 <dhellmann> stevemar: yep, did you see the stuff about the new releases repo?
19:53:35 <stevemar> dhellmann: i did not, my knowledge on the release process is very limited :(
19:53:50 <dhellmann> stevemar: ok, ping me when you're ready and I'll walk you through it
19:53:53 <dtroyer_zz> it's actually pretty cool
19:54:08 <stevemar> cool, just gotta find time, i'm slammed next week until friday, so probably then
19:54:15 <dtroyer_zz> also, don't forget cliff and/or o-c-c need rleeases before osc
19:54:19 <stevemar> teaching noobies how to openstack!
19:54:23 <stevemar> yup
19:54:29 <dhellmann> dtroyer_zz: good point
19:54:34 <stevemar> i really want that fuzzy patch in for cliff!
19:54:39 <dhellmann> ++
19:54:39 <stevemar> that one is very cool!
19:54:43 <dtroyer_zz> I haven't tried it, looks good?
19:54:48 <terrylhowe> agreed!
19:54:52 <dhellmann> yep, very nice addition
19:54:55 <stevemar> terrylhowe tried it and he reported back goodness
19:54:57 <dhellmann> stevemar: did you try it in interactive mode?
19:55:09 <stevemar> i tried the old patch, it was fine
19:55:16 <dtroyer_zz> does it let us do cisco-style shortcuts?
19:55:19 <stevemar> i'll give it another whirl
19:55:21 <dtroyer_zz> ie, serv sho
19:55:22 <terrylhowe> I did not try interactive
19:55:37 <stevemar> dtroyer_zz: no, this one finds matches in case you messed up the command
19:55:47 <stevemar> i.e.: # os user foo
19:55:53 <dtroyer_zz> ok, still good, but that's always been a dream of mine...
19:56:04 <stevemar> will report back: did you mean: os user create, os user show ...
19:56:22 <stevemar> dtroyer_zz: https://review.openstack.org/#/c/202053/
19:56:35 <terrylhowe> ser sho <- a lot of matches for that
19:56:41 <terrylhowe> interactive works
19:56:53 <dtroyer_zz> you type as much as required to make it unique
19:56:56 <stevemar> http://paste.openstack.org/show/404590/
19:57:02 <dhellmann> terrylhowe: nice
19:57:04 <dtroyer_zz> the rest is optional
19:57:20 <dtroyer_zz> again, long-term dream feature
19:57:34 <stevemar> this one + the --help option will go a long way
19:58:02 <stevemar> anyway, i'm done for now
19:58:05 <stevemar> good luck dtroyer_zz!
19:58:14 <terrylhowe> yeh, take it easy dtroyer_zz
19:58:19 <dtroyer_zz> ajayaa had a go question, appears to be gone…
19:58:20 <terrylhowe> not too easy though
19:58:36 <dtroyer_zz> thanks.  I'll probably check in as my laptop is always close
19:59:22 <dtroyer_zz> ok, if that's it, we'll call it a day
19:59:27 <stevemar> "A DAY"
19:59:34 <dtroyer_zz> #endmeeting