15:31:05 <mestery> #startmeeting neutron_drivers
15:31:05 <openstack> Meeting started Wed Feb 18 15:31:05 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:31:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:31:08 <openstack> The meeting name has been set to 'neutron_drivers'
15:31:13 <mestery> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers Agenda
15:31:25 <mestery> The only thing to discuss is based on the email armax sent yesterday
15:31:30 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/057196.html
15:31:37 <mestery> #topic Patch Discussion
15:31:46 <armax> mestery: is there’s any other item to discuss I am happy to hear it
15:31:59 <mestery> armax: dougwig had something, though we'll get to that at the end
15:32:06 <armax> mestery: cool
15:32:12 * mestery realizes dougwig may still be in bed
15:32:24 <mestery> OK, lets get started with the first patch on the list
15:32:25 <mestery> #link https://review.openstack.org/#/c/155373/
15:32:41 <armax> ihrachyshka: you around?
15:32:43 <mestery> This is the monkey patch from ihrachyshka.
15:32:45 <ihrachyshka> armax, sure
15:32:57 <salv-orlando> LOH
15:33:12 <ihrachyshka> I think markmcclain concerns are really valid and this one needs discussion, hence email thread and we discussing it here :)
15:33:33 <mestery> Excellent!
15:33:43 <ihrachyshka> afaik markmcclain wants us to look at getting rid of eventlet
15:33:49 <ihrachyshka> which I support with all my heart
15:33:52 <armax> I like amotoki’s proposal
15:33:55 <mestery> That seems like a good goal to have :)
15:34:07 <ihrachyshka> and we should look into doing some work around it the next cycle (i'm in)(
15:34:17 <markmcclain> cool
15:34:22 <ihrachyshka> that said, I think the patch series is worth going now, for they fix potential issues
15:34:32 <armax> ihrachyshka: not sure how straightforward or realistic it is to get rid of eventlet at this point
15:34:41 <ihrachyshka> and actually allows us to consider switching to threading model case by case later
15:34:51 <ihrachyshka> since we will have more clear view of what's patched
15:34:59 <markmcclain> right I do think a measured approach is best
15:34:59 <armax> ihrachyshka: that sounds like a plan to me
15:35:05 <ihrachyshka> armax, I updated patches as per amotoki comments
15:35:12 <armax> ihrachyshka: cool
15:35:16 <markmcclain> looking at amotoki's comment is a good suggestion
15:35:34 <ihrachyshka> right, you can all check latest upload, it uses 'dumb' main()s
15:35:37 <salv-orlando> that makes sense to me as well
15:35:46 <markmcclain> the only lingering question is what about some of hte plugin agents
15:35:54 <markmcclain> given that we're trying to spin them out
15:36:02 <mestery> That's a good point markmcclain
15:36:09 <markmcclain> is moving their mains into the cmd sub tree .. something we want?
15:36:09 <ihrachyshka> I guess some/most of them will stay for kilo?
15:36:16 <mestery> markmcclain: You're talking about LB and OVS agents with regards to ML2 right?
15:36:31 <ihrachyshka> mestery, there are other vendor plugins as well
15:36:37 <markmcclain> all of them
15:36:46 <armax> markmcclain: I don’t think we have to worry about all of them
15:36:50 <ihrachyshka> (btw some vendor agents are not actually patched, like mellanox0
15:36:51 <salv-orlando> is this really a blocker?
15:36:52 <marun> all of them?
15:36:55 <amotoki> I think htere are two options: in-tree or handle it in their trees.
15:37:01 <markmcclain> salv-orlando: not a blocker
15:37:04 <mestery> amotoki: ++
15:37:09 <markmcclain> just want to make sure we have clear plan
15:37:11 <amotoki> if they want to keep something in tree, they need to follow neutron convention.
15:37:24 <ihrachyshka> amotoki++
15:37:40 <ihrachyshka> which is I guess will be 'a dumb main calling proper main that is located wherever they want'
15:37:53 <markmcclain> +1 to dumb mains for plugins
15:37:55 <salv-orlando> amotoki: well, the thing is that eventually everything will go out of tree. And vendor agent should be out of tree by the end of htis release cycle
15:38:06 <ihrachyshka> for reference, list of plugins switching: https://review.openstack.org/155412
15:38:10 <armax> ihrachyshka: right, but I would personally leave it to the plugin maintainer to take any action on this regard
15:38:12 <salv-orlando> so I guess it probably does not matter if we don't worry at all about patching them or not
15:38:46 <markmcclain> so ihrachyshka could we roll them into one file?
15:38:46 <ihrachyshka> armax, leaving them with potential regressions introduced instead of handling patching uniformly? I don't think it's a great idea.
15:38:53 <armax> ihrachyshka: if and when they observe the issue, they’ll have to follow the practice we’re putting in place to avoid the eventlet snafus
15:39:12 <ihrachyshka> markmcclain, you mean, having single py file with multiple dumb main()s?
15:39:21 <markmcclain> ihrachyshka: yes
15:39:35 <markmcclain> basically have the dummy import the plugin module and then exec the main
15:39:40 <ihrachyshka> salv-orlando, afaik we give them chance to stay till Liberty
15:39:48 <ihrachyshka> markmcclain, that means lots of unneeded imports
15:39:52 <mestery> ihrachyshka: That's right, they have until Liberty
15:39:56 <markmcclain> ihrachyshka: not really
15:40:03 <markmcclain> the import would be inside of the dummy main
15:40:08 <armax> markmcclain: I don’t like the idea, it’s an overkill IMO
15:40:13 <markmcclain> so only exec would the import actually occur
15:40:19 <salv-orlando> ihrachyshka: might be. but they should enter the deprecation path, which is irreverisible afaict
15:40:27 <ihrachyshka> ok, that's an option. not sure whether we'll need to tweak pep8 for that, but sounds good to me
15:40:38 <markmcclain> ihrachyshka: pep8 should allow it
15:40:49 <ihrachyshka> I'm with armax on this, but really anything works for me
15:41:03 <salv-orlando> single file it might be ok for me... what's the advantage over multiple files (beyond having all the mains in one place)
15:41:05 <armax> ihrachyshka: I would worry about what we can right now…which is the basic stuff
15:41:36 <armax> ihrachyshka: lb, ovs agents, l3, dhcp, meta and server
15:41:56 <markmcclain> it's more all of the boilerplate files added in 155412
15:42:04 <armax> ihrachyshka: once we have line of action is clear, we can recommend through devref what needs to be done for eventlet
15:42:13 <armax> and people who care need to follow suit
15:42:14 * dougwig groggily approaches his keyboard...
15:43:02 <ihrachyshka> armax, sure, I'll make a note in my todo to update devref
15:43:29 <armax> so I don’t think that https://review.openstack.org/#/c/155412/ is needed, and I fear it messes us with the decomp efforts
15:43:36 <ihrachyshka> so, what's the end result of this? we're ok with the patches, right? should I merge mains?
15:44:03 <markmcclain> I'm fine with the chain of patches up until '412
15:44:19 <ihrachyshka> armax, well, in theory if we want to go threading route, we'll need to set unit tests running without monkey patching to check how we deal without it
15:44:41 <ihrachyshka> armax, and then having eventlet.monkey_patch() isolated (and avoided in that test run) would be a good thing
15:45:11 <markmcclain> ihrachyshka: if we're doing things right.. our unit tests shouldn't need eventlet
15:45:18 <markmcclain> and it should be transparent
15:45:25 <marun> that's a pretty big 'if'
15:45:31 <dougwig> you're right, BUT...
15:45:46 <ihrachyshka> markmcclain, I think until we run services with eventlet in production, we want patched run to be the default
15:45:49 <amotoki> we have seeveral unit tests which uses eventlet threads
15:45:58 <markmcclain> right well the ones that need eventlet are functional tests and we should ID them for moving in L
15:45:59 <salv-orlando> markmcclain: the unit tests which started a task manager based on eventlet are not there anymore ;)
15:46:46 <ihrachyshka> ideally, I would have monkey_patch() call in just two places - for services and for tests.
15:46:54 <ihrachyshka> and then introduce a switch to disable it for the latter
15:47:03 <ihrachyshka> and be able to get results for unpatched mode
15:47:10 <salv-orlando> anyway, to amotoki's point there is still code in neutron server and agents which explicitly uses eventlet, and it's covered by unit tests. For instance the threadpool started in the l3 agent
15:47:11 <marun> ihrachyshka: I think our unit tests are bad enough that removing the requirement for eventlet is going to be an uphill battle.  But they *shouldn't* need to be patched if they were sane.
15:47:21 <ihrachyshka> with calls spread thru the code base, and tests importing the code, we don't have an easy way to achieve this
15:47:39 <salv-orlando> marun: that's point I made on the mailing list, agree with that
15:47:46 <ihrachyshka> ...uphill battle... sounds like smth I need to get involved
15:48:34 <markmcclain> the good thing is that we don't have to fix them today, but at least collectively decide as a team that is where we want to be at the end of L or M
15:48:45 <ihrachyshka> ok, what's the plan for plugins? dropping the patch and leaving them explicitly patch themselves?
15:49:05 <armax> ihrachyshka: I would be in favor of this
15:49:06 <markmcclain> leave the plugins as is?
15:49:09 <armax> at least for now
15:49:10 <ihrachyshka> I would better stick to uniform approach for everything in the tree, but you decide
15:49:32 <ihrachyshka> ok, I'm in minority, and we'll get back to it once we really consider switching to threads
15:49:36 <dougwig> we're focused on eventlet, but isn't this really a meta-argument about DRY+magic versus explicit coding?  which is always a judgement call, and I have a mild preference for explicit _in this one case_.
15:50:32 <ihrachyshka> dougwig, we don't want to bound ourselves to eventlet, it will die, and we don't want to follow it
15:50:53 <ihrachyshka> so the fewer explicit eventlet/greenthread usages in the tree, the better
15:50:53 <markmcclain> dougwig: very much an argument of explicit vs magic :)
15:50:59 <amotoki> ihrachyshka: i prefre your patch. If they exists in the tree, it is better to do the same way.
15:51:09 <armax> so, ihrachyshka: of the 5 patches that are now targeting bug 1418541, is there anything else to be posted?
15:51:10 <openstack> bug 1418541 in neutron "processutils checks whether stdlib is monkey patched during import" [Undecided,In progress] https://launchpad.net/bugs/1418541 - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
15:51:10 <dougwig> ihrachyshka: right, but i don't think this is discussion is about eventlet at all.
15:51:29 <ihrachyshka> armax, I was going to move wsgi monkey patching under the same umbrella
15:51:58 <armax> so it sounds like there is still something pending?
15:52:24 <ihrachyshka> just one patch. also I will need to understand why some non-entry point files do monkey_patching
15:52:32 <ihrachyshka> like neutron/plugins/ml2/drivers/cisco/apic/apic_topology.py
15:52:37 <ihrachyshka> but that's a separate story
15:52:47 <armax> ok
15:53:15 <mestery> So, approaching the halfway point here, did we reach some consensus on this patch series now?
15:53:52 <armax> my understanding is that of the https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bug/1418541,n,z we need to unblock the top of the chain, and drop the last one
15:54:00 <markmcclain> +1
15:54:04 <mestery> armax: That's what I took from this too.
15:54:09 <armax> then ihrachyshka will complete the work with yet another patch
15:54:14 <ihrachyshka> ok, I'll mark the last one as WIP
15:54:29 <amotoki> as far as I understand, (a) neutron/cmd/eventelet seems reasonable, (b) all patches including vendor agents are okay, (c) apply monkey patch in tests/__init__
15:54:31 <armax> plus a devref one, if he wants to do it separately
15:54:32 <salv-orlando> sounds good to me
15:54:37 <amotoki> am not sure about (c).
15:54:58 <ihrachyshka> amotoki, I guess (b) was not the case?...
15:54:59 <amotoki> is my understanding on (b) correct?
15:55:09 <ihrachyshka> people are against it
15:55:17 <ihrachyshka> hence WIP for the patch
15:55:20 <ihrachyshka> right?
15:55:36 <mestery> ihrachyshka: Right, that's what I understood
15:55:40 <armax> amotoki: I think the suggestion was to leave them for now and have the agents follow the practice explicitely should they see the isuse
15:55:42 <armax> issue
15:55:56 <armax> we’re seeing with the reference elements
15:56:07 <salv-orlando> we can  argue whether patch tests/__init__.py in a separate discussion - to happen on gerrit which is the right place for them
15:56:17 <armax> salv-orlando: agreed
15:56:24 <ihrachyshka> ack
15:56:27 <salv-orlando> unless you think that going to gerrit means automatically getting blocked on a -2
15:56:38 <salv-orlando> but that's not the case I believe
15:56:52 <mestery> Right, lets discuss on gerrit for that one
15:56:55 <mestery> Shall we move on to patch #2 now?
15:57:02 <salv-orlando> yes for me
15:57:15 <amotoki> let's go
15:57:16 <armax> mestery: yup
15:57:18 <ihrachyshka> sure
15:57:18 <markmcclain> I've added my +2 for most of the series now that we have a plan
15:57:22 <mestery> #link https://review.openstack.org/#/c/148318/
15:57:24 <mestery> markmcclain: Thanks!
15:57:26 <ihrachyshka> markmcclain, thanks!
15:57:31 <mestery> Next patch is the CLI extension for neutronclient
15:57:50 <armax> roaet: you there?
15:57:52 <roaet> Aye
15:58:11 <salv-orlando> I've read the comments in the review. I kind of agree with the statement on openstack client, but...
15:58:32 <salv-orlando> my question is: if we add this feature in neutronclient now, are we making it worse? are we causing any harm?
15:58:37 <salv-orlando> or wasting our time?
15:58:51 <armax> I think none of the above
15:58:54 <dougwig> i have one question.  which client/CLI will be documented here: http://docs.openstack.org/kilo/install-guide/install/apt/content/ ?
15:58:54 <markmcclain> salv-orlando: well teh neutronclient is already a steaming pile
15:58:55 <mestery> I don't know how htis could make it worse or cause harm.
15:59:00 <roaet> I don't believe that there is harm, and we'll probably be saving time as there are already people planning to add things to it.
15:59:25 <mestery> dougwig: That link doesn't work for me, so the answer is none.
15:59:34 <dougwig> i did say "will be".  :)
15:59:45 <armax> it sounds to me that at none of the recent summits we ever talked _seriously_ about the client
16:00:01 <mestery> dougwig: Is the openstackclient ready to take on the work of python-neutronclient in Kilo? If the answer is no, then it's python-neutronclient.
16:00:07 <markmcclain> armax: we had full session in Paris with dtroyer
16:00:10 <marun> I don't think we can afford to block ourselves on somedays.
16:00:18 <mestery> marun: ++
16:00:20 <armax> markmcclain: about the neutron client?
16:00:26 <dougwig> that's what i'm asking.  we've heard "they're ready" from both sides.  which his going to be in the official docs?
16:00:27 <markmcclain> yes
16:00:36 <dougwig> /his/is/
16:01:01 <markmcclain> dougwig: prob have to ping annegent_ or another member of her team and see what their plans are
16:01:02 * armax wonder what was the outcome of that
16:01:21 <salv-orlando> so markmcclain if I get your point right you'd rather see roaet's work to land directly on openstackclient?
16:01:24 <markmcclain> armax: the outcome of the session was that we'd be putting resources on the openstack client
16:01:28 <markmcclain> salv-orlando: yes
16:01:41 <salv-orlando> roaet: have you considered that option?
16:01:41 <armax> markmcclain: ah, ok, so the usual wishful thinking but nothing serious :)
16:01:45 <marun> markmcclain: so why is this the first time this is coming to everyone's attention?
16:01:50 <roaet> But there are providers whose users still use neutronclient
16:01:52 <mestery> So, what I'm hearing is, the openstackclient is ready to deprecate python-neutronclient in Kilo?
16:01:53 <mestery> How did I miss this until this moment?
16:01:57 <marun> markmcclain: If this is a priority, where is it on the list of our priorities for this cycle?
16:02:02 <amotoki> i think we agreed that python sdk improvement should be done in openstacksdk and gradually migrate to openstack-cli.
16:02:02 <roaet> salv-orlando: aye, it is not feasible to release at the moment.
16:02:17 <amotoki> but we didn't decide we deprecate neutronclient in kilo.
16:02:18 <salv-orlando> well to roaet point I have to agree that we've not eol-ed python-neutronclient yet, nor freezed it
16:02:19 <marun> markmcclain: nothing about what your telling us suggests that it is going to happen this cycle.
16:02:24 <dougwig> is this, openstackclient is the client for kilo, and let's not waste time?  or was it, let's do this, like putting py33 as a default env in tox, and hope for unicorns?
16:02:31 <marun> markmcclain: and that doesn't suggest that we should block legitimate enhancements.
16:02:41 <mestery> I'm hear to say that I am not deprecating python-neutronclient in Kilo
16:02:43 <salv-orlando> I'm speaking from a user expectation perspective. I know it's a pile of <put your denigrative substantive here>
16:03:09 <mestery> Because honestly, this is the first I'm hearing of "the openstackclient is ready to deprecate the other clients"
16:03:15 <mestery> How can we deprecate it at this point in kilo?
16:03:20 <dougwig> mestery: +1
16:03:27 <mestery> So, lets move past that argument
16:03:32 <markmcclain> we can collectively decide to announce it's deprecation
16:03:36 <mestery> python-neutronclient will be around for Kilo
16:03:43 <mestery> Right, but it will be there for Kilo
16:03:47 <marun> markmcclain: it's definitely too late for this cycle though.
16:03:50 <markmcclain> deprecation doesn't mean we're killing the code today
16:03:52 <marun> markmcclain: maybe for lemming
16:04:18 <markmcclain> it's never too late
16:04:24 <amotoki> does anyone check the status of openstack client support stauts of neturon?
16:04:32 <markmcclain> deprecation just signals we're done making substantial changes to it
16:04:33 <armax> so I am still unclear as to what the openstack client is and is not
16:04:36 <salv-orlando> I have unfortunately no idea atm on whether we can replace our client with openstackclient. If anyone can share some info on that it might be useful. It seems that this is indeed the gist of the discussion.
16:04:37 <marun> markmcclain: I think you'll have to make a better case than I've heard thus far.
16:04:41 <armax> isn’t it just a proxy for the other clients?
16:04:44 <mestery> http://youtu.be/lL2ZwXj1tXM
16:04:47 <roaet> From my understanding and from the docs, it does what the python clients do.
16:04:52 <mestery> :)
16:04:54 <armax> and the other clients need to uniform so that the life of the proxy is easy?
16:05:52 <mestery> armax: That's what I thought it was
16:05:55 <armax> if my understanding is correct, I am not sure we can ever talk of deprecating the neutronclient
16:06:00 <armax> or any other client for that matter
16:06:01 <dougwig> there are separate sdk and cli packages, the cli is further along, and i'm guessing that the plan is to have the cli use the sdk when it's ready?
16:06:14 <roaet> From my conversations with the SDK team the OSC will consume the SDK when it's ready
16:06:18 <markmcclain> dougwig: maybe.. wish dean was online for that bit
16:06:26 <amotoki> armax: yes. openstackclient calls python-*client libraries in general. it is just a replacement of CLI
16:06:29 <roaet> but the SDK team has admitted to not being ready
16:06:45 <mestery> roaet: Yes, in the review no less
16:06:46 <briancurtin> ^that's the plan - OSC is currently on *clients, ideally is backed by SDK
16:06:55 <salv-orlando> I have to admit this thing about proxying has always baffled me. It was my impression too, but then dtroyer in Paris said it was self-sufficient. so yes, I'm a bit confused
16:07:38 <armax> just because of that confusion I don’t think we can warrant the stoppage of any feature development on the client
16:07:43 <annegent_> and from a docs perspective, we are interested in switching to openstack CLI
16:07:58 <annegent_> install one instead of many
16:08:03 <mestery> Can anyone confirm if openstack CLI is just proxying existing clients as armax has suggested then?
16:08:07 <roaet> Assuming OSC was self-sufficient, does that mean we should still abandon providers whose users require neutronclient.
16:08:11 <dougwig> annegent_: what's the timing on that change?
16:08:11 <mestery> If so, then isn't this discussion moot at this point?
16:08:19 <salv-orlando> armax: I think if we insist in python-neutronclient vs openstackclient we won't agree on anything
16:08:21 <amotoki> mestery:  *client has both CLI and libs and OSC consumes libs from *client.
16:08:24 <mestery> roaet: We'd have a deprecation process
16:08:31 <markmcclain> so the OSC has it's own command structure
16:08:41 <markmcclain> but is using teh http client form our backend
16:08:42 <annegent_> dougwig: we're concerned about Keystone v3 and nova not supporting domains, but that shouldn't prevent us from documenting openstack CLI, just where it's documented
16:08:50 <marun> mestery: I'm not sure how it could do otherwise.  It would be quite an effort to recreate the client, as steaming a pile as it might be.
16:08:51 <salv-orlando> I think the right question to ask is whether adding features to python-neutronclient is a bad idea or not.
16:08:54 <roaet> mestery: Aye. We are not prepared to immediately deprecate neutronclient.
16:09:01 <dougwig> annegent_: are you planning that switch in K, L, ?
16:09:08 <markmcclain> salv-orlando: that is the real question
16:09:39 <annegent_> dougwig: discussing for K
16:09:47 <salv-orlando> markmcclain: I think it depends on the criticality of the feature. Of which I am unsure. But then roaet can add something on this.
16:10:00 <armax> salv-orlando: correct, my take is, until we have a crystal clear clarity on the matter I don’t think we can afford stopping work from happening, especially if the work is ready to go in
16:10:18 <armax> and to me the sticking point here is the service-split
16:10:44 <roaet> Given our users' dependency on the client, to us it is critical for providing features they demand.
16:10:54 <markmcclain> armax: this work is not ready to go it
16:11:08 <dougwig> markmcclain: it'll never get there with a -2.
16:11:10 <amotoki> i don't think it can be deprecated in K, and exnteison mechanism helps services implement their commands.
16:11:12 <markmcclain> armax: there are techical changes required
16:11:35 <armax> markmcclain: agreed, but it would be nice once it is, that the adv services side of the client would follow the same structure
16:11:37 <mestery> amotoki: Right, we are not deprecating the client in Kilo, though it sounds like we can do that in Liberty.
16:12:03 <amotoki> mestery: agree for L.
16:12:09 <armax> so that the adv service folks can innovate on the client side at the same speed they can do on the server side
16:12:17 <marun> markmcclain: the issue is 'can it go in once ready', not 'in its current form'
16:12:18 <markmcclain> armax: well that's another reason to put the impetus behind the OSC
16:12:20 <armax> markmcclain: or at least this is mine of whishful thinking
16:12:29 <roaet> I believe we can live with deprecation in L.
16:12:35 <mestery> roaet: Excellent!
16:12:36 <markmcclain> until we contrib resources towards it will never be there
16:12:42 <marun> markmcclain: the +2's on the patch were more an indication of dissent around your view that it shouldn't go forward at all
16:12:43 <armax> markmcclain: right, but we gotta be realistic that the split is well under way, whereas OSC is nowhere near
16:12:43 <salv-orlando> I think the only problem with roaet's work is that it should have been available 2 years ago
16:12:44 <mestery> roaet: Because that means it will be there in L, and removed in M
16:12:57 <roaet> salv-orlando: It took me 6 months to get a 1 line change into the client.
16:12:58 <mestery> salv-orlando: lol
16:13:04 <armax> markmcclain: so to me roaet’s efforts sound like a good compromise, or bridge-solution
16:13:10 <mestery> roaet: How did you get that merged so quickly? ;)
16:13:13 <roaet> mestery: hahaha
16:13:22 * mestery beat salv-orlando to the punch there
16:13:41 <dougwig> mestery: way to pour salt in the wounds, there.  :)
16:14:02 <mestery> dougwig: I recently attended sensitivity training, can you tell? :D
16:14:02 <roaet> mestery: with extensibility added to the client even if we cannot handle deprecation, we can at least bridge the gap between missing features.
16:14:10 <mestery> roaet: Makes sense
16:14:29 <salv-orlando> seriously, my opinion is that unless there are technical flaws it is a feature that should be in the client if we're planning to use it at least for 6 more months.
16:14:40 <marun> +1
16:14:43 <mestery> +1
16:14:46 <dougwig> +1
16:14:52 <amotoki> +1
16:14:54 <salv-orlando> and for technical flaws I end to trust my peers who +2'ed the patch...
16:15:03 <mestery> +1
16:15:13 <salv-orlando> but since another very respected peer -2'ed and is claiming technical flaws we might better discuss those
16:15:13 <markmcclain> it re-implements entrypoints
16:15:21 <marun> salv-orlando: I think there are things that need to be fixed in the patch, as per markmcclain's most recent comment
16:15:37 <armax> +1
16:15:37 <mestery> marun: Right!
16:15:38 <marun> salv-orlando: but once those are fixed it should be mergeale
16:15:39 <dougwig> that's -1 worth for sure, let's get it fixed.
16:15:40 <roaet> markmcclain and amotoki have brought up technical issues, I will gladly fix.
16:15:41 <marun> mergeable
16:15:43 <salv-orlando> and stop talkign python-neutronclient vs openstackclient. That discussion is not useful for this release cycle.
16:15:52 <mestery> roaet: Awesome!
16:15:57 <mestery> salv-orlando: The voice of reason
16:16:00 <mestery> ;)
16:16:09 <amotoki> we are discussng two things: client lib and CLI. I am not sure which migration should happen first.
16:16:16 <markmcclain> so fixing the technical issues is fine, but the bigger issue that we'll never get off our crappy client
16:16:27 <salv-orlando> mestery: If I could speak reason without typos it would be even better ;)
16:16:28 <markmcclain> until we as a team work better with the SDK/OSC folks
16:16:30 <amotoki> at least regarding on service split, we have client lib implementation as an extension and it makes the migration  easier
16:16:53 <mestery> markmcclain: In parallel, I think we can start doing better on that front for sure. Certainly we'll all agree to that I think.
16:16:53 <roaet> markmcclain: I have been speaking to my product folks to prioritize support into SDK
16:16:57 <salv-orlando> markmcclain: so your vote is to deprecate client in Kilo and move this work to the openstackclient?
16:17:00 <markmcclain> roaet: awesome
16:17:05 <roaet> markmcclain: that should hopefully give a lot more resources from rax.
16:17:06 <briancurtin> markmcclain: i'm going to write up some status on SDK+OSC so this whole story is a bit more clear
16:17:09 <dougwig> markmcclain: that argues for a transition plan, not a full stop.
16:17:18 <markmcclain> yeah.. I'd be ok making this the last bigger feature we put in our client :)
16:17:25 <salv-orlando> briancurtin: yes, this will help a lot lazy people like me
16:17:49 <mestery> salv-orlando: Not deprecate in Kilo, but in Liberty.
16:17:55 <markmcclain> dougwig: transition plan is a perfect outcome here
16:18:04 <salv-orlando> markmcclain, roaet, mestery: it seems we're starting to see a consensus then. We can address technical comments, merge this feature.
16:18:09 <roaet> markmcclain: mestery: with a deprecation schedule we can assess the risks and appropriate resources to make the transition
16:18:11 <salv-orlando> And then freeze python-neutronclient
16:18:17 <marun> markmcclain: agreed that we need to focus attention on it.
16:18:22 <mestery> ++
16:18:23 <markmcclain> mestery: I think we can announce the lib as deprecated at the kilo release and say it will be supported for at least 12mos
16:18:31 <marun> markmcclain: it needs to be identified as a priority and have resources dedicated to it
16:18:44 <mestery> markmcclain: I'm fine with that to be honest, but lets make that call near Kilo-3.
16:18:48 <marun> markmcclain: we should make sure to talk about that in vancouver
16:18:52 <mestery> marun: ++
16:18:54 <mestery> Resources are key
16:19:15 <mestery> Excellent!
16:19:17 <amotoki> markmcclain: agreed. at least we need to annoucen to dev community.
16:19:22 <mestery> I think we have a way forward.
16:19:26 <mestery> And with 10 minutes left even! ;)
16:19:30 <armax> and with 10 minutes to spare :)
16:19:33 <mestery> Anything else on the client to discuss?
16:19:39 <roaet> did dougwig have something?
16:19:45 <marun> I'm not really clear on setting a deprecation schedule ahead of having resources to do the work...
16:20:11 <dougwig> roaet: not on the client. i think we're good there.
16:20:12 <mestery> marun: We'll reevaluate deprecation near Kilo-3, we're not saying it will be deprecated in Kilo at this point. Fair enough?
16:20:55 <marun> mestery: fair enough
16:21:00 <roaet> markmcclain: offline I would appreciate technical direction for how you'd want me to replace the entrypoint things
16:21:04 <mestery> OK
16:21:07 <mestery> #topic Open Discussion
16:21:08 <roaet> amotoki: same.
16:21:10 <mestery> 9 minutes left folks
16:21:15 <mestery> Anything else today?
16:21:30 <dougwig> drivers (and others), I'd appreciate any early feedback on this spec: https://review.openstack.org/#/c/154736/
16:21:31 <markmcclain> roaet: sure.. will follow up with email later today
16:21:34 <dougwig> splitting a lib out of neutron.
16:21:40 <roaet> markmcclain: thanks
16:21:44 <dougwig> the current state of affairs is... painful.
16:22:14 <markmcclain> dougwig: painful is too nice of a word
16:22:19 <salv-orlando> dougwig: bottom line for me is that it is really painful to have a dependency on something which is not stable at all.
16:22:25 <mestery> lol
16:22:34 <salv-orlando> on the other hand I suspect this task is far from being simple
16:22:41 <marun> dougwig: I'll comment on the review, but my concern is that stable interfaces and separating things out don't necessarily need to be conflated.
16:22:56 <salv-orlando> one risk that I see is that we'll just push the problem from neutron to neutron-lib
16:23:01 <marun> +1
16:23:04 <salv-orlando> making neutron development painful as well
16:23:11 <marun> well, that's the point
16:23:13 <dougwig> kyle wanted to wait for the summit, but if there's any chance that I can get a hint at if that's the right direction, I can start doing some of the early work.  if it's a 90 degree tangent, then I don't want to waste my time.
16:23:15 <salv-orlando> but at least we'll share the pain ;)
16:23:18 <marun> salv-orlando: so that we have skin in the game too
16:23:21 <marun> yeah
16:23:39 <dougwig> marun: it can't be a mindless split, which is why we can't do it in one-step.  agree.
16:23:41 <marun> dougwig: I don't think it's a tangent, something needs to be done.
16:23:49 <marun> dougwig: I think focusing on stable interfaces as the goal is important.
16:23:55 <marun> dougwig: if splitting things out aid in that, yay.
16:24:01 <marun> dougwig: if not, well...
16:24:15 <dougwig> every piece that's moved is going to have to be evaluated with, "is this a library module?  does it need new tests?"
16:24:34 <marun> dougwig: we can as easily separate things in the tree
16:24:55 <dougwig> not and put the results in pypi, so requirements.txt can be sane.
16:24:57 <marun> dougwig: we discussed that early in the cycle and got worn down by what the wsgi refactor might imply
16:25:34 <dougwig> separate repos means that in one we can say, "thou shalt not break method signatures", and in the other, "refactor, go nuts."
16:25:45 <marun> dougwig: I don't think that's enough.
16:25:53 <marun> dougwig: the only way that would work would be with co-gating.
16:26:05 <marun> dougwig: but i digress... let's discuss offline and in gerrit
16:26:17 <dougwig> ok, i'll find you later today.
16:26:22 <marun> dougwig: sounds good
16:26:28 <markmcclain> I think we might have to wait because if we discuss spining out the ref impl into a separate project it radically changes things
16:26:49 <marun> markmcclain: that suggests we wait on the split, and I'm ok with that
16:27:04 <marun> markmcclain: I don't think we need to avoid working on interface stability for things that are used out of tree, though.
16:27:32 <dougwig> if we agree in concept, and the first step is easy stuff like base exceptions, that let's us get through the weeks of paperwork to do things like the new repo, jenkins, etc...  that's the part that might be fast-trackable.
16:27:40 <mestery> markmcclain: The discussion of the spinning out of ref implementation needs to happen in Vancouver for sure
16:27:51 <mestery> dougwig: ++
16:28:06 <markmcclain> dougwig: should be fairly easy once we get direction on librarization
16:28:29 <markmcclain> maybe back burner this until K3 deadline passes?
16:28:34 <markmcclain> it's really not that long of a wait
16:28:56 <mestery> markmcclain: I'm fine with tabling it a bit, though I encourage folks to comment on the review as well, keeping in mind it's WIP
16:29:06 <dougwig> as long as we keep talking about this.  that infra stuff has a tendency to take awhile, even when easy.
16:29:07 <markmcclain> yeah.. comments are good on it
16:29:28 <mestery> Cool.
16:29:31 <roaet> Are we at time? I had one more tiny thing to add about the client. <_<   >_>
16:29:33 <mestery> OK, we're at time now in a bit
16:29:43 <mestery> roaet: Lets move it to #openstack-neutron since we're at the end, ok?
16:29:47 <roaet> mestery: ok
16:29:51 <roaet> thank you all
16:29:52 <mestery> Thanks to all for joining!
16:29:53 <mestery> Good discussion
16:30:05 <mestery> #endmeeting