18:01:09 <dstanek> #startmeeting keystone 18:01:10 <openstack> Meeting started Tue Sep 8 18:01:09 2015 UTC and is due to finish in 60 minutes. The chair is dstanek. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:14 <openstack> The meeting name has been set to 'keystone' 18:01:24 <dstanek> woot! 18:01:26 <dstanek> #topic Keystoneclient v2 branch 18:01:26 <bknudson> hi 18:01:35 <dstanek> jamielennox you around? 18:01:39 <stevemar> bknudson: hi 18:02:28 <claudiub> o/ 18:02:32 <dstanek> if not we can skip and defer until later... 18:02:37 <stevemar> dstanek: defer? 18:02:52 <dstanek> stevemar: whatever jamie wanted to discuss 18:02:58 <bknudson> we can't make big breaks. 18:03:02 <ayoung_> dstanek, he might still be waking up 18:03:15 <dstanek> ayoung_: yeah, i figured 18:03:17 <topol> o/ 18:03:23 <stevemar> just bump it to the end of the agenda 18:03:26 <ayoung_> ++ 18:03:34 <bknudson> circle back 18:03:55 <dstanek> #topic Changing driver version numbers....looking for guidance on how this should work? 18:04:01 <dstanek> henrynash! 18:04:10 <henrynash> ok, so dstanek and I started to chat about this 18:04:31 <henrynash> First…wasn’t celar to me if the driver versions are now released/frozen? 18:04:50 <henrynash> (I have this bug fix that wants to add three new driver methods) 18:05:11 <bknudson> I think they're frozen. 18:05:18 <bknudson> at feature freeze 18:05:31 <gyee> didn't he have FFE? 18:05:45 <hogepodge> o/ 18:05:58 <henrynash> gyee: this is for a bug fix, not a new bp 18:06:19 <dstanek> so does that mean that this particular bug needs to wait until M and can't be merged into L without a FFE? 18:06:27 <amakarov> henrynash, can you give a link please? 18:06:59 <henrynash> https://review.openstack.org/#/c/191976/ 18:07:05 <gyee> henrynash, so these methods can't be implemented in the compatibility layer? 18:07:26 <henrynash> gyee: so, no….but that raises a second question 18:08:03 <henrynash> gyee: in our developing_drivers.rst we say that we will add naive implementaions to the “old driver” 18:08:31 <henrynash> gyee: which actually wasn’t what I was expecting….but that’s what I followed in teh patch I have submitted 18:08:45 <dstanek> henrynash: so here's how i was picturing this 18:09:36 <dstanek> we release L on V8 versions of drivers and M on V9. if things are added to V9 then they have to be added to V8 (via a method in core.py so a driver implementer is not required to do anything) 18:09:51 <dstanek> some people have differing ideas on when to version 18:10:17 <gyee> so anything you need at the atomic level, should be provided by the old drivers by now, and any optimization that the old drivers doesn't have at the moment should be implementd at the naive layer. 18:10:22 <dstanek> i like per release because it's really easy to know what the current and supported versions actually are 18:10:45 <henrynash> dstanek: I also like per release or I think we’ll all get confused 18:11:08 <gyee> same argument apply to, say, adding a param to the public API in order to fix a bug 18:11:24 <dstanek> henrynash: yes, v8 or identity, v10 of assignments, etc... yes, can get very confusing 18:11:46 <henrynash> gyee, dstanek: so since I need a new sql table, looks like I can’t fix this in M 18:11:50 <henrynash> sorry, I mean L 18:11:52 <dstanek> we should treat driver API changes like we to REST API changes now. so i'm assuming that means FFE at this point? 18:12:02 <gyee> dstanek, ++ 18:12:33 * morgan is lurking. 18:12:51 <morgan> Yes i would say ffe or similar 18:12:51 * bknudson also lurks 18:12:55 * stevemar kicks out lurkers 18:13:09 * gyee high fives stevemar 18:13:26 <lbragstad> so all interfaces are locked down after milestone 3? 18:13:43 <henrynash> dtsanek: and when we do add a new version, as you said on IRC…we add this to the same driver file…but how do we use config to load the right driver? 18:13:44 <stevemar> unless they have an FFE 18:14:18 <henrynash> stevemar: would we allow an FFE that chanegd the interfaces? 18:14:38 <bknudson> if it's not changing interfaces is it a feature? 18:15:28 <dstanek> so i think FFE unless there are other thoughts here... 18:15:29 <bknudson> I guess a new backend would be considered a feature. 18:16:00 <stevemar> henrynash: i would think so 18:16:14 <gyee> but a feature doesn't mean it must change the interface 18:16:20 <dstanek> bknudson: yeah, and we could do other things that add features using config, etc. 18:16:22 <morgan> dstanek: that would be my choice 18:16:36 <dstanek> ok, i want to keep us moving 18:16:55 <henrynash> bknudson, stevemar, dtsanek: I imagined teh need for an FFE is just since we are landing code late taht is dangerous…if we are serious about supporting driver writers, I think we have to lock the interface at L3 18:17:39 <gyee> henrynash, how about locking all interfaces by L2, both API and driver 18:17:50 <dstanek> henrynash: i say yes for now. we have to start the process sometime and in the future i think this will matter more and more 18:17:56 <stevemar> lock all *existing* interfaces 18:17:58 <gyee> if we are treating driver interfaces like public APIs 18:18:01 <stevemar> not new ones 18:18:29 <henrynash> gyee: I think L2 is too restrictive (now that we are saying we’l support teh old version for a full release)... 18:18:38 <dstanek> #agreed we have frozen the v8 driver APIs as of L3 and require a FFE to make changes to them 18:18:39 <topol> can we document somewhere that driver interfaces are analogous to public APIs/ 18:18:54 <topol> if thats the way we go 18:19:07 <dstanek> #action dstanek to follow up in the l2 vs l3 debate and write it in the docs 18:19:14 <gyee> sure, I agree 18:19:14 <stevemar> topol: we started to doc this 18:19:25 <henrynash> dstanek: ….and i think we need a very good reason to allow an FFE that changes them 18:19:26 <bknudson> I missed V1-7. 18:19:27 <stevemar> topol: http://docs.openstack.org/developer/keystone/developing_drivers.html 18:19:30 <topol> stevemar awesome 18:19:36 <stevemar> bknudson: we all did :( 18:19:39 <henrynash> bknduson: they were great! 18:19:59 <dstanek> bknudson: we let versioning slide! it was actually V* 18:20:00 <stevemar> v1-v7 had no issues! 18:20:02 <dstanek> #topic keystonemiddleware tests broken by keystoneclient release 18:20:06 <henrynash> ok, I’ll change with dstanek after on my otehr quetsions on versions 18:20:10 <dstanek> #link https://bugs.launchpad.net/python-keystoneclient/+bug/1492600 (bug assigned to davechen) 18:20:12 <openstack> Launchpad bug 1492600 in python-keystoneclient "Session._send_request(...) doesnt catch the exception properly" [Critical,In progress] - Assigned to Dave Chen (wei-d-chen) 18:20:14 <henrynash> (I’ll chat wth) 18:20:16 <bknudson> anybody have time to look at this? 18:20:16 <topol> stevemar so it just needs to be updated with our stated direction then 18:20:19 <dstanek> #link http://logs.openstack.org/13/208213/2/check/gate-keystonemiddleware-python27/3e14ede/console.html.gz#_2015-09-04_17_56_39_631 18:20:24 <dstanek> #link https://review.openstack.org/#/c/220736/ Proposed change to ksc 18:20:27 <bknudson> otherwise it'll be my top priority after I get some other work done. 18:20:34 <stevemar> topol: yep, sounds like something for you to do :P 18:20:40 <stevemar> *delegate up!* 18:20:40 <bknudson> ksm is blocked currently 18:20:45 <bknudson> might be something I broke. 18:20:46 <topol> stevemar, cool 18:21:05 <dstanek> bknudson: is this the deprecation stuff? 18:21:08 <ayoung_> #action blk-u fix KC 18:21:08 <bknudson> that was it. 18:21:18 * topol stevemar always throws me bones :-) 18:21:20 <gyee> bknudson, link? which review is broken? 18:21:24 <bknudson> I don't know. I haven't looked at it. 18:21:45 <gyee> nm 18:22:04 <bknudson> all recent keystonemiddleware changes are failing 18:22:11 <bknudson> since the keystoneclient release. 18:22:39 <ayoung_> raildo, don't -1 something that is a rollback...lets get it fixed, and investigate underlying cause second 18:22:45 <gyee> ohhh! not exception mapping again 18:22:58 <ayoung_> dstanek, bknudson do we need https://review.openstack.org/#/c/220736/2 to unblock? 18:23:07 <gyee> we went through that once 18:23:25 <bknudson> ayoung_: I haven't looked at it enough to know if https://review.openstack.org/#/c/220736/2 is the fix. 18:23:33 <ayoung_> k 18:23:34 <raildo> ayoung_: ok :) 18:23:54 <gyee> I don't like that fix 18:24:09 <gyee> catching ConnectionError twice 18:24:20 <ayoung_> since it makes it through check, does that mean it fixes the issue? 18:24:31 <bknudson> if that change is necessary then we've made a backwards-incompatible change 18:24:37 <dstanek> gyee: two different exceptions though 18:24:39 <bknudson> so we should revert the change if we can figure out which one it is. 18:24:54 <stevemar> we will also need a ksc release 18:25:14 <dstanek> bknudson: is this something that you have time for? or are you looking for someone to step up? 18:25:18 <gyee> dstanek, I bet we mapped the ConnectionError somewhere 18:25:28 <gyee> redefined 18:25:43 <bknudson> dstanek: I'll have time, but it won't be until tomorrow at the earliest. 18:25:54 * stevemar didn't realize we releases a new ksc version yesterday.... 18:26:10 <stevemar> where was the ML announcement on that one 18:26:10 <dstanek> gyee: if it were the same class, just "redefined" through imports it would be fine. this would appear to be a while new exception 18:26:21 <stevemar> err.. on friday 18:26:37 <bknudson> who does releases on friday before labor day? 18:26:50 <morgan> bknudson: sorry :( 18:27:04 <stevemar> it was anti-morgan, the evil one 18:27:06 <morgan> It was supposed to go out on ... Uh thursday 18:27:13 <morgan> Or wednesday 18:27:32 <ayoung_> they anti-morgan is the good one 18:27:59 <ayoung_> otherwise my minion-to-evil-overlord contract is null 18:28:02 <lhcheng> agree with bknudson, we should rollback rather than just fixing the tests to pass. 18:28:21 <lhcheng> bknudson: I have some time later in the afternoon, I can start looking at it. 18:28:31 <bknudson> that would be great, thanks lhcheng! 18:28:35 <dstanek> ok! 18:29:20 <dstanek> #action lhcheng to start looking into the ksm issue caused by the ksc release. 18:29:36 <dstanek> #topic python-keystoneclient uses socket attributes that do not exist in Windows 18:29:37 <dstanek> socket.TCP_KEEPCNT and socket.KEEPINTVL do not exist in windows. because of this, the nova-compute service running on Hyper-V is not able to create instances. 18:29:45 <claudiub> o/ 18:29:46 <dstanek> #link https://review.openstack.org/#/c/211686/ proposed partial fix to make creating instances on Hyper-V possible 18:29:56 <stevemar> ugh, who the heck is using windows 18:29:57 <dstanek> claudiub: all you 18:30:04 <morgan> Ugh. Yah so we should fix that fast and release 18:30:07 <stevemar> oh its claudiub i'll be nice :) 18:30:18 <claudiub> ty. so, we really want this... 18:30:29 <bknudson> if windows is important let's get some ci for it. 18:30:31 <claudiub> we've been hitting this more and more often 18:30:41 <morgan> bknudson: ++ 18:30:52 <claudiub> even in the hyper-v ci 18:31:08 <dstanek> i thought the change was OK based on the docs, but i have not tried to actually use it on windows 18:31:12 <claudiub> and johnthetubaguy had the same problem with os x 18:31:29 <lbragstad> os x 10.10 i believe 18:31:42 <dstanek> really? 18:31:46 <claudiub> yeah, he commented on the patch and the bug report 18:32:10 <stevemar> this fix seems completely reasonable to me 18:32:24 <ayoung_> running the client from Windows seems reasonable. 18:32:25 <bknudson> the bug is Medium importance. 18:32:25 <claudiub> it won't break anything that already exists 18:32:29 <morgan> Os x is not officially supported 18:32:44 <stevemar> morgan: not even for the clients? 18:32:48 <claudiub> it just makes sure it won't die for windows and os x 18:32:49 <bknudson> there's no ci for OS X either. 18:32:55 <stevemar> and this doesn't change existing behaviour 18:32:56 <morgan> Not unless someone ci's it 18:33:19 <morgan> Windows there is ci possible 18:33:51 <dstanek> ok, so we just need people to go look at the review 18:34:12 <lbragstad> amakarov: had some questions on it, but I think they've been answered... 18:34:17 <stevemar> even on L941 we have OS specific handling 18:34:21 <stevemar> this seems like a no-brainer 18:34:24 <ayoung_> he was asking if the CR is incomplete. 18:34:29 <dstanek> sounds like nobody has objections so i'd like to move on 18:34:35 <stevemar> err, not OS-specific, but we have similar checks 18:34:41 <ayoung_> I thin the answer is no; they have a todo but it needs a requests change 18:34:49 <dstanek> it would be nice to get sigmavirus24's opinion in there too if he hasn't already commented 18:34:49 <ayoung_> and it is a "should" not a "must" 18:35:02 <amakarov> lbragstad, ? 18:35:20 <ayoung_> amakarov, care to remove your -1? 18:35:26 <ayoung_> https://review.openstack.org/#/c/211686/7/keystoneclient/session.py 18:35:31 <lbragstad> amakarov: your comment here - https://review.openstack.org/#/c/211686/ 18:36:06 <amakarov> lbragstad, aha, I see it 18:36:38 <sigmavirus24> dstanek: sorry waht's up? 18:36:39 <amakarov> My question is answered indeed? thank you 18:36:50 <amakarov> s/?/,/ 18:36:50 <claudiub> ok, so I only have to change the TODO to a NOTE? 18:36:57 <dstanek> sigmavirus24: we're talking about https://review.openstack.org/#/c/211686 18:37:33 <sigmavirus24> Yeah that's a reasonable review 18:37:41 <sigmavirus24> I still need to find time to add ioctl support to urllib3 18:37:42 <dstanek> claudiub: i also agree with jamie's comment about the link 18:37:51 <sigmavirus24> but that's something the author and I are in agreement about adding 18:37:56 <sigmavirus24> Just a matter of me finding time to do it how we discussed 18:38:21 <dstanek> sigmavirus24: do you have an issue already created for it or would you like us to do it? 18:38:41 <sigmavirus24> dstanek: we haven't created one yet, but I can create that 18:38:57 <ayoung_> leave as a TODO 18:39:03 <claudiub> k 18:39:09 <ayoung_> it should be done, but can't be until the requests change is n 18:39:12 <ayoung_> is in 18:39:26 <dstanek> claudiub: we should link to the requests issue too 18:39:39 <lbragstad> ++ 18:39:45 <dstanek> ok, so we just need some minor things here including some eyeballs on the review 18:40:01 <stevemar> todo -> note + link to requests 18:40:23 <bknudson> it's even got nice unit tests. 18:40:26 <claudiub> cool, can you paste the link to requests? 18:40:54 <lbragstad> claudiub: that will probably have to wait until the issue it created. 18:41:00 <lbragstad> s/it/is/ 18:41:02 <dstanek> lbragstad: ++ 18:41:06 <dstanek> ok, moving on 18:41:07 <claudiub> also, seems to be mixed opinions on wheter it should be a todo or a note 18:41:14 <claudiub> ok 18:41:18 <claudiub> ty :) 18:41:22 <dstanek> #topic Policies 18:41:23 <dstanek> FFE has been requested? 18:41:23 <bknudson> let's bikeshed it some more. 18:41:27 <dstanek> samueldmq: you.... 18:41:34 <samueldmq> hello everybody :) 18:41:35 <dstanek> claudiub: they can debate in the review :-) 18:41:56 <samueldmq> I basically want to discuss with you the need for FFE vs Postpone on this subject 18:42:19 <samueldmq> all the code in the implementation now is < 600 lines, and need some reviews 18:42:20 <stevemar> lol @ bknudson 18:42:38 <samueldmq> #link Server: https://review.openstack.org/#/c/216851/ 18:42:42 <samueldmq> #link Middleware: https://review.openstack.org/#/c/205049/ 18:42:45 <samueldmq> #link Oslo: https://review.openstack.org/#/c/200257/ 18:43:04 <samueldmq> only the oslo.policy one is needing an update to deal with some lock, etc 18:43:10 <samueldmq> when dealing with files 18:43:32 <samueldmq> + CacheControl support in ksclient, which is something dstanek was looking at 18:43:44 <dstanek> samueldmq: so what is the need for a FFE? 18:44:13 <samueldmq> dstanek, to get it merged this cycle we need a FFE, right ? 18:44:59 <samueldmq> I wanted to know if someone is already for/against it as FFE, and if we go for it, we need some cores to signup for review 18:45:12 <dstanek> samueldmq: no, i mean what's the case for doing it? you have to persuade the voters 18:45:45 <samueldmq> dstanek, k, so .. the feature everyone knows, we have relaxed the implementation which is much more consisntent and simpler for now 18:46:12 <samueldmq> gyee put us in contact with some guys of HP public cloud (stackholders) 18:46:35 <samueldmq> and we checked they won't be able to use it in L even if it's merged, because it'll be experimental 18:46:42 <bknudson> we should always use the term "stackholders" 18:47:08 <samueldmq> however to become stable, everything needs to be experimental previously (right morgan ?) 18:47:27 <samueldmq> so that's my call for opening a FFE on it 18:47:41 <samueldmq> we have stackholders, we have the code, we need eyes on it 18:47:46 <morgan> samueldmq: yes. Experimental first. 18:47:54 <samueldmq> and would like to check whether the core team is for/against it 18:47:57 <gyee> anybody besides me are going to review it? 18:48:10 <dstanek> samueldmq: so you are making the case to wait? since nobody will use it is there a reward? 18:48:47 <samueldmq> dstanek, no.. HP public cloud won't use it before it is stable, but it won't be stable before being experimental 18:49:01 <henrynash> samueldmq: so the argumetn taht we must put it in no simply becuase we think allowing a relase cycle to go by will make it stable is not a good arguemnt 18:49:33 <samueldmq> henrynash, makes sense, because people have to use it to make it stable, not just waiting 18:49:39 <henrynash> if something is good, solid and we really need it, we have said that it is possible to go from experimental to stable in a cycle 18:49:46 <bknudson> we at least give them the opportunity to use it 18:49:55 <dstanek> samueldmq: it also can't be stable until it's done. since we are building up to the real functionality will is be stable anytime soon? 18:49:56 <samueldmq> however I do believe we have other stackholders as well, like good feedbacks we've received in the operators ML 18:50:09 <bknudson> if they don't take advantage and then have complaints later it's their own fault 18:50:14 * lbragstad 10 minutes left 18:50:26 <bknudson> then again, they can cherry-pick the changes and try it that way. 18:50:38 <samueldmq> dstanek, we'll have it all (the delivery) .. the implementation is simpler now 18:50:57 <dstanek> samueldmq: do they want HTTP policy or dynamic policy? 18:51:23 <gyee> dynamic policy, but isn't HTTP a requirement? 18:51:27 <samueldmq> dstanek, fetching is part of all the dynamic stuff 18:51:31 <samueldmq> gyee, ++ 18:51:40 <stevemar> samueldmq: looks like you are changing the response of an API 18:51:58 <samueldmq> stevemar, we include a header: Cache-Control 18:52:05 <samueldmq> stevemar, so yes, we're chaging it 18:52:05 <dstanek> samueldmq: so HTTP policy is experimental now and will be stable in M, dynamic policy would be experimental in M and stable in N? 18:52:17 <gyee> I can do dynamic and have them delivered by a bunch of mice 18:52:22 <henrynash> I thought we agreed we would kill the phrase “dynamic policy”….it is centralised policy….peopl can be really dynamic today with their own cms 18:52:29 <samueldmq> dstanek, the rest of the features in dynamc policies, possibly yes 18:52:34 <samueldmq> henrynash, ++ 18:52:34 <stevemar> samueldmq: not just that, but you add 'freshness' to http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-endpoint-policy.html#get-effective-policy-associated-with-endpoint 18:52:39 <morgan> dstanek: not stable in M 18:52:44 <morgan> Might be stable in M 18:52:49 <lbragstad> henrynash: ++ 18:52:58 <dstanek> ok, put it to a vote? 18:52:59 <samueldmq> dstanek, that comes from controller, and is extracted in the wsgi level 18:53:09 <samueldmq> dstanek, yes please 18:53:20 <samueldmq> if that makes sense to everybody to make it a vote 18:53:20 <bknudson> if nobody's going to sign up to review it there's no point to the vote. 18:53:31 <ayoung_> so... 18:53:38 <ayoung_> HTTP policy would be really nice... 18:53:50 <dstanek> #vote FFE for the policy over HTTP changes. allow it? yes,no 18:54:00 <dstanek> #startvote FFE for the policy over HTTP changes. allow it? yes,no 18:54:01 <samueldmq> #vote yes 18:54:02 <openstack> Begin voting on: FFE for the policy over HTTP changes. allow it? Valid vote options are yes, no. 18:54:03 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 18:54:04 <henrynash> samueldmq: however, we should be under no illusion that getting it in now as experiemtal means it will be made stable in M….that’s down to whether we think it is ready 18:54:08 <ayoung_> #vote yes 18:54:11 <dstanek> starting would have helped 18:54:20 <samueldmq> #vote yes 18:54:35 <bknudson> #vote no 18:54:37 <morgan> henrynash: ++ 18:54:40 <samueldmq> henrynash, yes I agree, it can get experimental now, and stable in N or so, with the rest of policy stuff 18:54:47 <bknudson> I don't think it's worth the chance of instability. 18:54:52 <dstanek> #vote no 18:55:03 <ayoung_> you guys are being short sighted 18:55:07 <ayoung_> this is what the operators want 18:55:10 <gyee> #vote yes 18:55:13 <ayoung_> at least give it to them experimental 18:55:20 <dstanek> i'm worried about the new cache table and the logic surrounding refreshing 18:55:34 <morgan> ayoung_: i disagree this is what "operators want" it was a "oh sure that 18:55:35 <samueldmq> dstanek, I removed that, we are accepting inconsistencies when updates occur 18:55:37 <amakarov> ayoung_, so we 18:55:40 <samueldmq> dstanek, as we discussed before 18:55:44 <morgan> Might be nice" when asked at the ops midcycle 18:55:50 <ayoung_> morgan, horsepocky 18:55:51 <morgan> But not "omg we need that" 18:55:59 <stevemar> #vote no 18:55:59 <amakarov> we'll have plenty bugs to solve and be respected for that )) 18:56:02 <ayoung_> the number ofthings that are limited by our RBAC implementation are growing 18:56:02 <stevemar> there's still way too much disagreement about the direction here, and we would benefit from further discussion 18:56:10 <ayoung_> we need to start making some progress 18:56:10 <morgan> #vote no 18:56:27 * ayoung_ ragequite 18:56:33 <ayoung_> note not quit 18:56:38 <ayoung_> just quite rageful 18:56:50 <stevemar> ayoung_: FWIF you are slowly convincing me 18:56:53 <samueldmq> henrynash, htruta sorry for the timing 18:56:53 <stevemar> FWIW* 18:56:59 <dstanek> ayoung_: i thought that was supposed to be ragequiet 18:57:09 <henrynash> #vote no 18:57:11 <stevemar> quietly rage 18:57:14 <ayoung_> FWTF 18:57:23 <htruta> samueldmq: that's ok 18:57:23 <topol> #vote no 18:57:33 <ayoung_> actually...I am starting to rethink deploying hierarchical roles in the token 18:57:39 <ayoung_> that might actually be the better solution 18:57:42 <lhcheng> #vote no 18:57:45 <ayoung_> implied roles 18:57:46 <lbragstad> #vote no 18:58:01 <ayoung_> but...I'll save that for later 18:58:01 <dstanek> last call for votes.... 18:58:10 <samueldmq> dstanek, k ... should be enough for now 18:58:13 <dstanek> #endvote 18:58:14 <openstack> Voted on "FFE for the policy over HTTP changes. allow it?" Results are 18:58:15 <openstack> yes (3): ayoung_, gyee, samueldmq 18:58:16 <openstack> no (8): dstanek, lhcheng, bknudson, lbragstad, topol, morgan, henrynash, stevemar 18:58:21 <samueldmq> dstanek, would appreciate if we have some minutes to reseller 18:58:36 <samueldmq> ok guys, postpone was the decision 18:58:37 <dstanek> we have slightly less than 2... 18:58:45 <samueldmq> thanks :) 18:58:52 <dstanek> #topic Reseller 18:58:58 <dstanek> if we have the time...... 18:59:19 <htruta> I'd just like to question if it is reasonable to have an FFE 18:59:35 <dstanek> henrynash, htruta maybe we should move this to -keystone 18:59:36 <henrynash> htruta: it just seems TOO much code 18:59:41 <raildo> dstanek: ++ 18:59:44 <htruta> if it isn't I suggest we decide a cut point at the reseller chain that does not break people 18:59:58 <htruta> dstanek: sure 19:00:01 <dstanek> ok, we're out of time.... lets discuss in our own channel 19:00:07 <dstanek> #endmeeting