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