21:04:37 <dendrobates> #startmeeting
21:04:38 <openstack> Meeting started Tue Sep 14 21:04:37 2010 UTC.  The chair is dendrobates. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:04:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
21:04:40 <dendrobates> oops
21:04:55 <dendrobates> welcome everyone
21:05:20 <dendrobates> as usual the agenda is at http://wiki.openstack.org/Meetings
21:05:37 <dendrobates> #topic old business
21:05:56 <dendrobates> last meetings action items.
21:06:07 * dendrobates find out what license to use for docs] (dendrobates, 21:37:09) ACTION: find out how APL2 affects docs in code (dendrobates, 21:37:32)
21:06:08 <soren> Oh, dear.
21:06:17 <dendrobates> yes soren?
21:06:31 <jaypipes> dendrobates: I think ewan had that answered...
21:06:38 <dendrobates> I discussed the matter with RS legal and they are fine with whatever we decide.  It does look like the docs pulled out of the source need to be APL2.
21:07:10 <dendrobates> Ewan found Apache's policy, that doesn;t have to be ours
21:07:18 <jaypipes> dendrobates: gotcha
21:07:19 <dendrobates> but it probably should
21:07:34 <dendrobates> So my suggestion is that we use APL2 for everything.  Any disagreement?
21:07:39 <jaypipes> dendrobates: well pretty much everything in OS is Apache2...
21:07:41 <jaypipes> #agreed
21:07:50 <joshuamckenty> #agreed
21:07:50 <anotherjesse> #agreed
21:07:52 <adjohn> #agreed
21:07:52 <jbryce> #agreed
21:07:58 <xtoddx> #agreed
21:08:08 <joshuamckenty> #agreed Use APL2 for docs as well as source code
21:08:29 * joshuamckenty thinks that this only works for dendrobates
21:08:45 <dendrobates> ok let's consider it closed then.
21:08:48 <jaypipes> yep :)
21:08:50 <joshuamckenty> can I propose
21:08:51 <pvo> yay
21:08:54 <dendrobates> I think it works for everyone.
21:08:54 <joshuamckenty> that we dual license with CC0 as well?
21:09:00 <joshuamckenty> just to be annoying?
21:09:16 <creiht> dendrobates: Does that cause any issues with RS cloud docs being CC licensed?
21:09:18 <dendrobates> joshuamckenty: that sounds like extra work.
21:09:26 <jaypipes> creiht: I don't believe so, no.
21:09:26 <dendrobates> does it give us anything?
21:09:36 <_0x44> dendrobates: Is that extra work for us, or for legal?
21:09:36 <creiht> then find by me
21:09:36 <soren> It sounds like someone volunteering to do extra work, is what I hear.
21:09:42 <anotherjesse> joshuamckenty: yeah - I don't have permisssion to contribute under other licenses
21:09:43 <joshuamckenty> actually, just to prepare for the fact that, sooner or later, lawyers will realize that docs can't be treated like code, and we need a CC license on the docs
21:09:48 <joshuamckenty> oh, merde
21:09:50 <joshuamckenty> right
21:09:51 <joshuamckenty> nm
21:10:05 <dendrobates> if we wanted to use the cc with the non-comercial clause that maybe, but I don;t really want that
21:10:13 <jaypipes> KISS.
21:10:17 <joshuamckenty> cc0 is essentially public domain
21:10:18 <jbryce> i say we do 1 for now
21:10:20 <jaypipes> APL2 for all.
21:10:23 <joshuamckenty> it makes it easy to excerpt for books
21:10:35 <dendrobates> ok topic closed.
21:10:37 <jaypipes> the fact that RS cloud docs is CC won't intefere.
21:10:49 <dendrobates> #topic summit
21:10:58 <dendrobates> The next design summit has been announced http://goo.gl/OD4X
21:11:07 <dendrobates> November 9-12
21:11:16 <dendrobates> in San Antonio TX
21:11:17 <joshuamckenty> why texas?
21:11:27 <jk0> yeah, I vote Wisconsin
21:11:34 <creiht> hah
21:11:35 <adjohn> Tokyo please :)
21:11:37 <jk0> :D
21:11:40 <jaypipes> he
21:11:44 <dabo> Honolulu, please
21:11:45 <jaypipes> heh even.
21:11:47 <romain_lenglet> I second for Tokyo
21:11:52 <dendrobates> joshuamckenty: because the kind gentleman that is paying requested it :)
21:11:55 <joshuamckenty> in seriousness, though
21:11:57 <soren> I hear Bahamas is nice in November.
21:11:57 <joshuamckenty> Right
21:12:07 <joshuamckenty> can we start a pool for an alternate location for crocus?
21:12:12 <ttx> ans starts with B
21:12:23 <soren> ttx: Oh, right.
21:12:30 <xtoddx> i vote for New Orleans, so I can split time between opentstack and rubyconf
21:12:32 <zul> montreal
21:12:38 <jaypipes> dendrobates: so, the location/date is fixed.  shall we make travel and lodging arrangements or will there be some info coming on the hotel?
21:12:38 <dendrobates> this is Rackspaces chance to show off our headquarters
21:12:45 <dendrobates> yes it is fixed
21:12:55 <dendrobates> Please register your attendance on Launchpad at  http://goo.gl/nw5G
21:13:02 <jaypipes> dendrobates: ah, ok.  missed that, sorry.
21:13:13 <dendrobates> It is free and open to everyone, but we need to know if your coming.
21:13:20 <dendrobates> Info about blueprints and sessions will eventually appear at http://wiki.openstack.org/Summit/Bexar
21:13:25 <pvo> dendrobates:
21:13:34 <dendrobates> pvo: yes
21:13:35 <pvo> er do RS folks need to register?
21:13:48 <dendrobates> yes, it would be helpful for scheduling.
21:13:51 <pvo> ok
21:14:10 <dendrobates> you'll be able to mark yourself as required for certain blueprint discussions
21:14:16 <anotherjesse> dendrobates: the nasa folks are pushing through the paperwork to go
21:14:34 <jaypipes> #action: ALL register for summit if going at http://goo.gl/nw5G
21:14:55 <dendrobates> anotherjesse: there may be a chance of sponsorship for key individuals that cannot get funding to attend.
21:15:20 <dendrobates> let me know if anyone needs help, but no promises
21:15:42 <jaypipes> dendrobates: k, on to orm-refactor? :)
21:16:07 <dendrobates> #topic ORM refactoring
21:16:33 <dendrobates> So I am guessing most people saw my email to the ml
21:16:42 * jaypipes would like to get resolution on this and get it merged today or tomorroww...
21:16:53 * anotherjesse too
21:16:55 <dendrobates> ok so....
21:16:58 * joshuamckenty also
21:16:58 <jaypipes> lots of stuff held up for it right now..
21:17:04 <dendrobates> I propose that we merge it in to austin, and quickly follow with the addition of support for redis,  For the reasons I outlined on the ml.  We can decide if we want to deprecate redis post austin.
21:17:12 * joshuamckenty concurs
21:17:12 <jaypipes> #agreed
21:17:20 <jbryce> #agreed
21:17:22 <anotherjesse> #agreed
21:17:25 <pvo> #agreed
21:17:25 <_0x44> #agreed
21:17:27 <comstud> #agreed
21:17:31 <vishy> #agreed
21:17:33 * joshuamckenty has deep secret love for redis
21:17:34 <soren> #agreed
21:17:35 <jbryce> (and #agreed is an admin only function if you want it to show up in the logs with a summary)
21:17:40 <adjohn> #agreed
21:17:49 <xtoddx> #agreed with joshuamckenty's secret love
21:17:50 <dendrobates> any dissension
21:17:52 <vishy> :(
21:17:58 <soren> joshuamckenty: So you're doing the Redis backend? :)
21:17:58 <anotherjesse> so we aren't supposed to do a #agreed to vote?
21:18:01 <jaypipes> dendrobates: I will go ahead and create a blueprint for the re-addition of a noSQL adapter.
21:18:03 <vishy> fine then: #disagreed
21:18:07 <jaypipes> dendrobates: if ok with you?
21:18:14 <joshuamckenty> soren, I did it the first time :)
21:18:15 <soren> anotherjesse: I think the idea is that the chair uses it to denote what was agreed.
21:18:23 <soren> joshuamckenty: So you've got practice.
21:18:25 <dendrobates> #action create a blueprint for the re-addition of a noSQL adapter.
21:18:25 <jbryce> anotherjesse: you can use it to vote, but it won't get summarized
21:18:40 <joshuamckenty> soren, good point
21:19:04 <anotherjesse> jaypipes / dendrobates re-adding redis should be relatively easy - since the models don't escape the api layer as anything more than dicts
21:19:13 <jaypipes> anotherjesse: yup.
21:19:19 <dendrobates> soren we'll get the voting right next time.
21:19:25 <eday> so, I know people want redis, but why exactly if it doesn't make sense for out data set? It seems we wanted to move away from it and use SQL (hence the orm branch). I don't think we need to worry about backwards compatibility yet
21:19:31 <jaypipes> anotherjesse: though the fakeldap stuff may be the bigger foobar.
21:19:38 <dendrobates> It is not about redis.
21:19:54 <jbryce> i think it's more about shared nothing no spof
21:20:08 <dendrobates> it's more about how we drop something from openstack, imho
21:20:09 <jaypipes> eday: not redis specifically. could be memcache as far as I care...
21:20:09 <anotherjesse> jaypipes: the fake ldap eventually needs to be pluggable user system - eg backend to mysql or redis or ldap or ...
21:20:10 <_0x44> eday: It's about going into a release with required dependencies, and then finishing the release with those dependencies just gone without a period of deprecation
21:20:18 <jaypipes> anotherjesse: ++
21:20:26 <dendrobates> _0x44: exactly
21:20:30 <jaypipes> _0x44: yup.
21:20:55 <eday> dendrobates: well, I think we still have the luxery of not having to worry about that until Austin is released :)
21:21:04 <_0x44> eday: It's not a problem now since we didn't have any users before. But it will be in the future, and we don't want to set bad precedent
21:21:21 <eday> 100% agree we need to deprecate once we have something we say we support, but we've not yet
21:21:25 <jaypipes> eday: so you are saying prioritize the fakeldap rework over the re-addition of a noSQL adapter?  just trying to understand...
21:21:50 <jaypipes> eday: if fakeldap didn't depend on redis, there would be no redis dependency.
21:21:57 <eday> jaypipes: I'm saying don't add a nosql adapter just for the sake of having one at this point, especially if we are moving towards a relational model
21:22:06 <anotherjesse> jaypipes: they are separate - just mentioning it because fakeldap was written at a time when there was no centralized datastore (not even redis)
21:22:31 <jaypipes> anotherjesse: I know, what I'm saying is that the fakeldap piece is the last remaining dependency on redis IINM
21:22:52 <joshuamckenty> jaypipes: so we need two patches
21:23:02 <joshuamckenty> one to be off of redis entirely, and one to put it back in
21:23:08 <dendrobates> Even though we do not have users, it would surprise casual observers that thought redis was required to find it u nsupported.
21:23:27 <jaypipes> joshuamckenty: right, and I believe eday is trying to say it's better to be off redis entirely. right, eday?
21:23:30 <eday> Also, if we keep using a relational data model in nova, and have nosql backends, we'll be reinventing an ORM on top of SQLAlchemy and X (whatever it is we support)
21:23:46 <jaypipes> joshuamckenty, eday: b/c then we could de-prioritize the re-adding of the nosql driver?
21:24:00 <jbryce> sounds like there are 2 separate things people are talking about: 1) managing deprecation of things that are in the project and 2) should we have non-relational/nosql options at all going forward
21:24:02 <dendrobates> then we make a blueprint stating that and discuss it in November and deprecate it.
21:24:33 <_0x44> I think re-adding the nosql driver should still be prioritized because that means that it can be used by the k/v cache for gundlach's rate limiting
21:24:35 <jaypipes> jbryce: yes, but I think eday is saying if we remove the nosql dependency before Austin release, #1 will not be a problem :)
21:24:48 <gundlach> _0x44: i disagree with that
21:24:50 <joshuamckenty> #1 is a problem
21:24:59 <_0x44> gundlach: You disagree that it could be used?
21:25:05 <joshuamckenty> because we're not just removing a dependency, we're adding one
21:25:05 <_0x44> gundlach: Or that it should be prioritized?
21:25:14 <joshuamckenty> we're adding a SQL dependency where we didn't have one before
21:25:17 <jaypipes> joshuamckenty: is it a problem if there is no more redis-dependent code before Austin release?
21:25:19 <gundlach> no, i disagree that it's a priority.  rate limiting works fine for the scale Austin will need, without a separate server
21:25:39 <anotherjesse> jaypipes: not for us
21:25:53 <dendrobates> I think it is a priority and we have a volunteer to do it:  jaypipes
21:25:57 <jaypipes> anotherjesse: meaning there is not a problem? or there is?
21:25:59 <gundlach> and i've already got a simple, working WSGI app that suffices in case someone did need to 'call out sideways' from multiple API servers to do rate limiting.
21:26:03 <dendrobates> it should not affect anyone else
21:26:06 <anotherjesse> jaypipes: there isn't a problem with not having redis - nebula doesn't use it
21:26:17 <joshuamckenty> anymore
21:26:20 * joshuamckenty sniffs
21:26:23 <jaypipes> dendrobates: I'm happy to do it.  But what is "it"? :) the removal of redis dependent code or the re-adding of a nosql driver?
21:26:41 <dendrobates> re-adding of a nosql driver
21:27:06 <anotherjesse> jaypipes: vish and I will help
21:27:10 <jaypipes> dendrobates: ok.  however, I think there is still disagreement on whether we should do that before Austin. eday seems to be making the argument against that.
21:27:17 <jaypipes> anotherjesse: cheers :)
21:27:30 <jaypipes> eday: correct?
21:27:34 <dendrobates> we can then discuss all of this at the summit.  I will make the blueprint myself.
21:27:47 <jaypipes> dendrobates: so, not for Austin, then...
21:28:02 <dendrobates> no, I mean discuss deprecating redis support
21:28:08 <jaypipes> ah...
21:28:09 <jbryce> so for austin, re-add a nosql driver; for future release discuss necessity of nosql support
21:28:20 <dendrobates> jbryce: exactly
21:28:21 <eday> if we are ok dropping redis, what is the technical reason to add some other NoSQL store?
21:28:42 <joshuamckenty> there was no concensus (lazy or otherwise) yet on dropping redis
21:28:43 <eday> I don't see any, especially given that we're moving towards a relational model with the ORM branch
21:28:44 <anotherjesse> proving that we aren't pushing sql assumptions into the data?
21:28:48 <joshuamckenty> there's simply a patch to add SQL support
21:28:49 <anotherjesse> data layer
21:28:55 <jaypipes> jbryce: hmm, ok.  I kind of agree with eday, though.  If we re-add support in for Austin, we must deprecate stuff if in the future we decide not to support it :)
21:29:15 <eday> joshuamckenty: it doesn't just add SQL, it reworks the entire data model and removes redis because fundamental things changed :)
21:29:42 <joshuamckenty> right, but that wasn't the goal of the patch (to remove redis). It was to add an ORM
21:29:44 <jaypipes> joshuamckenty: ya, eday is right on that one.
21:29:59 <anotherjesse> it was to make the data model explicit
21:30:05 <eday> I think we should discuss in November if a SQL store will suffice long term (performance numbers) and think about the long term data model, but I see no reason to add a NoSQL interface/store "just because" for Austin
21:30:08 <anotherjesse> and API interaction with it
21:30:21 <joshuamckenty> there was an earlier (unfinished) effort to make the data model more explicit on top of redis
21:30:30 <jaypipes> sorry, but I'm going to agree with eday on this one...
21:30:34 <jbryce> tying it to sql is a pretty big design decision that will have lots of long-term implications. i think it definitely is worthy of a design summit discussion before making a final decision
21:30:35 <dendrobates> the my reasons from the ml:
21:30:43 <joshuamckenty> we abandoned that at NASA b/c we had to switch from redis for security reasons
21:30:45 <creiht> it seems like you will make more people mad if you add a no-sql backing for redis, and then just drop it a release later
21:30:46 <dendrobates> * OpenStack should avoid making technical decisions for implementers.
21:30:47 <dendrobates> We should only mandate a technology if we have to, for reasons like
21:30:47 <dendrobates> uniformity of the code, i.e the twisted debate, or because choice would
21:30:47 <dendrobates> be difficult to implement.
21:31:02 <jaypipes> creiht: right.
21:31:16 <xtoddx> I don't think lack of NoSQL support "ties" it to SQL.  It is still pluggable, even if the plugin doesn't exist
21:31:23 <joshuamckenty> i disagree
21:31:37 <joshuamckenty> without two plugins, a plugin architecture is just a myth
21:31:47 <jaypipes> joshuamckenty: true.
21:31:50 <joshuamckenty> and if both plugins are SQL-shaped,
21:31:53 <joshuamckenty> then you're tied to SQL
21:31:54 <dendrobates> In general, if we are going to drop a major technology choice, we should do it slowly, by deprecating it first.  We should never go into a release requiring a technology and end the release with it totally
21:31:54 <creiht> so write a null plugin :)
21:31:54 <dendrobates> unsupported.  This is just not fair to our users.  We will make choices, but we need to ensure smooth transitions for people that have implemented Openstack.  I know it is less of an issue for our first
21:31:54 <dendrobates> release, but good policy is good policy.
21:31:56 <xtoddx> but the data interface layer has no assumptions about being in sql, its just hashes
21:32:01 <xtoddx> or dicts, rather
21:32:01 <anotherjesse> joshuamckenty: I agree that it would flush it out .. for instance there are some places that do obj.foo instead of obj['foo'] still
21:32:12 <eday> Also, nothing is set in stone here. We may throw out ORM and convert to something entirely different in 6 months. But right now we know that Redis won't suffice (security at least), and that we have a huge ORM branch blocking other work.
21:32:21 <creiht> dendrobates: when was the first release that required redis? :)
21:32:30 <jaypipes> dendrobates: yes, you are correct... I'm torn on this decision, like I mentioned on the ML.. :(
21:32:32 <jbryce> eday: everyone already agreed to merge the orm branch
21:32:39 <joshuamckenty> creiht: it was nova 0.6
21:32:48 <dendrobates> we should not make security decisions  for implementors
21:32:48 <creiht> dendrobates: and I agree with stable, non-beta products
21:32:51 <joshuamckenty> IIRC
21:33:06 <jaypipes> jbryce: right, we're not discussing whether to merge the orm branch, but what to do about nosql driver for the new datastore api...
21:33:17 <dendrobates> for example you can compile Apache with -DBIG_SECURITY_HOLE
21:33:41 <anotherjesse> proposal: since the "pluggable" daat layer is there - we can spent a couple days the first week of oct adding support for redis
21:33:58 <anotherjesse> it is a "should have" not a "must have"
21:34:03 <joshuamckenty> agreed
21:34:07 <xtoddx> +1
21:34:12 <eday> jbryce: I thought it sounded like some folks  wanted to wait and discuss in November
21:34:41 <anotherjesse> I like the idea of having it since it can ferret out any assumptions we've made in the api that is wrong
21:34:42 <jbryce> eday: i think the discussion is around long-term inclusion of redis or other nosql rather than blocking the orm branch
21:34:50 <jaypipes> anotherjesse: this whole argument is between "should have" and "must have". :) there's a good argument on both sides I think.
21:34:55 <dendrobates> eday: we have agreed to merge orm-refactor
21:35:04 <eday> jbryce: yup, just thought it had regressed for a second :)
21:35:15 <jbryce> #info we will merge orm refactor for austin
21:35:34 <jaypipes> dendrobates: OK, so...why don't we do this... take a vote for "should have" vs. "must have" (for Austin)
21:35:37 <anotherjesse> jaypipes: I would say it is a "must have" if it wasn't for the time constraints...  since having two backends would be nice
21:35:55 <jaypipes> anotherjesse: right, but this is all about Austin
21:36:05 <jbryce> #info discussion required at november design summit around long-term inclusion or deprecation of support for redis/nosql datastores
21:36:10 <jaypipes> anotherjesse: which has a certain timeframe :)
21:36:12 <dendrobates> I think we can get it done.
21:36:12 <joshuamckenty> so we need the same vote for the fakeldap backend
21:36:20 <jaypipes> jbryce: yup, good #info.
21:36:24 <joshuamckenty> e.g., getting that off redis as well
21:36:36 <jaypipes> joshuamckenty: that would be easy enough...
21:36:45 <dendrobates> joshuamckenty: is there a fakeldap branch?
21:36:53 <joshuamckenty> there's a fakeldap module
21:36:59 <joshuamckenty> I don't know if there's a branch
21:37:01 <jaypipes> dendrobates: no, it's a module.
21:37:19 <dendrobates> so this is work that is not done yet.
21:37:27 <dendrobates> and it is only for fakeldap
21:37:38 <joshuamckenty> well, that's what I meant by saying the goal was not redis removal
21:37:45 <jaypipes> joshuamckenty, vishy: we could try using dataflake.ldapconnection.tests.fakeldap...
21:38:03 <joshuamckenty> ooh, interesting. Or we could go back to keeper :)
21:38:08 <captcha12> what is the fakeldap branch?
21:38:08 * joshuamckenty ducks
21:38:09 <jaypipes> ha!
21:38:22 <jaypipes> captcha12: it's a module used in tresting nova.
21:38:26 <joshuamckenty> nothin like serializing json on disk
21:38:57 <joshuamckenty> so vote for "must have"?
21:39:06 <joshuamckenty> #disagree
21:39:11 <dendrobates> -1
21:39:15 <gundlach> #disagree
21:39:29 <xtoddx> -1 on "must"
21:39:33 <jbryce> so let me see if i've got this: the last remaining question is really do we add redis support back in for austin, potentially pulling it back out in future releases and confusing some people--should have option, or do we just let it disappear out of austin (and updating fakeldap) also potentially confusing some people and then add it back in post november--must have option.
21:39:34 <_0x44> -1
21:39:40 <vishy> jaypipes: sure, it needs to support very little
21:39:43 <jaypipes> #disagree
21:39:55 <jaypipes> vishy: not disagreeing with you! ;)
21:40:29 <joshuamckenty> jbryce: I think we've agreed that we "should" put redis support back in for austin. This is whether we "must" do it
21:40:32 <jaypipes> jbryce: no, the must have option is to have rediis/nosql support in Austin's relaease
21:40:34 <gundlach> jbryce: um, i thought 'must' vs 'should' were backwards from your descriptions.
21:40:34 <jbryce> hmm...got my must have and should have backwards, didn't i?
21:40:37 <vishy> #disagree on must have
21:40:38 <xtoddx> i almost feel like redis is a solution looking for a problem, does anyone actually want to run on it?
21:40:47 <joshuamckenty> yes
21:40:49 <joshuamckenty> I do
21:40:58 <eday> I vote we defer the redis/further data model argument to November summit discussions. We should just sit tight with the ORM branch as is (minus small improvements as needed)
21:41:00 <xtoddx> do you want to write it before austin?
21:41:05 <vishy> i think a day of hacking using the old BasicModel will make it work
21:41:05 <jaypipes> OK, so we are #agreed that redis/nosql support is a SHOULD HAVE for Austin.
21:41:17 <joshuamckenty> dude, I'm modelling earthquakes. < xtoddx
21:41:35 <xtoddx> joshuamckenty: wanna talk vish into writing it before austin
21:41:40 <joshuamckenty> yup
21:41:53 <jaypipes> what about the SHOULD vs MUST for the fakeldap rework?  I vote for MUST HAVE.
21:41:56 <joshuamckenty> #info vish will add redis support in using BasicModel, hopefully in time for Austin
21:42:05 <vishy> hehe
21:42:08 <xtoddx> #agreed!
21:42:08 <vishy> thx josh
21:42:12 <joshuamckenty> #agreed
21:42:32 <dendrobates> #disagree, it's only used for testing
21:42:40 <_0x44> Doesn't the outcome of fakeldap depend on whether or not redis is added back?
21:42:50 <joshuamckenty> not really
21:42:56 <dendrobates> _0x44: no it is separate from the data model
21:43:04 <jaypipes> dendrobates: OK, but recognize that the fakeldap module is the last remaining redis dependent code.
21:43:25 <soren> Uh, it's not just used for testing.
21:43:29 <joshuamckenty> I think we're about to spend more time discussing it than the patch will take
21:43:38 <dendrobates> I say should have.  If it comes down to other features, I say drop it
21:43:43 <xtoddx> #agreed joshuamckenty
21:43:48 <jaypipes> dendrobates: without the fakeldap redis dependency, we could theoretically release Austin with no Redis dependency.
21:43:53 <dendrobates> joshuamckenty: ha
21:44:00 <jbryce> soren: what else is it used for?
21:44:10 <joshuamckenty> #info xtoddx will cherry pick the old (pre-redis) fakeldap forward as a patch
21:44:20 <soren> WEll, the fakeldap thing is used if you don't actually want to use ldap for your user backend. This seems common.
21:44:27 <dendrobates> soren: fakeldap is used for more than production?
21:44:32 <soren> It's the default in the Ubuntu packages, for instance.
21:44:32 <dendrobates> er testing
21:44:41 <dendrobates> oh
21:45:15 <joshuamckenty> ooh... we could make fakeldap back onto SQL, and use it as a performance test of the DB ;)
21:45:15 <soren> Since, what's the point in requiring ANOTHER data store for users if you don't alrady have LDAP set up. It's just more needless complication.
21:45:35 <jaypipes> soren: but fakeldap requires redis :)
21:45:46 <joshuamckenty> lol
21:45:55 <jaypipes> I love this catch22 ;)
21:46:01 <xtoddx> jaypipes: we can get off of redis though, maybe move into the db.api layer
21:46:05 <soren> jaypipes: It does, yes.
21:46:10 <soren> jaypipes: I never said it didn't :)
21:46:13 <jaypipes> it's the code equivalent of a Chinese finger-trap.
21:46:33 <dendrobates> yeah, but it's not our fingers we got stuck
21:46:39 <eday> soren: well, then your argument above contradicts itself, since it's the only thing using redis, no?
21:46:54 <jbryce> so it's a must have to get fakeldap working without redis if redis is not a must have
21:46:57 <dendrobates> soren: so what are you suggesting?
21:47:02 <soren> eday: Well, the orm branch hasn't been merged yet :)
21:47:15 <jaypipes> jbryce: thus the catch22 ;)
21:47:17 <soren> dendrobates: That someone makes the fakeldap thing hook into the ORM.
21:47:23 <eday> soren: it will be, that was already decided, and redis is gone for that end :)
21:47:28 <dendrobates> jbryce: they are unrelated
21:47:39 <soren> dendrobates: I'm suggesting that now. I wasn't suggesting anything before. I was just sayin'.
21:47:45 <eday> (well, for now at least)
21:47:58 <xtoddx> 1) merge orm, 2) move fakeldap into the db layer, 3) make a nosql db layer driver
21:48:00 <xtoddx> right?
21:48:05 <soren> eday: sorry, I'm having a hard time keeping up :)
21:48:08 <dendrobates> xtoddx: correct
21:48:10 <joshuamckenty> eday: this is what I was pointing out earlier, when I explained that ORM change wasn't about removing redis
21:48:23 <creiht> Or you could use ldap as your data store, and all your problems are solved :)
21:48:26 <jaypipes> xtoddx: thank you for your clarity. YES!
21:48:31 <vishy> easier would be kill fakeldap and just make an AuthDriver that backends to orm
21:48:45 <eday> joshuamckenty: yeah, I was thinking about just non-auth before. I knoew auth was still using it for fake
21:48:46 <xtoddx> vishy: true
21:48:47 <jaypipes> vishy: already done with repoze.what.sql :)
21:48:48 <joshuamckenty> xtoddx: what's the current cacheing layer on auth?
21:49:00 <dendrobates> so lets get volunteers for each part and end this.
21:49:05 <jaypipes> dendrobates: ++
21:49:16 <dendrobates> talk with your code.
21:49:27 <xtoddx> joshuamckenty: the middleware uses the memcached middleware bundled with swift, but nothing durable
21:49:38 <eday> jaypipes, so, you have it done and solved? :)
21:49:52 <jaypipes> eday: what part? repoze.what.sql?
21:50:10 <dendrobates> let's stay on topic.
21:50:20 <jbryce> #action vishy will add redis support in using BasicModel, hopefully in time for Austin
21:50:29 <eday> jaypipes: the auth/fake ldap replacement
21:50:35 <dendrobates> move fakeldap into the db layer: volunteer?
21:50:41 <jbryce> joshuamckenty also volunteered xtoddx to make fakeldap not depend on redis
21:50:45 <xtoddx> i'll do it, it should be quick
21:50:59 <jbryce> #action xtoddx to move fakeldap into db layer
21:51:02 <soren> \o/
21:51:05 <xtoddx> i'll kill fakeldap and just make a new auth driver that can be default in ubuntu packages
21:51:10 <dendrobates> make a nosql db layer driver:
21:51:22 <dendrobates> jaypipes: are you taking that?
21:51:28 <jaypipes> xtoddx: please take a looksie at repoze.who and repoze.what.
21:51:34 <jaypipes> dendrobates: sure.
21:51:41 <xtoddx> jaypipes: links?
21:51:50 <jaypipes> dendrobates: but I think vishy already has that?
21:51:56 <joshuamckenty> I believe anotherjesse and vishy offered to play in as well
21:52:13 <jbryce> jaypipes: that's what it said earlier in the chat so i just copied it into an action....
21:52:15 <jaypipes> xtoddx: http://docs.repoze.org/who/1.0/
21:52:27 <dendrobates> ok all can play, but I';ll hold jaypipes responsible.
21:52:35 <jaypipes> dendrobates: OK, so vishy, anotherjesse and me.
21:52:39 <jaypipes> dendrobates: cool.
21:52:39 <joshuamckenty> (well, technically *I* offered for vishy to play in, but who's counting)
21:52:43 <xtoddx> jaypipes: thanks
21:53:09 <dendrobates> #action vishy, jaypipes and anotherjesse to make a nosql db layer driver
21:53:25 <jaypipes> xtoddx: http://what.repoze.org/docs/1.0/
21:53:32 <dendrobates> so we have agreement
21:53:38 <jaypipes> yup
21:53:43 <jbryce> is someone going to take point on getting the orm merge in?
21:54:01 <eday> jbryce: I can just go mark as approved right now
21:54:03 <jaypipes> jbryce: it's automated.  just have to set the merge prop to approve.
21:54:20 <jaypipes> eday: do it! get to the chopper!
21:54:25 <vishy> eday: adding a little patch for networking but i can propose it after
21:54:31 <jbryce> jaypipes, eday: yep...just wanted to make sure it didn't get lost in the shuffle
21:54:34 <vishy> there will need to be a few things fixed after merge
21:54:35 <eday> any objects to landing it now?
21:54:38 <jaypipes> jbryce: :)
21:54:46 <jaypipes> eday: nope.
21:54:46 <dendrobates> Let's make sure we've had the proper review.
21:54:50 <eday> err, objections
21:54:55 <jaypipes> dendrobates: it's been reviewed a lot.
21:55:08 <eday> dendrobates: this discussion was the last "review"
21:55:11 <jaypipes> dendrobates: termie and me did a full review as well as eday I believe and soren.
21:55:12 <soren> +1
21:55:25 <soren> It's good stuff. Merge it :)
21:55:25 <dendrobates> jaypipes: thanks, I hadn;t checked
21:55:30 <dendrobates> ok, go!
21:55:30 <eday> ok, marking it
21:55:33 <jaypipes> dendrobates: no worries :)
21:55:51 <dendrobates> I smell a broken build email
21:55:56 <jbryce> haha
21:56:01 <eday> probably :)
21:56:28 <dendrobates> topic closed
21:56:42 <dendrobates> #topic meeting time
21:56:43 <eday> did we need to discuss xtoddx's auth branch too, or save that for later?
21:56:55 <dendrobates> same time next week?
21:57:02 <dendrobates> eday: ml
21:57:08 <adjohn> +1
21:57:14 <zul> can i make a suggest an hour earlier?
21:57:21 <adjohn> please no :(
21:57:29 <vishy> i have about 4 branches based on orm which will need review as well :)
21:57:35 <dendrobates> zul: you can if you want ninjas from japan to behead you
21:57:47 <zul> dendrobates: i would pay to see that
21:58:04 <soren> zul: You can't see ninjas.
21:58:13 <zul> soren: right
21:58:14 <dendrobates> #action everyone do code reviews
21:58:18 <ttx> zul: look behind you.
21:58:35 <dendrobates> #endmeeting