19:01:02 <dtroyer> #startmeeting OpenStackClient
19:01:03 <openstack> Meeting started Thu Jun  4 19:01:02 2015 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:05 <sigmavirus24> o/
19:01:06 <openstack> The meeting name has been set to 'openstackclient'
19:01:07 <dtroyer> Anyone here?
19:01:16 <sigmavirus24> I don't have anything to talk about, but I'm here
19:01:32 <dhellmann> o/
19:01:54 <dtroyer> ping: stevemar, briancurtin, terrylhowe, lhcheng
19:02:09 <briancurtin> hi
19:02:27 <dtroyer> the agenda is at https://wiki.openstack.org/wiki/Meetings/OpenStackClient#04_Jun_2015
19:02:33 <terrylhowe> o/
19:02:51 <dtroyer> #topic open items
19:03:00 <dtroyer> There were actually some from last week
19:03:23 <dtroyer> the first is the volume v2, which Amey is making great progress on
19:03:53 <dtroyer> not much else to say there
19:04:41 <dtroyer> the second is about https://bugs.launchpad.net/python-openstackclient/+bug/1459519, which IIRC is addressed in cliff by https://review.openstack.org/#/c/186394/
19:04:41 <openstack> Launchpad bug 1459519 in cliff "ERROR: openstack 'ArgumentParser' object has no attribute 'debug'" [Undecided,In progress] - Assigned to Terry Howe (thowe-g)
19:05:04 <dtroyer> that's approved and probably needing a re-kick in gerrit after the restart
19:05:10 <dhellmann> kicked
19:05:20 <dtroyer> thx
19:06:01 <dtroyer> that leaves the osc-plugin to cookiecutter conversion, which I have not started yet
19:06:09 <terrylhowe> that solves the issue and then we get the pbr incompatibilty errror
19:07:34 <dtroyer> terrylhowe: do you know if the lib/dep releases this week will have changed that?
19:08:44 <terrylhowe> maybe I just need to upgrade stevedore and the oslo package
19:09:53 <dtroyer> possibly
19:10:25 <dtroyer> let's see where that falls out, it should probably hit before we actually get the release out so hopefully if it's broken we can still fix it...
19:10:32 <dtroyer> which brings us to
19:10:37 <dtroyer> #topic releases
19:11:12 <dtroyer> We had started the week intending for a quick 1.3.1 release to fix some bugs jamielennox had to support devstack using only identity v3
19:11:35 <dtroyer> that turned into implementing ec2 credentials v3 commands and a couple of other things, so 1.4.0 is next
19:11:46 <dtroyer> as soon as one last fix gets through the gate
19:12:20 <dtroyer> there was also a dependency on updating keystoneclients in global-requirements, which is now merged
19:12:22 * stevemar sneaks in late
19:13:01 <dtroyer> so unless there is something else, I'll do 1.4.0 this afternoon
19:13:22 <stevemar> dtroyer, we need to update osc reqs too
19:13:42 <stevemar> this guy: https://review.openstack.org/#/c/188501/
19:13:53 <dtroyer> oh, right.  both ksc and occ?
19:13:54 <stevemar> rechecking him now
19:14:03 <stevemar> oh right occ too
19:14:20 <stevemar> that pesky bot doesn't update often enough :)
19:15:00 <stevemar> the bot didn't propose an update to occ, curiously enough
19:15:02 <dtroyer> if there isn't a depends-on in the commit message, don't recheck yet until 188417 is merged
19:15:18 <stevemar> oh, partly because the occ is just merging now.....
19:15:30 <dtroyer> the cliff re-kick dhellmann just did failed on the osc job, likely because of that
19:16:02 <dtroyer> sigh, this must be what living inside a JSON serializer is like
19:16:10 <terrylhowe> :)
19:16:19 <stevemar> can we chat about the osc-plugin cookie cutter?
19:16:28 <stevemar> if you're done with this topic
19:16:34 <dtroyer> if we're done with the release, sure.  I'm done
19:17:04 <dtroyer> stevemar: go for it
19:17:30 <stevemar> just wondering if we want another repo for this stuff, and what exactly will go in it
19:17:35 <stevemar> osc-plugin or osc-base
19:17:52 <stevemar> something the other plugin based CLIs can import, with not much bloat
19:18:14 <dtroyer> that's what the cookiecutter is for, do you mean a working plugin repo?
19:18:20 <stevemar> so they can get the utils (key-value parser, finding domain stuff, test things...)
19:18:28 <dtroyer> oh, right
19:18:46 <dhellmann> so maybe split those things out of osc and make a new lib that can be used by osc and the plugins?
19:19:00 <stevemar> a lot of them have just been copying and pasting the entire file over, or req'ing on OSC (way too big)
19:19:08 <stevemar> yes dhellmann, that's what i meant :)
19:19:18 <dhellmann> ew, no, we don't want either of those approaches -- yeah, let's figure out what should go into a lib
19:19:21 <dtroyer> I'm still not convinced that another repo/package is the right thing to do there, is doing some sort of conditional import an option?
19:19:34 <stevemar> conditional imports are dirty
19:19:45 <dtroyer> if not osc-lib (or similar) is a good second for me
19:19:49 <stevemar> a small shared lib wouldn't hurt
19:20:02 <stevemar> imo anyway
19:20:05 <dhellmann> if we don't want a new repo, we need to consider part of osc a lib and lock down its api with good tests so we can tell plugin authors its safe to import it
19:20:27 <stevemar> bah, no we did that in ksc and it's uggo
19:20:33 <dhellmann> I can see pros/cons to both approaches
19:20:38 <dtroyer> dhellmann: I hope to do that with some parts anyway, but we don't want OSc in a requirements.txt anywhere to do that
19:20:58 <dhellmann> but, yeah, being explicit about the lib contents by putting them into a lib is my preference
19:21:17 <dhellmann> dtroyer: how will plugins indicate which versions of osc they work with?
19:21:29 <dhellmann> or vice versa
19:21:59 <dtroyer> the plugin interface is unversioned atm, so that should probably happen
19:22:05 <dhellmann> ++
19:22:15 <stevemar> silly q, why would versioning be an issue, arent they just entry points?
19:22:47 <dtroyer> yes, but there still are requirements on what needs to be implemented behind those entrypoints
19:23:28 <stevemar> dtroyer, i'll have some time next week to fiddle around with osc-lib (or whatever we call it)
19:23:40 <dtroyer> so it sounds like we're all close enough to go in the osc-lib direction
19:23:45 <stevemar> expect an etherpad, and i might move things in osc proper around
19:24:06 <stevemar> i think it'll really help the folks who are doing osc plugin based CLIs
19:24:21 <dtroyer> stevemar: sounds good.  I'm actually taking time off starting next Thursday and all of the following week
19:24:24 <stevemar> i dont want to put too many requirements in there at all
19:24:31 <stevemar> pfft, slacker
19:24:41 <stevemar> i'll be at cloud identity summit next week
19:24:56 <stevemar> so far i'll know no one there, yippie, lots of hacking time
19:25:10 <dtroyer> that's what bar-time is for
19:25:42 <stevemar> thats all i really wanted to talk about
19:25:50 <stevemar> and amey is kicking ass with cinder commands
19:26:05 <terrylhowe> yeh, I can hardly keep up
19:26:25 <dtroyer> #agreed stevemar will start investigating and prototyping osc-lib for use by external plugins
19:26:26 <stevemar> terrylhowe, you get an honorable mention for functional tests too :)
19:27:10 <stevemar> i'm also pumped to see if jamie can pull off a v3 only devstack
19:27:41 <dtroyer> that'll be interesting…
19:28:19 <dtroyer> looks like https://review.openstack.org/#/c/188417/ just merged, so other osc jobs should pass again
19:28:32 <stevemar> we should probably do a bug sweep, and an old review sweep
19:28:40 <stevemar> i'll do those soonish
19:28:48 <stevemar> i might ask for 2nd opinions
19:29:00 <dtroyer> that's a good idea
19:29:05 <dtroyer> blueprints too
19:29:10 <dtroyer> speaking of which,
19:29:13 <dtroyer> #blueprints
19:29:44 <dtroyer> the only one I just remembered that we should mention is https://blueprints.launchpad.net/python-openstackclient/+spec/every-time-record-log-in-file
19:30:01 <stevemar> right
19:30:04 <stevemar> they have code too
19:30:23 <stevemar> and adjusted their bp to meet our vague handwavey reqs
19:30:25 <stevemar> i like that
19:30:50 <dtroyer> I havent looked closely yet, so that's good to hear
19:31:07 <stevemar> yeah the bp was updated based on summit feedback
19:31:12 <stevemar> and the code looks decent too
19:31:17 <stevemar> its still marked in WIP i think?
19:31:37 <stevemar> yes, it is: https://review.openstack.org/#/c/186720/
19:32:36 <terrylhowe> looks like a good start
19:34:26 <stevemar> anyone want to take a look at that? even if it's WIP?
19:35:02 <dtroyer> that's good to hear.  I was a bit worried about what they wanted until we talked to them in YVR
19:35:29 <dtroyer> I don't think I'll have time to look before I go
19:35:41 <terrylhowe> it needs a lot of work still
19:36:03 <stevemar> work is okay :P
19:36:20 <dtroyer> getting them the right feedback early would be helpful
19:36:49 <dtroyer> any other blueprints?
19:37:13 <stevemar> not blueprints, but one more issue
19:37:24 <stevemar> we had this come up on the mailing list: http://lists.openstack.org/pipermail/openstack-dev/2015-June/065470.html
19:37:54 <stevemar> and it looks like they took my suggestion to heart, now we have https://review.openstack.org/#/c/188285/
19:38:13 <stevemar> sigmavirus24, maybe you know more about this stuff?
19:38:21 <dtroyer> I don't know how I feel about —or-update
19:38:27 <sigmavirus24> oh?
19:38:40 <stevemar> sigmavirus24, http://lists.openstack.org/pipermail/openstack-dev/2015-June/065470.html
19:38:55 <stevemar> does glanceclient allow for many images with the same name?
19:39:00 <sigmavirus24> Yes it does
19:39:01 <dtroyer> the fill-in-a-reservation-slot was intentional, the it also-replaces-existing-images I don't think was, on my part at least
19:39:15 <sigmavirus24> Names are not unique
19:39:30 <dtroyer> so to clarify, is he talking about replacing an image not creating a new one, ie the same UUID?
19:39:58 <sigmavirus24> Pretty sure they were talking only about name
19:40:02 <dtroyer> because I'm not sure we should want that
19:40:13 <sigmavirus24> "if image with *name* specified for create already existed"
19:40:25 <terrylhowe> create should create.  not update
19:40:32 <sigmavirus24> == terrylhowe
19:40:36 <dtroyer> yes
19:40:40 <sigmavirus24> unless the service has non-unique names
19:40:47 <sigmavirus24> er
19:40:52 <sigmavirus24> unless the service has unique names
19:40:53 <sigmavirus24> sorry
19:40:59 <sigmavirus24> brain gas
19:41:30 <stevemar> in osc (for image create only), we (for some reason) check to see if the image name already exists, and if does, then we do an update
19:41:37 <stevemar> i don't like that ^
19:41:54 <dtroyer> so I think I need to actually play wiht this to make sure I understand what is going on.  either way, I don't hear support for an —or-update option
19:42:15 <stevemar> i think we'll have to break the existing behaviour
19:42:17 <dtroyer> that's to support the reservation thingy, but checking on name is probably wrong
19:42:22 <stevemar> and let create do just that
19:44:18 <dtroyer> so I hear this: create should only create new images (UUIDs), modulo the reserved image behaviour, which is not what I think this is about
19:46:11 <stevemar> i think so
19:46:52 <dtroyer> #info the desired behaviour of 'image create' in re https://review.openstack.org/#/c/188285/ is to create new images and allow duplicate names
19:47:49 <dtroyer> ok, moving on
19:47:54 <dtroyer> #topic bugs
19:47:56 <stevemar> gah, i can't believe it's done that way :(
19:48:28 <dtroyer> I don't know how many times I've said that about glance stuffs
19:48:42 <dtroyer> any other bugs to discuss here?
19:48:51 <stevemar> ¯\_(ツ)_/¯
19:48:56 <sigmavirus24> "you're welcome"?
19:48:58 <stevemar> none else from me
19:49:13 <terrylhowe> nothing here
19:50:04 <dtroyer> ok...
19:50:07 <dtroyer> #open discussion
19:50:10 <terrylhowe> I wanted to ask about a OSC “config show” command
19:50:18 <dtroyer> what else is on our colective minds?
19:50:23 <terrylhowe> was there a review on that or did I dream that?
19:50:43 <terrylhowe> Was there something in OCC to support printing the configuration maybe?
19:51:03 <dtroyer> you may be dreaming about my osc-debug plugin that does all sorts of stuff, including dumping out auth and other info
19:51:14 <terrylhowe> this would be convenient for testing OCC, env and cli opts
19:51:23 <terrylhowe> functionally
19:51:26 <dtroyer> some of which should either get intot he main repo or an official debug-like plugin
19:51:41 <dtroyer> yup, that's why I wrote it ;)
19:51:57 <terrylhowe> maybe that is what I was looking at
19:52:28 <dtroyer> some of it though is also the kind of stuff that might be too much rope for some users, one reason I was hesitant to put it in the main repo
19:52:41 <dtroyer> exposing passwords and whatnot
19:52:46 <terrylhowe> that’s all.  I’ll just look at that some more.
19:53:45 <dtroyer> be aware that if you load osc-debug, it'll really slow down your startup times.  I don't leave it install all the time
19:54:05 <dtroyer> I haven't looked at why it is so bad yet
19:54:21 <dtroyer> anything else?
19:55:03 <dtroyer> we have a whole five minutes to recover if not
19:55:31 <terrylhowe> nothing
19:55:49 <dtroyer> ok, thanks everyone!
19:55:56 <dtroyer> #endmeeting