19:01:10 <dtroyer> #startmeeting OpenStackClient
19:01:11 <openstack> Meeting started Thu Mar 19 19:01:10 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:12 <terrylhowe> o/
19:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:14 <openstack> The meeting name has been set to 'openstackclient'
19:01:24 <lhcheng> o/
19:01:28 <terrylhowe> o/
19:01:34 <stevemar> agenda is here: https://wiki.openstack.org/wiki/Meetings/OpenStackClient
19:01:43 <stevemar> ping dtroyer, dhellmann, stevemar, briancurtin, terrylhowe, lhcheng for meeting
19:02:00 <briancurtin> hey
19:02:10 <dtroyer> stevemar: is faster on the copy-n-paste than me today
19:02:28 <dtroyer> #topic open actions
19:02:32 <stevemar> i have some l33t shortcut skillz
19:02:51 <dtroyer> I had the only open action, around an election for PTL.
19:03:25 <dtroyer> I think Tuesday's approval of our status as an official OpenStack project moots that; I've confirmed that we will be included in the next PTL election cycle
19:03:55 <stevemar> is that open to all contributors or just cores? if the latter we have quorum now :)
19:04:25 <stevemar> dont we need an interim ptl? when is the election?
19:04:31 <dtroyer> :)  the election is all ATCs within the last year
19:05:17 <dtroyer> we decided last week to seek additional PTL candidates, nobody has stepped forward by the TC meeting so I left my as provisional PTL
19:05:28 <dtroyer> we'll do a normal cycle in April
19:05:36 <stevemar> makes sense
19:06:43 <dtroyer> #topic public test interfaces
19:07:18 <stevemar> oh this is new... whats up here?
19:07:19 <dtroyer> d0gual asked about this in -sdks, we haven't talked about it, or what exactly are the public interfaces for plugins in general
19:07:46 <dtroyer> but I wanted to start some thinking and discussion around that so we can document somthing there
19:08:05 <dtroyer> specifically he asked about openstackclient.tests.fakes
19:08:27 * stevemar looks that up
19:08:38 <dtroyer> that seems like a good place to have public bits since we basically treat it that way in our own tests
19:09:14 <dtroyer> my first thought is that if that breaks it is due to internal OSC changes and a plugin would need to know
19:09:44 <stevemar> i'm confused as to what the end goal is?
19:10:00 <dtroyer> what can a plugin use from OSC's fakes in its own tests?
19:10:22 <stevemar> ah okay... what do we claim/hope won't change from fakes
19:10:27 <terrylhowe> if the plugins are developing off a tag, it shouldn’t be aproblem
19:10:43 <dhellmann> o/
19:11:13 <dtroyer> terrylhowe: right, until its time to move to the next tag.  It's basically asking where we'll (try to) keep some compatibility inernally
19:12:32 <dhellmann> dtroyer: for test fixtures in oslo we put them in foo/fixtures instead of foo/tests as a way of indicating what is public and what is private
19:12:59 <dhellmann> it helps consumers, but it also helps reviewers know when changes might need closer scrutiny for backwards-compatibility
19:13:09 <dtroyer> dhellmann: mmm…that sounds like a good plan
19:13:57 <stevemar> sounds reasonable
19:14:10 <dhellmann> actually, we don't use the "s" so it's just "fixture"
19:14:16 <stevemar> create a bp for the work?
19:14:41 <dtroyer> stevemar: I think so
19:15:14 <stevemar> #action create a bp for moving fakes to fixtures for plugins to consumer
19:15:15 <dtroyer> I feel like I need to get a bit smarter around tests and structuring things like this.  I'm guessing oslo would be a good pattern to match?
19:16:03 <stevemar> probably
19:16:14 <dhellmann> dtroyer: we're not 100% consistent, but we're getting better
19:16:49 <dhellmann> dtroyer: https://review.openstack.org/#/c/158787/ is related
19:17:02 <dhellmann> (that's a spec describing why we're moving to just using fixtures, and not test base classes)
19:17:26 <dtroyer> cool, will read in a bit, thanks
19:18:41 <stevemar> in keystone we need to start using fixtures instead of overloading test setups and base classes
19:18:58 <stevemar> so don't look there for good practices/examples :\
19:19:11 <dtroyer> ok, we'll get a bp started, this likely will be something to talk about in Vancouver
19:19:24 <stevemar> sounds good, next topic time?
19:19:33 <dtroyer> #topic bug reviews
19:19:44 <dtroyer> I had a couple of questions for the group...
19:19:56 <dtroyer> https://bugs.launchpad.net/python-openstackclient/+bug/1429330
19:19:57 <openstack> Launchpad bug 1429330 in python-openstackclient "Upload of mapping rules does not honor JSON format" [Undecided,New]
19:20:21 <dtroyer> is this a bug, or how do we want to address it?
19:20:35 <stevemar> that one...
19:20:39 <dtroyer> I feel like something like that should work, but I'm not sure exactly how.
19:21:09 <stevemar> if we do address it, we'll need a way to pass in the entire request body via a file
19:21:25 <stevemar> and we'd have to do that to all commands
19:21:32 <dtroyer> yeah, I think it generalizes to handling JSON input
19:21:56 <stevemar> so that comes down to, do we think that's a valid input method?
19:22:44 <stevemar> in cases where the request body is huge, and the command line is super long, then maybe it makes sense?
19:22:49 <dhellmann> was the problem that the contents of the input file were wrong?
19:23:28 <dtroyer> AIUI, the output was wrapped at a different level than the input required
19:23:38 <dtroyer> I don't mean to solve it now, just to decide where to file it… another bp?
19:24:01 <dhellmann> one of the example files that works with raw curl didn't work with the client because of that?
19:24:16 <dhellmann> I guess I'm saying I think it's already working? Maybe I'm misunderstanding.
19:25:07 <dtroyer> the input JSON didn't need the two outer layers of 'mapping' and 'rules'
19:25:08 <stevemar> yeah, it worked for curl... the entire post body was in the file
19:25:29 <dhellmann> right, but I wouldn't expect the user-friendly client to need to have the raw request body, just the data
19:25:51 <dhellmann> I guess we could look at what we're given and unpack part of it if we see that it's wrapped too many levels like that
19:25:56 <stevemar> dtroyer, we only have the rules input via the file, because it's hard to specify them otherwise.
19:26:48 <dtroyer> The general solution I was thinking was to be able to take JSON that we output with —format json and be able to use it as input where it makes sense, mapping create is one of those places.
19:27:00 <dhellmann> that makes sense
19:27:04 <dtroyer> this specific case isn't exactly that, just got me to thinking about it
19:27:17 <dtroyer> so maybe a generalized bp and close this?
19:27:21 <dhellmann> ok, I agree we should be able to take our output as input
19:28:20 <dtroyer> #action dtroyer create a bp to generalize taking JSON input based on our own JSON output
19:28:56 <dtroyer> the second one I had on my list stevemar jumped the gun with in -sdks a little bit ago
19:28:59 <dtroyer> https://bugs.launchpad.net/python-openstackclient/+bug/1406470
19:29:00 <openstack> Launchpad bug 1406470 in python-openstackclient "track backwards incompatible changes" [High,Confirmed]
19:29:27 <stevemar> getting the args out of the request input file is gonna be a pain
19:29:44 <stevemar> anyway, we can go on to the next issue
19:30:04 <dtroyer> I think handling this via commit message tags might work as that is where we will be talking about an incompatibile change anyway
19:30:25 <stevemar> ++ agreed
19:31:35 <dhellmann> do we want to track them just for release notes? or to make sure we come back later and remove the obsoleted thing?
19:31:54 <stevemar> the latter
19:32:29 <dhellmann> ok. We have versionutis and debtcollector in oslo that might also be useful for those things
19:33:30 <dtroyer> I need to catch up with debtcollector, will have a look
19:33:45 <stevemar> hmm, maybe versionutils will work, i initially dismissed it since it uses the release names (juno/kilo, etc)
19:33:54 <stevemar> but i think we're aiming for that anyway
19:34:04 <dhellmann> debtcollector is focused on developer internal APIs, while versionutils is focused on user-facing features
19:34:38 <dhellmann> so versionutils might be better in this situation, but yeah if we're not using the release cycle as a unit of time for deprecation then that might not make sense either
19:34:44 <dhellmann> anyway, worth a look
19:34:54 <dtroyer> if we're going to define internal interfaces we'll need debtcollector-like functionality
19:35:22 <stevemar> dhellmann, is versionutils in it's own repo yet?
19:35:32 <dtroyer> I didn't think we were going to anything more WRT integrated release cycles than stick to the lib versioning around that
19:36:36 <dhellmann> stevemar: not yet. finding a home for that is tricky because of the dependencies
19:36:55 <dhellmann> dtroyer: that was my understanding
19:37:51 <dtroyer> ok, I think we have some direction there
19:37:54 <stevemar> booo, i don't want to sync back up with incubator, we were officially free of it!
19:38:09 <dhellmann> stevemar: it's on my list to sort out for liberty
19:38:22 <stevemar> i'll try to help :)
19:38:48 <dhellmann> ++
19:39:01 <dtroyer> anyone else have any bugs that need attention?
19:39:13 <stevemar> let me check
19:39:44 <stevemar> oh, want to chat about the `osc is slow` bug? bug 1431649
19:39:46 <openstack> bug 1431649 in python-keystoneclient "openstackclient is really slow" [Undecided,In progress] https://launchpad.net/bugs/1431649 - Assigned to Robert Collins (lifeless)
19:40:06 <stevemar> i have no idea how to fix this one :\
19:40:30 <dtroyer> sure.  I played with that earlier in the week, both fixing the —timing operation, but then hacking up some internal timing
19:40:47 <dtroyer> https://review.openstack.org/164091 is the —timing fix
19:41:00 <stevemar> did you find out where the slowness is worst?
19:41:07 <dtroyer> https://review.openstack.org/165181 is my poor-man's profiler
19:41:38 <dtroyer> loading keystoneclient.session is by far the slowest
19:41:48 <dtroyer> I didn't look inside that at all
19:42:16 <stevemar> dtroyer, does running keystone CLI commands use session?
19:42:29 <dtroyer> I had a couple of external plugins that were also hideously slow compared to the built-in clinets (compute, etc), not sure why, but have removed them for now
19:42:37 <stevemar> cause that is still a big zippier than their OSC counter part
19:42:41 <dtroyer> stevemar: no idea
19:42:47 <dtroyer> probably not then
19:43:19 <dtroyer> other than the actual REAT round trips, loading the actual command class what the only other peak I saw
19:44:42 <dtroyer> I need to update the bug with what I found, but I'm not sure what is actionable there
19:45:08 <dhellmann> it would be interesting to know if we're importing code that isn't being used, but I suspect not
19:45:59 <dtroyer> dhellmann: I think between cliff/stvedore and the ClientManager descriptor magic I don't think there is much else within our repo
19:46:12 <dtroyer> that loads unnecessarily
19:46:47 <dhellmann> yeah, I meant in some of those plugins
19:46:57 <dtroyer> I suspected the plugin discovery bits but that turns out to be not too bad pulling the plugin entrypoint list
19:47:50 * dhellmann can't remember if the plugin manager in cliff loads plugins before it runs them
19:48:00 <dtroyer> the external non-keystone client libs are not loaded until the actual command class starts
19:48:01 <dhellmann> *any of them
19:48:09 <dhellmann> ok
19:48:27 <dtroyer> take_action() is where we grab novalicent, via ClientManagerfor example
19:49:05 <dtroyer> I'm still curious why osc-debug was so slow, but that's out of scope unless it also affects all of the other plugins
19:49:41 <stevemar> looks like ksc v2 shell still creates a session https://github.com/openstack/python-keystoneclient/blob/d697ea29a6481b39cc8e05be2c386cf5fa2575c4/keystoneclient/shell.py#L201
19:50:03 <dhellmann> it would be interesting to see what https://github.com/dhellmann/smiley shows for some of these commands, maybe I'll give that a try
19:50:23 * dtroyer has another thing for the reading list
19:51:15 <dtroyer> #action dtroyer to add timing info to https://bugs.launchpad.net/python-openstackclient/+bug/1431649
19:51:16 <openstack> Launchpad bug 1431649 in python-keystoneclient "openstackclient is really slow" [Undecided,In progress] - Assigned to Robert Collins (lifeless)
19:52:17 <dtroyer> any other bugs to talk about?
19:53:02 <dhellmann> none for me
19:53:19 <dtroyer> #topic other repo news
19:53:50 <dtroyer> both cliff and os-client-config ACLs now include openstackclient-core, but nothing else has changed for them at this time
19:54:59 <dhellmann> I thought I'd remove oslo-core from cliff next week.
19:55:20 <dhellmann> dtroyer: that reminds me, do we have an official "topic tag" for the mailing list? I used "osc" I think but I'm not sure if that was right.
19:55:31 <stevemar> osc works for me
19:55:53 <dtroyer> dhellmann: I don't know if we do, I like that better than the openstackclient I've been using, more subject shows
19:55:55 <dhellmann> I don't know if we need to do anything to register a tag, or if we just need to be consistent
19:56:16 <dtroyer> I think there is a benefit to registering, will find out
19:56:28 <stevemar> didn't even know you could register them
19:56:28 <dhellmann> I'm sure reed would know
19:56:54 <dhellmann> yeah, I think it lets you see them in the mailman subscription UI, but I don't know if it picks up the topics automatically
19:57:16 <dtroyer> #action dtroyer find out if we have a registered ML tag, register OSC if we don't
19:57:16 <stevemar> any other tasks to do? now that we've been blessed?
19:57:33 <dhellmann> stevemar: take over the world?
19:57:44 <dtroyer> daemon mode!
19:57:45 <stevemar> that was already on the list
19:57:59 <dhellmann> stevemar: touché
19:58:40 <dtroyer> btw, I was looking at that in trying to speed up devstack, it works kinda, except I think we need to tweak the output a bit better to distinguish the end of a particular command
19:59:02 <dhellmann> dtroyer: daemon mode?
19:59:20 <dtroyer> t isn't really a daemon, more of a bas coproc with captive pipes in stdin/stdout
19:59:33 <stevemar> we're at time
19:59:45 <dtroyer> but load once, send/receive multiple commands
19:59:50 <dhellmann> dtroyer: we ought to be able to turn the interactive mode stuff into a way to do that, too
20:00:16 <dtroyer> I've alreadyproposed a bit of that in devstack, but things that need a value returned are 'hard'
20:00:17 <dhellmann> that might already work, actually
20:00:25 <dhellmann> yeah
20:00:34 <dtroyer> otherwise it works great
20:00:42 <dtroyer> ok, thanks everyone
20:00:48 <dhellmann> thanks
20:00:51 <dtroyer> #endmeeting