13:01:07 <dtroyer> #startmeeting openstackclient
13:01:09 <openstack> Meeting started Thu May 19 13:01:07 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:12 <openstack> The meeting name has been set to 'openstackclient'
13:01:26 <dtroyer> Anyone here for our first new-time meeting?
13:01:55 <rtheis> hi
13:02:07 <dtroyer> \o/  I am not alone! ;)
13:02:25 <dtroyer> which means that my even/odd week math finally worked
13:04:20 <dtroyer> well, let's start and see if anyone else shows up
13:04:44 <dtroyer> #topic reviews
13:04:57 <dtroyer> anything to talk about rtheis?
13:05:29 <rtheis> dtroyer: https://review.openstack.org/#/c/307629/
13:06:10 <dtroyer> right… I am concerned about not breaking (or un-breaking?) non-table formatters here
13:06:19 <rtheis> should we drop most formatting if non-table?
13:06:25 <reedip_> Hi!
13:06:40 <dtroyer> reedip_: hi
13:06:45 <dtroyer> rtheis: maybe so?
13:07:17 <dtroyer> part thinking in that case, especially for JSON, is that it's likely to be machine read anyway
13:07:52 <amotoki> from my experience, if json format is specified, there is no need to use a formatter.
13:08:01 <rtheis> dtroyer, yeah which makes me think we should format dicts or list as we do
13:08:08 <rtheis> *shouldn't
13:08:30 <dtroyer> I've been down this path before, wanting to teack cliff to know the difference...
13:08:56 <dtroyer> https://review.openstack.org/287536
13:09:09 <rtheis> yep, that's the one I was thinking about
13:09:38 <dtroyer> that provides a way for us to know when to skip it altogether, and I think takes care of my worries
13:10:06 <dtroyer> I'll see if dhellmann, stevemar, etc will have another look at it
13:10:16 <rtheis> sounds good
13:10:23 <amotoki> i like the flag :)
13:11:03 <dtroyer> ok, other reviews?
13:11:55 <rtheis> none from me
13:11:56 <dtroyer> I am still a bit behind, my apologies, the osc-lib work has soaked up a lot of time
13:12:36 <dtroyer> #topic bugs
13:12:57 <dtroyer> I am even further behind on culling the bug list, does any need priority attention?
13:13:27 <rtheis> I don't recall any critical bugs
13:13:29 <reedip_> none from my end
13:14:22 <dtroyer> ok, so then we move on
13:14:34 <dtroyer> #topic osc-lib
13:15:11 <dtroyer> We have officially added the osc-lib repo to the OpenStackClient project, it is populated and I've started pushing in the initial changes
13:15:29 <dtroyer> https://review.openstack.org/#/q/project:openstack/osc-lib,n,z
13:15:36 <rtheis> nice
13:15:58 <rtheis> dtroyer: sorry, I haven't had much time to review that work
13:16:24 <dtroyer> I've been a little free with approving stuff for a couple of days, but it's time to get back to the usual two +2 to merge now, as from here on more of the work will have opinions attached to it
13:16:51 <rtheis> sounds good
13:17:05 <reedip_> +1
13:17:15 <dtroyer> the shell refactor does more than I would have liked, but the tests were a mess to begin with
13:17:19 * dtroyer looks in mirror
13:17:49 <dtroyer> I do have an OSC branch that is tracking this work
13:18:19 <dtroyer> https://github.com/dtroyer/python-openstackclient/tree/osc-lib
13:19:06 <dtroyer> my plan is to not merge any osc-lib bits into OSC until we are working on the 3.0 stuff
13:19:50 <dtroyer> any questions on osc-lib?
13:20:19 <rtheis> so we need to be aware of dual maintenance until then?
13:20:37 <dtroyer> yes
13:21:17 <dtroyer> I'm trying to keep an eye on that… for example, I've already taken bits of Navid's ksa patch into osc-lib
13:21:42 <rtheis> ok, I'll keep an eye out too
13:22:15 <dtroyer> fortunately, the bulk of the work was copy + s/// so it'll be easy to port stuff over
13:22:25 <dtroyer> ClientManager and OpenStackShell are the two major exceptions
13:23:32 <dtroyer> ok, if nothing else…
13:23:47 <dtroyer> #topic releases
13:24:12 <dtroyer> I think we are going to be able to stick to the tentative release schedule we talked about in Austin
13:24:26 <dtroyer> which is basically do 2.5.0 before the end of May
13:24:42 <dtroyer> and 3.0 before N-2, which IIRC is in late June
13:25:38 <rtheis> sounds good
13:25:51 <rtheis> is there a list of TODOs being tracked to handle in 3.0?
13:25:59 <dtroyer> 3.0 will include the package name change (from python-openstackclient to openstackclient), osc-lib, the floating/fixed ip commands, and other smaller breaking-ish things
13:26:20 <rtheis> ok
13:26:24 <dtroyer> #action dtroyer to put the list of 3.0 bits into etherpad
13:26:36 <rtheis> thanks dtroyer
13:26:36 <amotoki> what is the background of renaming to openstackclient?
13:27:10 <dtroyer> the 'python-' prefix is generally used for libraries, which is why the project lcient packages have it.
13:27:23 <dtroyer> We just copied them without realizing that a stand-alone command should not have it
13:27:36 <amotoki> agree. we don't need to care how CLI is implemented.
13:27:42 <dtroyer> we're not planing to rename the repo, just the package published to PyPI
13:28:14 <tangchen_> Hi, guys, I'm late.
13:28:28 <dtroyer> welcome tangchen_!
13:28:45 <rtheis> hi tangchen_
13:28:56 <tangchen_> Hi~~
13:29:21 <dtroyer> oh, the other major thing I didn't list for 3.0 is the ksa/auth rework
13:29:48 <dtroyer> totally getting ksc out of the auth picture, it'll only be used in OSc for the identity CRUD
13:30:05 <dtroyer> (this iss Navid's patch I referred to earlier)
13:30:51 <dtroyer> #topic open discussion
13:31:00 <dtroyer> What else do y'all want to talk about?
13:31:01 <Na_> hi
13:31:25 <Na_> i create a new bp https://blueprints.launchpad.net/python-openstackclient/+spec/neutron-services-transition today
13:31:29 <tangchen_> I'd like to ask something neutronclient
13:31:40 <tangchen_> Oh, yes
13:31:58 <tangchen_> Na_ asked me about it today.
13:32:07 <Na_> i want to know is there any plan about neutron-*aas CLIs transition
13:32:12 <dtroyer> Na_: what do you need from OSC to do that work?
13:32:15 <rtheis> Na_: those currently belong in python-neutronclient
13:32:19 <rtheis> as OSC plugins
13:32:31 <amotoki> we will have osc plugins for neutron service commands
13:32:36 <dtroyer> My understanding is that those are all plugins that will be in either neutronclient repo or independant
13:32:48 <Na_> rtheis: the patch you submit about add osc plugin to neutronclient has no update for about 2 weeks
13:32:54 <dtroyer> ok, seems like we all have the same understand there
13:33:04 <amotoki> we will plan to have them in python-neutronclient repo now.
13:33:22 <rtheis> Na yes, I haven't had time to get back to that.
13:33:33 <Na_> rtheis: if your patch is not merged, i can not do next work
13:33:58 <amotoki> i must review it too.
13:34:19 <Na_> rtheis: i need finished neutron-dynamic-routing CLI transition before N-1
13:34:32 <Na_> amotoki: pls, thanks
13:34:40 <rtheis> Na_ feel free to take over the patch set
13:34:49 <amotoki> related to neutron stuff, btw, does anyone know the conclusion on discussion whether nova admin commands should exist in osc?
13:35:03 <amotoki> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093955.html
13:35:19 <amotoki> if not, I'd like to ask it in -dev list.
13:36:01 <Na_> rtheis: ok, i need time to learn it
13:36:39 <dtroyer> amotoki: I don't think that thread came to any changes in the current practice re separating admin out of OSC for the existing APIs
13:37:07 <dtroyer> policy makes anything we base on the defaults subject to deployment change
13:37:33 <Na_> rtheis: amotoki: tangchen_: thanks your help
13:37:48 <tangchen_> Na_: np :)
13:38:01 <dtroyer> amotoki: if you have a more specific question fro the ML, feel free to raise it
13:38:17 <rtheis> amotoki: there is a patch set that one may consider admin currently in the queue: https://review.openstack.org/#/c/315834/
13:38:30 <amotoki> dtroyer: thanks. I am wondering where neutron admin commands should go.
13:38:41 <dtroyer> so far we are erroring on the side of inclusion for the existing APIs
13:39:18 <dtroyer> so "things pertaining to the Network API go in the OSc repo, others are plugins" is my default response to that
13:39:55 <amotoki> my current vote is same too.
13:40:12 <dtroyer> also, nothing vendor-specific goes into OSC
13:40:46 <amotoki> agree too. neutornclient repo already push out vendor stuff.
13:41:35 <tangchen_> BTW, about the glanceclient
13:41:45 <tangchen_> https://blueprints.launchpad.net/python-openstackclient/+spec/migrate-glanceclient-to-osc
13:42:04 <tangchen_> I asked glance team, and they agreed to start the work. :)
13:42:10 <tangchen_> just for your info.
13:42:23 <dtroyer> good news!
13:42:43 <rtheis> nice
13:42:51 <dtroyer> glanceclient has been high on my list for SDK migration for a long time, due to the unique dependencies it has
13:43:13 <dtroyer> we can't merge any of that though until we have an SDK 1.0 release
13:43:32 <dtroyer> we have the network exception to that rule because it is all new work
13:44:07 <briancurtin> dtroyer: i’m quite close to merging the compute refactor for what will turn into the 1.0 final API. i can do glance next if people want to get a head start on integration leading up to 1.0
13:44:34 <dtroyer> that is great to hear briancurtin
13:45:04 <tangchen_> OK, but do we have any idea when will the sdk 1.0 release ?
13:45:20 <briancurtin> tangchen_: “soon” - i’m not doing estimates anymore
13:46:00 <tangchen_> braincurtin: Hi, I'm sorry I don't quite understand what you said about 1.0 final API
13:46:01 <rtheis> looking for my list of todos for OSC network commands ...
13:46:22 <rtheis> https://etherpad.openstack.org/p/newton-openstackclient
13:46:41 <tangchen_> bgiancurtin: Is the work on the sdks side ?
13:46:50 <briancurtin> yes.
13:46:54 <rtheis> See "Overview Transition to SDK 1.0" for some of the things wee need to do on OSC side to handle SDK 1.0
13:46:55 <tangchen_> bgiancurtin, sorry for the name
13:47:32 <tangchen_> rtheis, bgiancurtin: OK, thx :)
13:48:27 <dtroyer> any other topics?
13:48:35 <tangchen_> OK, I have nothing to say.
13:48:40 <rtheis> nothing else
13:48:49 <amotoki> none from me
13:49:55 <dtroyer> well then, let's have 10 extra minutes to get a snack!
13:50:04 <dtroyer> thank you everyone!
13:50:17 <rtheis> thanks
13:50:21 <tangchen_> thx. :)
13:50:27 <dtroyer> #endmeeting