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