13:01:03 <dtroyer> #startmeeting openstackclient
13:01:03 <openstack> Meeting started Thu Jul 28 13:01:03 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:07 <openstack> The meeting name has been set to 'openstackclient'
13:01:18 <rtheis> hi tangchen
13:01:21 <stevemar> o/
13:01:34 <stevemar> oh wow, we're all here
13:01:44 <dtroyer> Hi gang!
13:01:49 <tangchen> Hi, stevemar, rtheis, dtroyer
13:01:53 <tangchen> :)
13:02:26 <dtroyer> I am fighting laptop/browser issues so flying a bit blind right now
13:02:37 <dtroyer> timing is everything, right?
13:02:46 <tangchen> haha
13:03:02 <dtroyer> #topic release status
13:03:09 <dtroyer> So let's talk 3.0 release
13:03:30 <dtroyer> It seems the pressure is all on the osc-lib work to complete now, correct?  maybe one more thing from Henry?
13:03:54 <dtroyer> (which may be what was proposed yesterday)
13:04:01 <stevemar> yeah, and he just posted something
13:04:08 <dtroyer> ok, cool
13:04:17 <stevemar> i'll take a look at it today
13:04:56 <dtroyer> I was hoping to be done this week, and have gotten stuck on reproducing the failures in the shell review
13:05:38 <rtheis> and for osc-lib, do we want release notes?  There are a couple conflicting reviews.
13:05:55 <stevemar> rtheis: it doesn't hurt to have it, we never had a reason until now
13:06:03 <stevemar> looks like someone proposed the directory structure
13:06:03 <dtroyer> good question… most libs do not have reno-based release notes (based on a sampling of oslo and a few others)
13:06:13 <stevemar> https://review.openstack.org/#/c/348210/
13:06:18 <dtroyer> since those are end-user focused
13:06:38 <dtroyer> is there a strong feeling that we should have that?  or just the dev docs?
13:06:56 <dtroyer> I am leaning toward just dev docs but am not stuck on that
13:06:57 <stevemar> i think just the dev docs are fine, osc-lib isn't meant to be end user facing
13:07:03 <rtheis> I say we match other libs
13:07:07 <rtheis> so dev docs are fine
13:07:24 <dtroyer> ok
13:07:25 <stevemar> i'll update the patch
13:07:36 <rtheis> thanks stevemar
13:07:37 <dtroyer> #agreed osc-lib will not use reno release notes
13:07:59 <dtroyer> and +A Andrea's cleanup then, I've been holding off on that until we had this conversation
13:08:19 <dtroyer> #topic osc-lib
13:08:55 <dtroyer> while we're on that, I have also been holding off on another osc-lib release in case I needed something for the shell work, but I think it's time to do 0.4.1 at least there
13:09:27 <stevemar> +A'ed ajaegers cleanup
13:09:42 <dtroyer> thanks
13:09:44 <tangchen> me too
13:10:44 <stevemar> we only have 5 commits unreleased https://github.com/openstack/osc-lib/compare/0.4.0...master
13:11:08 <stevemar> 2 of which are minor
13:11:12 <dtroyer> right, osc needs some of them for the shell work
13:11:14 <stevemar> actually 3 commits
13:11:26 <dtroyer> and its taking 3+ days to do release, g-r and u-c updates these days
13:11:31 <stevemar> OK
13:11:48 <stevemar> who wants to create the release? :)
13:12:08 <tangchen> I'd like to try onec
13:12:10 <tangchen> once
13:12:13 <dtroyer> rtheis, tangchen: want some practice?
13:12:16 <dtroyer> ok, cool, thanks
13:12:17 * dhellmann arrives late
13:12:26 <rtheis> thanks tangchen
13:12:37 <tangchen> thanks, Richard. :)
13:12:44 * dtroyer backs up a bit to confirm something with dhellmann
13:12:47 <tangchen> Any guide please ?
13:12:50 <stevemar> tangchen: you just gotta copy https://github.com/openstack/releases/commit/e305d347a68b2619cbadb0ae05453e652fde9ae1
13:13:27 <dhellmann> dtroyer : reno?
13:13:28 <dtroyer> dhellmann: we're not planning for reno-style release notes for osc-lib, that seems consitent with most others, correct?
13:13:42 <stevemar> tangchen: as dtroyer said, mark it 0.4.1 and get the most recent hash (7a8b05152ac49f3895bef56be4424171c3917dd8)
13:14:18 <dhellmann> we're adding reno to libs that have config options that deployers would see. I don't think that applies to osc-lib. I don't know if there are any other user-facing things that make sense to include in release notes there?
13:14:18 <dtroyer> *most other libs
13:14:22 <tangchen> stevemar: OK, I'll try it tomorrow
13:14:37 <dtroyer> dhellmann: no, there shouldn't be anything like that
13:14:40 <stevemar> tangchen: we need it a bit sooner :(
13:14:53 <dhellmann> so osc-lib doesn't define any command line options?
13:14:54 <stevemar> tangchen: the release team doesn't allow releases on fridays
13:14:55 <tangchen> Oh, now ?
13:15:06 <stevemar> (in case a gate is broken)
13:15:38 <stevemar> tangchen: should only take a minute, i can do it if you want, i know it's late your time
13:16:00 <tangchen> Oh, I can do it.
13:16:02 <dtroyer> dhellmann: hmmm… actually it has most of the global options, yes.  so is there a way for osc to ppick those up naturally?
13:16:04 <tangchen> working on it
13:16:06 <tangchen> one min
13:16:15 <stevemar> tangchen: thanks :)
13:16:35 <dhellmann> dtroyer : we don't currently have a way to pull notes from one repo into another, no. :-/
13:17:26 <dtroyer> but having the reno notes in osc-lib would at least make references cleaner
13:17:31 <amotoki> even though osc-lib has a release note like reno style, it is not easy that users track changes in dependent libraries.
13:17:56 <dhellmann> amotoki : that's a good point, putting release notes in the library might be a little confusing
13:17:59 <amotoki> i think what we can do is just to mention osc-lib or other libs had such changes.
13:18:09 <dhellmann> we could address that by having osc's release notes point to the lib notes for "more details"
13:18:14 <dhellmann> right
13:19:02 <amotoki> it's not best but it sounds better approach
13:19:19 <dtroyer> the user-unfriendly bit there is knowing _which_ osc-lib is installed.  this is ok for service deployers, unfortunate for end-users
13:19:32 <dhellmann> dtroyer: true
13:19:36 <dtroyer> and not something I though of when we decided to do the split.
13:19:47 <dtroyer> but also minor in the Big Scheme of Things
13:20:17 <dhellmann> maybe we can do something with the --version output of osc to expose that better
13:20:21 <stevemar> dtroyer: osc-lib *ideally* shouldn't be changing too often after the big split
13:20:57 <dtroyer> dhellmann: I'll make sure it is included in module show output too
13:21:09 <dtroyer> that'll ease that pain a bunch
13:21:11 <dhellmann> ++
13:22:02 <tangchen> stevemar: Shall we hash it to ef4a4f143b1f96ac8c2a685a8e1a4e96c802cb0d ?
13:22:14 <tangchen> Seems it was merged just now.
13:22:37 <tangchen> the releasenote cleanup
13:22:43 <rtheis> are we back to osc-lib release notes?
13:22:50 <dtroyer> tangchen: you could, not necessary though
13:22:54 <dtroyer> rtheis: yes
13:23:02 <rtheis> ok
13:23:52 <dtroyer> lets move on...
13:24:00 <dtroyer> #topic review highlights
13:24:12 <dtroyer> Any reviews that need to be brought up here?
13:24:54 <rtheis> https://review.openstack.org/#/c/340624/
13:25:04 <rtheis> a couple items on this review...
13:25:29 <rtheis> 1) https://review.openstack.org/#/c/340624/14/neutronclient/osc/v2/trunk/trunk.py
13:25:34 <rtheis> rom openstackclient.identity import common as identity_common
13:25:40 <rtheis> from openstackclient.identity import common as identity_common
13:26:03 <rtheis> Is this available to plugins and is there a plan to move any of this to osc-lib
13:26:15 <rtheis> this = identity common utilities
13:26:52 <stevemar> tangchen: sure, sounds like a good level
13:26:54 <dtroyer> we really have not talked about moving API-specific bits to osc-lib, although it may not be out of the question
13:27:15 <amotoki> so far neutron osc plugin wants to use find_project() and option definitions from identity.common.
13:27:15 <dtroyer> Identity has a bit of a special place though in that everyone needs bits of it
13:27:55 <dtroyer> the reason to move it is so plugins do not depend on osc itself, so stand-along CLIs are possible
13:28:08 <dhellmann> it might make sense to expose some of the identity api through osc-lib, either fully by giving the identity client, or partially by giving a wrapper
13:28:41 <dhellmann> I could see commands wanting to do things like translate UUIDs returned by APIs to names, for example
13:28:57 <dtroyer> I think most of the stuff (from memory) in identity.common doesn't require a client to exist if it isn't called…
13:29:28 <stevemar> dtroyer: some functions expect a client to be passed in the args
13:29:37 <dtroyer> right, which is find for a lib
13:29:42 <stevemar> ja
13:29:45 <dtroyer> if you don't use it there isn't a cost
13:30:12 <rtheis> yep, that looks right
13:30:19 <dtroyer> so if we can do it without forcing ksc or the sdk to be included we should be ok
13:30:26 <stevemar> it would be nice to be consistent, so other projects don't reimplement it
13:30:41 <dtroyer> exactly, and osc-lib is meant to be the plugin interface
13:30:43 <amotoki> stevemar: +1
13:31:00 <dtroyer> so we need to support that.  maybe post 1.0 though
13:31:21 <tangchen> <amotoki>: Hi, I know the problem. And yes, +1
13:31:41 <rtheis> ok, so in the short term should we suggest that plugins duplicate the code until osc-lib has it
13:31:59 <stevemar> dtroyer: in this case, the common one they are using is just adding an argument to parsed_args, so its really easy to add support for this
13:32:21 <stevemar> rtheis: yeah, its a small function anyway
13:32:22 <dtroyer> yay! more args/option in osc-lib!  :)
13:32:41 <amotoki> for short term in neutornclient, i would like to gather such things in https://review.openstack.org/#/c/348097/
13:32:42 <dtroyer> can someone put together an initial proposal for osc-lib for this?
13:32:58 <rtheis> sounds good
13:33:22 <dtroyer> the easy stuff can go in quickly, but I don't want to hold up osc-lib's 1.0 (which would hold up osc's 3.0) if we can help it
13:34:18 <rtheis> amotoki: is this something you'd be willing to do since you are working the neutron end too?
13:34:26 <rtheis> and may be the first user
13:34:51 <amotoki> rtheis: it is just an initial version, but i am thinking this kind of thing is required.
13:35:12 <rtheis> ok
13:35:24 <amotoki> rtheis: we only see two implementations for OSC plugin, but we already see many code duplications.
13:35:24 <tangchen> +1 for gathering them all together.
13:35:27 <dtroyer> amotoki: agreed… I'm just running slower than I'd like atm
13:36:02 <amotoki> it is a bit late in a dev cycle, so i think it is fair that we do this kind of things in each repo and collect them in the beginning of the cycle.
13:37:00 <dtroyer> amotoki: that may be the case for the plugins, but go ahead and start putting it into osc-lib too
13:37:30 <amotoki> dtroyer: yeah, i am thinking so.
13:37:48 <amotoki> but I think we need to gather inputs a bit more.
13:37:55 <dtroyer> ok
13:38:02 * dtroyer finally got a peek at that review…
13:38:19 <dtroyer> is 'network trunk' the final resource name?
13:38:41 <rtheis> dtroyer: that is the current plan
13:38:58 <rtheis> nothing merged yet
13:39:53 <dtroyer> (assuming these are .1q trunk ports) is 'trunk port' out of the question?
13:39:59 <amotoki> in general I think it is better that networking commands have 'network' prefix unless it is clear that command names belong to 'networking'.
13:40:14 <dtroyer> I haven't read all of the comments yet so don't know what the history is
13:41:14 <rtheis> dtroyer: I suggested "network trunk" or "trunk port" in patch 3
13:41:15 <dtroyer> I believe we should use the best descriptive name that a user will understand, if that means prepending 'network', ok, but it should not be done automatically
13:42:26 <dhellmann> dtroyer : ++
13:42:34 <amotoki> i think we don't need 'network' prefix for 'load balancer' or 'vpn', but if it is not clear that a command name belongs to 'networking' 'network' prefix sounds okay.
13:42:35 <dtroyer> I'll leave a comment… I agree trunk port is clearer to me, although is it greatly different from a port otherwise?  The options might be different enough to warrant a specific resource
13:43:06 <rtheis> dtroyer: thanks, there is some concern in https://review.openstack.org/#/c/340624/17/setup.cfg too
13:43:13 <dtroyer> I would have started with port —trunk, but again, I haven't read this in any detail yet
13:43:50 <rtheis> a trunk port is a new resource in neutron db which contains ports
13:43:51 <amotoki> rtheis: a verb 'enumerate'?
13:44:02 <rtheis> amotoki: yes
13:44:15 <rtheis> and a subport command object
13:44:28 <dtroyer> ok, so a trunk is a port container?  that is different, and maybe is enough to not include port in the name.
13:44:31 <amotoki> rtheis: honestly 'list' is sufficient.
13:44:38 <dtroyer> just because it is differnt in the db, though, doen't mean anything to a user
13:44:48 <stevemar> amotoki: ++
13:45:20 <rtheis> dtroyer: that is my understanding of a trunk
13:45:25 <rtheis> amotoki: is that correct?
13:45:55 <amotoki> rtheis: I think so too, but i haven't fully followed the development of trunk port...
13:45:57 <dtroyer> I'll read up on it.  trunk means 802.1q trunk to most network folk, so if it isn't that it will be fun
13:46:46 <rtheis> dtroyer: thanks for your input
13:47:07 <rtheis> nothing else from me on that review
13:47:15 <dtroyer> ok, thanks
13:47:18 <dtroyer> any other reviews?
13:47:34 <amotoki> rtheis: thanks for raising these!
13:47:39 <rtheis> yw
13:47:58 <tangchen> No from me.
13:48:19 <dtroyer> ok, how about…
13:48:22 <dtroyer> #topic bugs
13:49:59 <rtheis> I don't have any to discuss
13:50:01 <dtroyer> no bugs?
13:50:11 <dtroyer> well, with 10 minutes remaining:
13:50:14 <dtroyer> #topic open discussion
13:50:20 <dtroyer> what is on our minds today?
13:51:21 <rtheis> dtroyer: unfortunately, I'm thinking about neutron extensions
13:51:42 <rtheis> I had a discussion with armax about some of the neutron osc plugins
13:51:51 <rtheis> many require neutron extensions to be enabled
13:52:08 <dtroyer> that's a fun thing
13:52:20 <dtroyer> and discovery of that, right?
13:52:24 <rtheis> should we have a general check up front in command object to fail
13:52:26 <rtheis> right
13:52:39 <rtheis> and does it also belong in osc-lib
13:53:12 <dtroyer> is that info available in the / route yet?  (at version negotiation time?)
13:54:00 <rtheis> dtroyer: I don't know
13:54:11 <amotoki> in neutron, if a corresponding neutron extension is not available, 404 is returned. IIRC, what armax said is that we would liek to distinguish 404 and not supported.
13:54:47 <dtroyer> ok, as long as that info is readily available we can handle it
13:55:00 <rtheis> amotoki: that's right, thanks
13:55:02 <dtroyer> if we can get help out of the version negotiation that's better
13:55:31 <dtroyer> it doesn't sound like special-case error handling is too hard though, and if it's basically boilerplate for osc-lib we can do that
13:55:52 <dtroyer> like with Identity though, if it requires additional dependencies for osc-lib we'll need to think hard about it
13:56:07 <rtheis> dtroyer: sounds good
13:56:09 <rtheis> thanks
13:56:12 <dtroyer> also, in this case how much should go to the SDK?
13:56:19 <amotoki> perhaps we can define requirement conditions (like micro-version or extensions) somewhere.
13:56:32 <dtroyer> if these are common problems for apps that may make long-term sense
13:56:55 <rtheis> https://review.openstack.org/#/c/343992/
13:56:58 <dtroyer> amotoki: as we make those things consistent across APIs, yes, I'd love to do that
13:57:04 <rtheis> SDK api microversion support in review now
13:57:11 <dtroyer> \o/
13:58:04 <dtroyer> we can prototype this sort of extension handling between osc and plugins, and migrate it into the appropriate dependencies/libs as it gets worked out
13:58:36 <rtheis> good idea
13:58:53 <amotoki> it will be a good input to SDKs :)
14:00:06 <rtheis> we out of time
14:00:08 <dtroyer> tangchen: thanks again for doing the osc-lib release, it looks good
14:00:10 <dtroyer> yup
14:00:16 <tangchen> thanks. :)
14:00:18 <dtroyer> thanks everyone! awesome meeting!
14:00:18 <rtheis> thanks
14:00:23 <dtroyer> #endmeeting