19:02:58 <dtroyer> #startmeeting OpenStackClient
19:02:59 <openstack> Meeting started Thu May 28 19:02:58 2015 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:03:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:02 <openstack> The meeting name has been set to 'openstackclient'
19:03:05 <terrylhowe> o/
19:03:15 <dtroyer> Agenda is at https://wiki.openstack.org/wiki/Meetings/OpenStackClient#28_May_2015
19:03:21 <dtroyer> pretty light
19:03:37 <dhellmann> o/
19:03:41 <stevemar> i will tack on something at the end
19:03:42 <dtroyer> #topic open actions
19:04:00 <dtroyer> I don't think we had any from before the summit, were there things from the summit that we should note here?
19:05:15 <stevemar> 'open actions' is weird
19:05:24 <stevemar> we need to fix the bug in 1.3.0
19:05:32 <dtroyer> yeah, ok, let's move on, we'll do a summit recap in a bit
19:05:42 <dtroyer> the test bug?
19:05:42 <stevemar> yeah, thats probably better
19:05:54 <stevemar> hmm, no, it's cliff related
19:06:06 <terrylhowe> namespace.debug?
19:06:11 <stevemar> https://bugs.launchpad.net/python-openstackclient/+bug/1459519
19:06:11 <openstack> Launchpad bug 1459519 in cliff "ERROR: openstack 'ArgumentParser' object has no attribute 'debug'" [Undecided,In progress] - Assigned to Terry Howe (thowe-g)
19:06:11 <stevemar> yep
19:06:22 <dtroyer> ok, let's jump to bugs then
19:06:23 <terrylhowe> well, there is a pbr issue there as well
19:06:25 <dtroyer> #topic bugs
19:06:34 <sigmavirus24> terrylhowe: which pbr issue? 1.0.x releases?
19:06:57 <terrylhowe> yeh, osc requires <2 and some dependencies require <1
19:07:37 <terrylhowe> I’m not sure what the fix is, get oslo.config and stevedore to cut new releases or something else
19:07:48 <dtroyer> heh, IIRC the deps need to get fixed.  I think they were getting done as issues came up
19:08:31 <dhellmann> there are a couple of ways to deal with the requirements issue, and we'll be doing some oslo releases next week that should help
19:08:52 <dims_> ++ dhellmann
19:08:58 <dhellmann> in the mean time if we tell pkg_resources not to check requirements when it loads plugins, that should also help
19:09:12 <dhellmann> stevemar: I can't reproduce the bug as reported
19:09:21 <dtroyer> I didn't see it either yesterday
19:09:30 <stevemar> dhellmann, thats a good thing then
19:09:33 <dtroyer> trying again now
19:09:42 <dhellmann> stevemar: is the plugin in question third-party?
19:09:55 <dhellmann> the error looks like not
19:09:56 <stevemar> doesn't look like it
19:10:08 <sigmavirus24> dhellmann: doesn't stevedore already handle this by default?
19:10:22 <dhellmann> it does, though I'm not sure we're using stevedore everywhere in cliff
19:10:35 <dhellmann> cliff's command manager was a special case at one point
19:11:02 <dhellmann> terrylhowe's fix in https://review.openstack.org/#/c/186394/1 looks simple enough, but it's failing some test jobs
19:11:22 <terrylhowe> those problems are related to test_shell which is another review
19:11:26 <dhellmann> ah, ok
19:11:48 <dtroyer> which is about to merge
19:12:53 <dtroyer> so is the pkg_resources thing something we can do in OSC?  I'm still a bit ignorant on that stuff
19:13:14 <stevemar> on the + side, it seems like we didn't break the gate
19:13:28 <dhellmann> dtroyer: let me peek at that code again, sec
19:14:19 <dhellmann> dtroyer: it looks like maybe we can
19:14:43 <dhellmann> this section: http://git.openstack.org/cgit/openstack/cliff/tree/cliff/commandmanager.py#n80
19:15:12 <dhellmann> should look more like: https://review.openstack.org/#/c/186111/1/novaclient/auth_plugin.py,cm
19:15:38 <dhellmann> I have a video meeting starting soon or I would put the patch together myself, but I can do it after that if no one beats me to it
19:16:06 <dtroyer> I'll take a stab at it after we're done here, may need your help/
19:16:10 <dtroyer> thanks dhellmann
19:16:22 <dhellmann> come to think of it, I think the feature stevedore is missing is a "load on use" flag, so I'll make a note of that and then we can move cliff to using it
19:17:34 <dtroyer> in other bug news, my new shell tests got a bit aggressive and o-c-c changed out from under them.
19:17:43 <stevemar> \o/
19:17:51 <dtroyer> terrylhowe put up https://review.openstack.org/186484 which is about to merge and should unblock us
19:18:18 <dtroyer> the tests need to be moved out of unit test, which of course I didn't do last week
19:18:33 <stevemar> should we do something more proactive about it? or just depend on occ?
19:19:04 <dhellmann> can we add some test fixtures to occ like we do with some of the oslo libs?
19:19:04 <terrylhowe> occ is family, so it seems to me we should depend on it
19:19:07 <dtroyer> they are really integration/functional tests to make sure we don't break things in the CLI/ENV/conf parsing
19:19:08 <stevemar> we could always just deal with breakage as it occurs... i dont think it'll happen often
19:19:32 <dtroyer> so in a sense, it worked, but in a place not intended
19:19:35 <stevemar> thats a lot of opinions :P
19:20:00 <terrylhowe> I would think occ would stablize there isn’t much to it
19:20:00 <stevemar> dtroyer, we have a functional test suite, we could make them functional tests
19:20:25 <terrylhowe> I think some additional functional tests testing —os-cloud etc would definitely be a good idea
19:20:33 <stevemar> ++
19:20:38 <dtroyer> stevemar: right, and that is my plan, but they probably are even more than that as I want to keep cliff and occ in the loop instead of mocking them out or something
19:21:27 <dtroyer> dhellmann: re occ tests, we certainly could add stuff there too, it's light
19:21:28 <dhellmann> right, so we either want testing with the real thing or with fixtures provided by those libraries where the API breaks can be prevented through tests upstream
19:22:13 <dhellmann> the idea is to move any setup that uses occ out of the osc tests and into a fixture that those tests can use, but make the fixture live in occ where the local tests can detect breaks
19:22:42 <dhellmann> we do that with oslo.config, for example
19:23:18 <dtroyer> right.  will catch up to that then
19:23:55 <dtroyer> so, any other bugs anyone wants to highlight here?
19:24:29 <stevemar> we partially fixed the glance v2 set/create bug...
19:24:48 <stevemar> https://bugs.launchpad.net/python-openstackclient/+bug/1405562
19:24:48 <openstack> Launchpad bug 1405562 in python-openstackclient "add support for v2 image create/update commands" [High,In progress] - Assigned to Amey Bhide (abhide)
19:24:48 <dtroyer> set only, right?
19:24:56 <stevemar> the bug is for set and create
19:25:02 <stevemar> amey did set
19:25:25 <dtroyer> they're so close, between v1 create and v2 set it should almost write itself
19:25:27 <stevemar> was wondering if we should split it into 2 bugs, and close on the 'update' change
19:25:54 <stevemar> maybe if i'm not so lazy i'll try and do v2 create
19:25:57 <dtroyer> If Amey is planning to do create I think leaving it is fine
19:26:10 <dtroyer> I don't have a strong opinion there
19:26:29 <stevemar> thats fine, was more of a heads up that we might have parity soon
19:26:30 <stevemar> yay
19:26:40 <stevemar> he's also working on the cinder v2 commands
19:26:58 <dtroyer> yup, was just about to mention that
19:27:43 <stevemar> eventually i want to talk about plugins and such, but change #topic first :P
19:27:57 <dtroyer> ok
19:28:12 <dtroyer> #topic steve and plugins
19:28:16 <dtroyer> go
19:28:18 <stevemar> hooray
19:28:39 <stevemar> looks like magnum is now on board with using osc plugins too
19:28:46 <stevemar> as per the ML
19:28:56 <stevemar> but they're having trouble with naming conventions
19:29:04 <stevemar> as container is also used by swift :(
19:29:19 <stevemar> and 'service'
19:29:41 <dtroyer> they may have to go to multi-word object names
19:30:04 <stevemar> also i think the heat team is looking to make osc plugins too. they already have code proposed to osc, so they are on the right path
19:30:21 <dtroyer> we are going to have to namespace as the number of projects grows
19:30:27 <spzala> stevemar: we will start working soon too on plugin for heat-translator to make it available during Liberty release
19:30:41 <dtroyer> I don't like the way congress did it but don't have a better idea yet
19:30:55 <stevemar> spzala, right, thats the other one
19:31:06 <spzala> Yup
19:31:16 <stevemar> dtroyer, theres another project under the heat umbrella called 'heat-translator' which has a simple CLI right now
19:31:35 <stevemar> think it makes sense for that to become as osc plugin too?
19:31:54 <stevemar> (i actually told spzala yes already so don't make me look silly)
19:32:00 <dtroyer> another option I threw out in a ML thread yesterday is to make creating top-level command names easier.  it would essentially re-cycle shell.py but be called something else
19:32:07 <sigmavirus24> stevemar: I'm going to say "No", just to make you look silly
19:32:14 <spzala> to get started on plugin, is the best way is to look at existing plugin or is there a doc out there? Seeing comment from dtroyer seems like there are multiple ways to create plugin?
19:32:16 <stevemar> sigmavirus24, nooo
19:32:21 <spzala> stevemar: :-)
19:32:24 <dtroyer> I'm going to say "abstain" because I haven't looked at its scope yet
19:32:31 <stevemar> spzala, http://docs.openstack.org/developer/python-openstackclient/plugins.html
19:33:05 <dtroyer> btw, I started a cookiecutter template for building these things on the plane home, it lies yet unfinished
19:33:15 <spzala> stevemar: cool, thanks. that's the one I was looking just now.
19:33:21 <dtroyer> is that a big enough deal I should move it up the list?
19:33:45 <stevemar> dtroyer, what will the cookie cutter do?
19:33:49 <dtroyer> because I suspect many projects ill put their osc plugin bits directly into ther client lib
19:34:05 <dtroyer> basically it sets up an empty osc-plugin repo
19:34:13 <stevemar> probably a good idea
19:34:20 <dtroyer> https://github.com/dtroyer/osc-plugin
19:34:26 <dhellmann> nice
19:34:45 <dtroyer> ok, Ill try to get it functional soon
19:35:19 <terrylhowe> how do you want handle that, bring it in as an osc project?
19:35:25 <dhellmann> the namespacing issue is tough. I don't like including project names either, but ensuring everyone picks nice descriptive names for nouns is also hard
19:35:36 <stevemar> terrylhowe, bring it under the openstackclient umbrella
19:35:42 <dhellmann> terrylhowe: that makes sense
19:35:49 <dtroyer> terrylhowe: the cookiecutter template?  that was my thought
19:35:53 <terrylhowe> cool
19:35:56 * dtroyer types slow
19:36:16 <dtroyer> any more on plugins?
19:36:21 <stevemar> y, one more thing
19:36:44 <stevemar> does the client have to list osc in requirements.txt?
19:36:54 <stevemar> a client that wants to create an osc plugin?
19:37:00 <spzala> dtroyer: nice (looking at github link)
19:37:10 <dtroyer> no, because it isn't a requirement
19:37:26 <dtroyer> if the plugin is in with a lib it should still be able to stand alone
19:37:32 <dtroyer> of course the plugin code is unused
19:37:45 <dtroyer> it's project choice though
19:37:52 <stevemar> ah, but if osc is installed, it'll automagically pick up the plugins?
19:37:56 <dtroyer> yes
19:38:04 <dhellmann> stevemar: no, we don't want clients listing osc as a requirement
19:38:11 <dhellmann> stevemar: and yes
19:38:14 * dhellmann types slower than dtroyer
19:38:28 <stevemar> if osc is installed first, then some client is installed, it'll still work out automagically?
19:38:40 <stevemar> s/client/plugin/
19:38:45 <dtroyer> yup, osc scans the entry points at runtime
19:38:49 <stevemar> thats neat
19:38:58 <stevemar> spzala, hope that answers a question you had ^
19:39:12 <stevemar> it also makes finding out which projects use osc plugins harder :)
19:39:22 <stevemar> was hoping to just scan req.txt
19:39:46 <dtroyer> if you are already looking in the repo, look in setup.cfg
19:39:49 <dhellmann> stevemar: we can look in setup.cfg for the namespace for our plugins
19:39:57 <stevemar> ++
19:39:57 <spzala> stevemar: nice, yep.
19:39:59 <stevemar> next topic
19:40:17 <dtroyer> #topic summit recap
19:41:21 * stevemar just realized congressclient doesn't package their own shell \o/
19:41:29 <dtroyer> I made a summary of the etherpads and didn't paste it anywhere yet…
19:41:44 <dtroyer> the highlights are…
19:42:06 <dtroyer> we confirmed that the backport policy is only critical bugs
19:42:46 <dtroyer> we confirmed that vendor-specific network commands will be plugins and not in the OSC repo
19:43:33 <dtroyer> caching: auth cache to be triggered out of ksa
19:44:02 <dtroyer> suggested to use requests-cache for data caching, needs investigation
19:44:16 <dtroyer> I'll do that if nobody else really had a need to jump on it
19:45:10 <stevemar> dtroyer, i think sigmavirus24 could be helpful there :P
19:45:16 * stevemar throws ian under the bus
19:45:33 <sigmavirus24> oh don't use requests-cache
19:45:34 * dtroyer secret plot for help is exposed ;)
19:45:49 <sigmavirus24> cachecontrol is the only library that requests recommends
19:45:54 <sigmavirus24> It's used with a lot of success by pip
19:46:07 <stevemar> Zucan, was in -sdks looking for osc help, i dragged him here
19:46:22 <dtroyer> ok, I'll look at cachecontrol first then
19:46:30 <Zucan> Thank you... wasn't looking for help, just looking for best way to "plugin into the process" :)
19:47:01 <dtroyer> Zucan: welcome
19:47:03 <stevemar> looking to test out new features or help with some dev? :)
19:47:07 <sigmavirus24> Zucan: step 1: get surgery to add an RJ45 jack to your brain ;)
19:47:50 <dtroyer> resuming summary…
19:47:51 <Zucan> stevemar: probably a little of both, though, likely more on testing side.  I attended some of the openstack client worksessions on Friday at the summit (morning time)
19:49:14 <stevemar> dtroyer, resume away
19:49:16 <dtroyer> agreed to rename project to 'OpenStackClient' (lowercase the package name) at 2.x release;  conflicts with renaming comamnd to 'os' or 'osc' noted, we will not rename the command
19:49:31 <dtroyer> pip namespace already reserved
19:49:36 <dtroyer> er, pypi
19:49:53 <stevemar> ++ i had a private git repo with everything renamed
19:50:01 <stevemar> but i suspect it's crazy out of date now
19:50:38 <dtroyer> talked about the sdk migration, strong preference to do it bits at a time rather than a big-switch
19:51:21 <dtroyer> I don't recall a firm decision on that requiring a major version bump, seems like it owuld at some point to me, we can work that out when we actually have that problem
19:52:13 <dtroyer> A list of known projects with OSC plugins is now in the docs.
19:52:49 <dtroyer> There were also some comments from nkinder regarding domain-related usability
19:53:04 <terrylhowe> ksa might be on the roadmap
19:53:41 <dtroyer> IIRC the main thing is using names where IDs are required now, that will take a series of changes across multiple projects
19:54:36 <dtroyer> terrylhowe: thanks.  we talked about the layering of osc/occ/ksa in the work session a good bit
19:55:10 <dtroyer> I didnt' take notes, what is in the etherpad is basically what I remember, we need to look at a couple of ways to layer these three
19:56:00 <dtroyer> also from that session was the precedence discussion between cli options, environment variables and config file settings.
19:56:09 <dtroyer> we will use that order
19:56:28 <dtroyer> and we're nearly out of time so I'll stop, that's the big stuff
19:56:36 <dtroyer> except for whatever I missed  ;)
19:56:46 <dtroyer> so what did I miss?
19:56:59 <stevemar> think you got it all
19:57:02 <stevemar> and neutron
19:57:16 <terrylhowe> covered all tthe big points I think
19:57:49 <terrylhowe> I’ll get back on neutron soon I’d expect
19:58:21 <dtroyer> cool.  I'd hoped for that to just start with the sdk and not use neutronclient any more
19:58:41 <terrylhowe> yeh, I’m going to give that a shot
19:58:49 <dtroyer> great, thanks
19:58:56 <dtroyer> #topic open discussion
19:59:00 <dtroyer> two minutes left...
20:00:35 <dtroyer> terrylhowe: looks like your fix got things moving again, we can recheck the failed reviews from last night
20:00:46 <terrylhowe> cool
20:01:02 <dtroyer> and with that, thanks everyone!
20:01:06 <dtroyer> #endmeeting