18:02:18 <dtroyer> #startmeeting OpenStackClient
18:02:19 <openstack> Meeting started Thu Mar 12 18:02:18 2015 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:23 <openstack> The meeting name has been set to 'openstackclient'
18:02:30 <dtroyer> who is here today?
18:03:06 <briancurtin> I'm in another meeting but keeping an eye out here (I'm mostly an observer at the moment anyway)
18:04:02 <dtroyer> briancurtin: at this rate it'll be an easy meeting to multitask
18:04:11 <stevemar> o/
18:04:24 <stevemar> dtroyer, present
18:04:36 <stevemar> looks like we didn't break anything this release
18:04:36 <stevemar> yay
18:05:12 <dtroyer> stevemar: that means we didn't try hard enough…  1.1.0 is yet to come  ;)
18:05:21 <stevemar> https://wiki.openstack.org/wiki/Meetings/OpenStackClient
18:05:36 <stevemar> dtroyer, any word on project proposal status?
18:05:41 <dtroyer> well, it's light today anyway
18:05:48 <dtroyer> ok, for the record
18:05:53 <dtroyer> #topic project proposal
18:06:13 <dtroyer> The TC is still stewing over just what and when they will do anything.
18:06:19 <stevemar> dst times were screwing me up
18:06:58 <dtroyer> there are at least 4 project proposals, from a summary that jogo put together, ours seems to be the easiest but I don't think anything will happen for a while.
18:07:21 <dtroyer> it's been almost three years, another <time-units> doesn't make much difference
18:07:50 <dtroyer> anyway, that was the only open action from last meeting
18:08:05 <stevemar> the proposal looks solid
18:08:36 <stevemar> apparently i can't even +1 it
18:09:10 <dtroyer> nope, TC-only, although you can leave a comment, and are encouraged to do so.  applies to everyone, not just our team
18:09:35 <stevemar> #action everyone leave a comment here: https://review.openstack.org/#/c/161885/
18:09:56 <dtroyer> #topic release plans
18:10:52 <dtroyer> aside from whatever bugs we collect before then, I'd like to get a pencil list of the things we want in the next release.  Plans are for it to be 1.1.0 and have some new bits to show off
18:11:35 <dtroyer> also, note that proposals regarding libraries and versioning around integrated releases would have us doing a 1.1.0 rev soon anyway, should we decide to follow that process.
18:12:07 <stevemar> aside from os-client-config is there anything else you think is worth showing off?
18:12:28 <stevemar> other items are cache, and ... neutron support / cinder v2 support
18:12:37 <dtroyer> that's the big one for me, the other user-visible one is getting some caching in place
18:13:01 <dtroyer> cinder v2 is important, I don't know how long that will take, and who is going to do it
18:13:59 <stevemar> dtroyer, i could try to do it between kilo release and summit
18:14:19 <stevemar> provided i'm not crazy busy with $dayjob
18:14:19 <dtroyer> As far as neutron, one thing I want to do sooner that later is work out what stuff overlaps with nova-net and get the commands designed to be able to use either one transparently
18:14:42 <stevemar> with that one, i have no neutron knowledge
18:14:48 <dtroyer> I did a poc, and IIRc we already have something that dies the service catalog check
18:14:49 <stevemar> or nova-net
18:15:29 <dtroyer> I was also hoping to not need to bring in neutronclient, but I don't see that possible with the time I have available
18:15:45 <jogo> dtroyer: you need to make sure no one objects to you being PTL
18:16:07 <jogo> dtroyer: just a formality though
18:16:24 <stevemar> jogo, we say that in the review?
18:16:47 <dtroyer> jogo: sure…I'll let anyone else who wants the job say so…
18:17:00 <stevemar> not it
18:17:37 <jogo> stevemar:  The leadership is chosen by the contributors to the project
18:17:41 <jogo> http://governance.openstack.org/reference/new-projects-requirements.html
18:18:05 <jogo> doesn't have to be a formal election or anything
18:18:23 <jogo> IMHO something in the weekly meeting notes is enough
18:18:38 <dtroyer> we do have a quorum of cores today…  ;)
18:18:41 <stevemar> jogo, that comment was a joke :)
18:18:43 <stevemar> ha
18:18:58 <stevemar> dtroyer, start a vote and get it over with?
18:19:20 <jogo> stevemar: well the real question is anyone else want the gig?
18:19:25 <jogo> if not, by default ...
18:19:26 <stevemar> nope
18:19:27 <dtroyer> well, cores != contributors.  I suppose we should make a list following the usual guidelines and go from there
18:19:42 <dtroyer> so let's start with that
18:20:10 <dtroyer> #action anyone wanting to run for OSC PTL please send an email to the -dev ML before the next meeting
18:20:31 <dtroyer> at that point we can decide how to proceed, election if more than one
18:21:06 <dtroyer> #action dtroyer to get an OSC contributor list per the usual OpenStack voting guidelines
18:22:11 <dtroyer> ok, let's skip straight to…
18:22:14 <stevemar> dtroyer, just do (git log --format='%aN' | sort -u)
18:22:18 <dtroyer> #topic open discussion
18:22:56 <dtroyer> stevemar: that needs a date filter in it, one ywar, but I need to sort out the cutoff date
18:23:30 <dtroyer> IIRc we're at around 62 overall
18:23:46 <dtroyer> moulo a couple of multiple-email folk
18:24:11 <stevemar> true
18:24:19 <stevemar> lemme look at the bugs
18:24:43 <stevemar> oh ... thoughts on this one https://bugs.launchpad.net/python-openstackclient/+bug/1429330 ?
18:24:45 <openstack> Launchpad bug 1429330 in python-openstackclient "Upload of mapping rules does not honor JSON format" [Undecided,New]
18:25:52 <stevemar> i just closed https://bugs.launchpad.net/python-openstackclient/+bug/1424520 in favor of https://blueprints.launchpad.net/python-openstackclient/+spec/neutron-client
18:25:53 <openstack> Launchpad bug 1424520 in python-openstackclient "Openstackclient needs more neutron functionality" [Undecided,Invalid] - Assigned to Satyanarayana Patibandla (satya-patibandla)
18:26:18 <dtroyer> at some level it would be nice to take our output and be able to feed it right back in.  I don't know if OSC generated that kind of output (the data, not json)
18:27:02 <stevemar> that sounds gnarly
18:27:57 <stevemar> dtroyer, two other things 1) renaming the project to just openstackclient (jamie opened a bug for this)
18:28:00 <dtroyer> I do not think that accepting random curl-derived JSON is our responsibility though
18:28:11 <dtroyer> ah, the renaming…
18:28:29 <dtroyer> I agree with him, but am not sure how/when we should do that.
18:28:43 <stevemar> dtroyer, i thought so, and i am happy with the current impl of the mapping rules... but wanted a fundamental statement for that
18:28:45 <dtroyer> I've started creating my plugin repos with osc-* names
18:29:06 <stevemar> we don't accept {user:{name:x, id:y}} in general
18:29:15 <stevemar> that leads me to another point
18:29:19 <stevemar> bknudson, brought it up
18:29:49 <stevemar> what do you think of having osc-keystone, osc-nova, osc-glance, etc projects?
18:30:08 <dtroyer> splitting the existing client bits out?
18:30:16 <dtroyer> first off, it's be osc-identity, etc
18:30:20 <stevemar> splitting the exisitng CLI bits
18:30:22 <bknudson> I suggested put it in python-kyestoneclient
18:30:26 <bknudson> keystoneclient
18:30:38 <stevemar> gosh no
18:30:41 <dtroyer> but I'm not sure I want to split everything out, that compounds the dependency management stuff.
18:30:52 <stevemar> let that be a python lib
18:31:06 <bknudson> dtroyer: you wouldn't have to worry about it anymore, it's keystone's problem.
18:31:41 <bknudson> or do you want to make it easy to switch to sdk?
18:31:55 <dtroyer> bknudson: I worry too much already about things changing out from under us.  one of the reasons we have a consistent comamnd set is that one group controls how they look, that's what the 'C' in OSC stands for (so he says when convenient)
18:32:17 <dtroyer> switching to sdk is/was a long-term goal
18:32:27 <dtroyer> I don't have a timeline for that
18:33:03 <stevemar> dtroyer, i was thinking just having the CLI bits in different repos, and we can import them, they would each be plugins
18:33:10 <dtroyer> I really want to keep the 'layer 1/2' service CLIs in OSC directly.  everything else we can argue about; my default will be separate
18:33:15 <bknudson> seems like the openstack project in general needs to figure out how to split up work and have it still be consistent.
18:33:16 * stevemar feels like he didn't explain it well enough the first time
18:33:43 <dtroyer> bknudson: and how has that worked for us so far?  ;)
18:34:38 <dtroyer> stevemar: I think I know what you meant.  for the basic services, I don't want users to have to manage any more dependencies than necessary.  If we develop and release them in lock-step, what is the benefit of a split?
18:34:41 <bknudson> dtroyer: it's consistently inconsistent.
18:36:02 <dtroyer> for example, we already have a huge discrepency with the congress plugin.  they prefixed _every_ command with 'congress'.  it's the only one I know of to do that, against my advice.  so…
18:36:29 <stevemar> blah
18:36:32 <stevemar> thats silly
18:36:56 <stevemar> dtroyer, its usage is: `openstack congress <resource> <action>` ?
18:37:05 <dtroyer> yes
18:37:09 <stevemar> wth
18:37:21 <dtroyer> it's a natural reaction to having to think globally.
18:37:34 <stevemar> this was one of the reasons i thought separate repos was a good idea
18:37:40 <stevemar> we could share core-ness like oslo does
18:38:09 <bknudson> or have a rule that dtroyer or stevemar has to +2 every change.
18:38:15 <dtroyer> I don't see how pulling out compute and friends keeps us from doing that with higher layer projects
18:38:18 <bknudson> you're essentially the gatekeepers now.
18:38:56 <stevemar> well for compute, identity we could keep in osc, with all layer 1/2 guys
18:39:09 <stevemar> (this is all shooting from the hip)
18:39:20 <bknudson> it might make it easier for developers to find their changes... (e.g., I'd subscribe to osc-identity)
18:39:34 <stevemar> i was hoping to spread the work load so i'm not re-implementing cinder v2 and swift and ... and ...
18:40:08 <dtroyer> so is the current small core them the real bottleneck?
18:40:21 <stevemar> dtroyer, i dunno, theres a hangup with adoption
18:40:27 <dtroyer> I'd love to add to that, but you have to have known and active people to do that
18:40:38 <stevemar> we gotta figure out why folks aren't buying what we're selling
18:40:47 <bknudson> it is disappointing to see keystone the only ones who seem to be interested in deprecating the cli
18:40:58 <bknudson> other groups seem to be loving their clis.
18:40:59 <dtroyer> neutron is too
18:41:10 <bknudson> ah, great.
18:41:11 <dtroyer> swift is too, but in a different manner
18:41:12 <stevemar> i don't want osc to become `just use it for keystone v3` and just nova/glance/etc cli for everything else
18:41:26 <dtroyer> they both don't want to keep maintaining their currelt clis much longer
18:41:56 <notmyname> for swift, that's been more of an aspiration thing that clearly hasn't resulted in any actual coding
18:41:59 <notmyname> IMO
18:42:05 <bknudson> maybe once a couple of groups do it users will start wondering why they're doing nova for some things and openstack for the rest.
18:42:24 <dtroyer> notmyname: that still puts you ahead of most of the other projects
18:42:36 <stevemar> notmyname, is there anything thats preventing y'all?
18:42:41 <bknudson> (because now they're wondering why they're doing openstack for some things and not keystone)
18:42:48 <notmyname> stevemar: prioritization and motivation, mostly
18:43:28 <stevemar> notmyname, we can't help the prioritization part, that will come from tc/user feedback, but we can help with the motivation part?
18:43:40 <stevemar> i need something more tangible :)
18:44:03 <stevemar> that should read "but can we help with ... ?"
18:44:05 <dtroyer> stevemar: sadly, you might be the only one doing this as a normal part of $DAY_JOB.
18:44:22 <dtroyer> it's <20% for me overall
18:44:27 <stevemar> dtroyer, s/sadly/likely
18:44:37 <notmyname> stevemar: no, it's mostly that python-swiftclient does mostly work and our respective employers want us working on EC, encryption, performance (in swift), bugs, etc, etc
18:44:53 <bknudson> stevemar: btw - this is exactly the kind of thing deployers are asking for... more consistency.
18:45:12 <dtroyer> and there lies a bit part of the issue.  people writing checks don't see anything client-side outside of horizon (and competitors) wothwhile
18:45:15 <stevemar> bknudson, i know they are, our (openstacks) UX stinks
18:47:25 <stevemar> anyway, food for thought i guess
18:47:33 <stevemar> we're not going to reach a conclusion here :)
18:47:40 <dtroyer> what????
18:47:49 <dtroyer> Resolution Now!
18:48:00 <dtroyer> oh, wait, that's 'Serenity Now!'
18:48:32 <dtroyer> fwiw, I do see the value in other optional plugins, such as the osc-debug I've been playing with
18:49:39 <stevemar> dtroyer, i think thats all i have
18:49:48 <dtroyer> whether they are part of a project lib or stand-alone, it's a good idea.  I'm just not sure about moving out any of the current project plugins.  Think of ways to convince me and we'll have some $COLD_BEVERAGE in Vancouver
18:50:37 <dtroyer> one more thing, since it's a current review: https://review.openstack.org/161302
18:50:39 <stevemar> rethinking it now, and if we did go that route then i'd prefer our current guys stay put
18:50:54 <dtroyer> do you have an opinion on using —remite-id-file or just —file or what should that look like?
18:51:04 <stevemar> i haven't reviewed yet because the server side pieces aren't in place yet
18:51:22 <dtroyer> ah, ok.  then I don't feel so bad about dragging my feet on it
18:51:29 <stevemar> nah don't
18:51:42 <stevemar> oh in the case that there are so many remote-ids that we need a file
18:52:09 <stevemar> should --remote-id be --remote-id x --remote-id y
18:52:20 <stevemar> (looking at the doc it says comma separated)
18:52:24 <dtroyer> I suggested that, that's when the 'there's so many' bit came up
18:52:46 <stevemar> screw that, copy and paste
18:52:57 <stevemar> we don't do comma separated anywhere
18:53:08 <dtroyer> I prefer the multiple option, but for just values (as poopsed to attr=value pairs) a list os palatable, but not quite consisent
18:53:33 <dtroyer> I think we do, there's a couple on the neutron proposals
18:53:37 <stevemar> i don't like --remote-id-file, doesn't seem riht
18:53:47 <stevemar> so we don't *yet* :D
18:54:03 <stevemar> the other identity commands are all repeaters
18:54:10 <stevemar> and we are giving a file option
18:54:12 <dtroyer> I can;t say for sure, I haven't exhaustively looked since this came up
18:54:12 <stevemar> so...
18:54:17 <stevemar> if it's that many, use a file
18:55:00 <dtroyer> ok.  we need a argparse action for list, that's easy to do, but I don't think Marco wants to do it
18:55:13 <stevemar> i'll do it
18:55:32 <stevemar> for the file, i'm okay with just --file tbh
18:55:41 <stevemar> --remote-id-file sounds weird
18:55:45 <dtroyer> that's what we used in image create
18:56:01 <dtroyer> but that was to pull the named resource, not an option atribute
18:56:07 <dtroyer> but I can live with it
18:56:12 <stevemar> i suppose
18:56:20 <stevemar> fine fine
18:56:41 <dtroyer> wow, we managed to fill up an hour anyway…
18:57:32 <dtroyer> ok, thanks
18:57:47 <dtroyer> #endmeeting