Tuesday, 2010-09-14

*** adjohn has joined #openstack-meeting02:34
*** littleidea has quit IRC02:56
*** littleidea has joined #openstack-meeting03:14
*** adjohn_ has joined #openstack-meeting04:02
*** adjohn has quit IRC04:04
*** adjohn_ is now known as adjohn04:04
*** adjohn has quit IRC08:11
*** littleidea has quit IRC09:21
*** littleidea has joined #openstack-meeting09:40
*** littleidea has quit IRC09:49
*** klord has joined #openstack-meeting13:20
*** dendrobates is now known as dendro-afk13:59
*** dendro-afk is now known as dendrobates14:05
*** littleidea has joined #openstack-meeting15:01
*** replicant has joined #openstack-meeting16:37
*** niemeyer has joined #openstack-meeting16:38
*** kevnfx has joined #openstack-meeting16:45
*** kevnfx has quit IRC17:16
*** dendrobates is now known as dendro-afk17:52
*** kapil__ has joined #openstack-meeting17:52
*** niemeyer_ has joined #openstack-meeting17:52
*** niemeyer has quit IRC17:54
*** replicant has quit IRC17:54
*** ttx has joined #openstack-meeting17:57
*** littleidea has quit IRC18:02
*** dendro-afk is now known as dendrobates18:16
*** littleidea has joined #openstack-meeting18:20
*** User481 has joined #openstack-meeting19:15
*** dabo has joined #openstack-meeting19:49
*** anotherjesse has joined #openstack-meeting19:52
*** joshuamckenty has joined #openstack-meeting19:54
*** _cerberus_ has joined #openstack-meeting19:55
*** xtoddx has joined #openstack-meeting19:56
*** kapil__ has quit IRC19:57
*** niemeyer_ has left #openstack-meeting19:57
*** vishy has quit IRC19:59
*** vishy has joined #openstack-meeting20:00
*** gustavomzw has joined #openstack-meeting20:25
*** Rudd-O has joined #openstack-meeting20:30
*** keshav2 has joined #openstack-meeting20:31
*** gholt has joined #openstack-meeting20:31
*** littleidea has quit IRC20:31
*** kevnfx has joined #openstack-meeting20:38
*** romain_lenglet has joined #openstack-meeting20:39
*** kevnfx has left #openstack-meeting20:41
*** kevnfx has joined #openstack-meeting20:41
*** anotherjesse has quit IRC20:43
*** jbryce has joined #openstack-meeting20:44
*** Youcef has joined #openstack-meeting20:48
dendrobateswoohoo 10 minutes to go.20:50
*** anotherjesse has joined #openstack-meeting20:50
joshuamckentyWe should have some credits run automatically20:52
* joshuamckenty prompts "My sister got bit by a llama once..."20:53
*** adjohn has joined #openstack-meeting20:53
*** pvo has joined #openstack-meeting20:54
anotherjessemovie trivia [sponsored by coca cola] asks: what hollywood hulk co-stars with Jennifer Lopez in The Wedding Planner?20:55
vishys/hulk/hunk ?20:56
anotherjessethat was a joke (referencing josh's pre-movie credits"20:56
*** jbarratt has joined #openstack-meeting20:56
*** murkk has joined #openstack-meeting20:57
*** kevnfx has left #openstack-meeting20:57
joshuamckentyum...20:57
joshuamckentyJim Carey?20:58
zulgday20:58
*** comstud has joined #openstack-meeting20:59
jbryceanotherjesse: lou ferrigno!20:59
*** kevnfx has joined #openstack-meeting21:00
soreno/21:00
vishyjybryce: lol21:00
anotherjesseok, danceparty time21:00
*** _0x44 has joined #openstack-meeting21:00
joshuamckenty(dance)21:00
*** jaypipes has joined #openstack-meeting21:00
joshuamckentyoh, bother. No skype gestures21:00
dendrobatesI'll give everyone a few minutes to show before we start21:00
* joshuamckenty sighs.21:00
jaypipesjoshuamckenty: whatup? :)21:01
*** jk0 has joined #openstack-meeting21:01
*** creiht has joined #openstack-meeting21:01
* joshuamckenty misses his (dance)(party) goodness from skype21:01
jaypipesjoshuamckenty: re: CLI options/config processing, see here: http://wiki.openstack.org/CommonOptionsProcessing21:02
xtoddx(headbang)21:02
*** jie has joined #openstack-meeting21:02
jaypipesjoshuamckenty: I'll be emailing the ML later this week to officially propose that.21:02
joshuamckentyah, nice, danke (jaypipes )21:02
jaypipesnp21:02
joshuamckentydo you follow up your blueprints with an ML email?21:03
joshuamckentyI've just been abandoning them in the ether ;)21:03
Rudd-OOK21:03
Rudd-Oher eI am21:03
Rudd-O-)21:03
*** pvo has left #openstack-meeting21:04
Rudd-Oand so is keshav2 from cloud.com21:04
jaypipesjoshuamckenty: yes, I do the spec on the wiki, tied to a blueprint.21:04
dendrobates#start-meeting21:04
*** pvo has joined #openstack-meeting21:04
jaypipesjoshuamckenty: the ML email is just to notify people of the spec.21:04
jaypipesjoshuamckenty: and get feedback of course21:04
dendrobates#startmeeting21:04
openstackMeeting started Tue Sep 14 21:04:37 2010 UTC.  The chair is dendrobates. Information about MeetBot at http://wiki.debian.org/MeetBot.21:04
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.21:04
dendrobatesoops21:04
dendrobateswelcome everyone21:04
dendrobatesas usual the agenda is at http://wiki.openstack.org/Meetings21:05
dendrobates#topic old business21:05
dendrobateslast meetings action items.21:05
dendrobatesACTION: 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
sorenOh, dear.21:06
dendrobatesyes soren?21:06
jaypipesdendrobates: I think ewan had that answered...21:06
dendrobatesI 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:06
dendrobatesEwan found Apache's policy, that doesn;t have to be ours21:07
jaypipesdendrobates: gotcha21:07
dendrobatesbut it probably should21:07
dendrobatesSo my suggestion is that we use APL2 for everything.  Any disagreement?21:07
jaypipesdendrobates: well pretty much everything in OS is Apache2...21:07
jaypipes#agreed21:07
joshuamckenty#agreed21:07
anotherjesse#agreed21:07
adjohn#agreed21:07
jbryce#agreed21:07
xtoddx#agreed21:07
joshuamckenty#agreed Use APL2 for docs as well as source code21:08
* joshuamckenty thinks that this only works for dendrobates 21:08
dendrobatesok let's consider it closed then.21:08
jaypipesyep :)21:08
joshuamckentycan I propose21:08
pvoyay21:08
dendrobatesI think it works for everyone.21:08
joshuamckentythat we dual license with CC0 as well?21:08
joshuamckentyjust to be annoying?21:09
creihtdendrobates: Does that cause any issues with RS cloud docs being CC licensed?21:09
dendrobatesjoshuamckenty: that sounds like extra work.21:09
jaypipescreiht: I don't believe so, no.21:09
dendrobatesdoes it give us anything?21:09
_0x44dendrobates: Is that extra work for us, or for legal?21:09
creihtthen find by me21:09
sorenIt sounds like someone volunteering to do extra work, is what I hear.21:09
anotherjessejoshuamckenty: yeah - I don't have permisssion to contribute under other licenses21:09
joshuamckentyactually, 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 docs21:09
joshuamckentyoh, merde21:09
joshuamckentyright21:09
joshuamckentynm21:09
dendrobatesif we wanted to use the cc with the non-comercial clause that maybe, but I don;t really want that21:10
jaypipesKISS.21:10
joshuamckentycc0 is essentially public domain21:10
jbrycei say we do 1 for now21:10
jaypipesAPL2 for all.21:10
joshuamckentyit makes it easy to excerpt for books21:10
dendrobatesok topic closed.21:10
jaypipesthe fact that RS cloud docs is CC won't intefere.21:10
dendrobates#topic summit21:10
dendrobatesThe next design summit has been announced http://goo.gl/OD4X21:10
dendrobatesNovember 9-1221:11
dendrobatesin San Antonio TX21:11
joshuamckentywhy texas?21:11
jk0yeah, I vote Wisconsin21:11
creihthah21:11
adjohnTokyo please :)21:11
jk0:D21:11
jaypipeshe21:11
daboHonolulu, please21:11
jaypipesheh even.21:11
romain_lengletI second for Tokyo21:11
dendrobatesjoshuamckenty: because the kind gentleman that is paying requested it :)21:11
joshuamckentyin seriousness, though21:11
sorenI hear Bahamas is nice in November.21:11
joshuamckentyRight21:11
joshuamckentycan we start a pool for an alternate location for crocus?21:12
ttxans starts with B21:12
sorenttx: Oh, right.21:12
xtoddxi vote for New Orleans, so I can split time between opentstack and rubyconf21:12
zulmontreal21:12
jaypipesdendrobates: 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
dendrobatesthis is Rackspaces chance to show off our headquarters21:12
dendrobatesyes it is fixed21:12
dendrobatesPlease register your attendance on Launchpad at  http://goo.gl/nw5G21:12
jaypipesdendrobates: ah, ok.  missed that, sorry.21:13
dendrobatesIt is free and open to everyone, but we need to know if your coming.21:13
dendrobatesInfo about blueprints and sessions will eventually appear at http://wiki.openstack.org/Summit/Bexar21:13
pvodendrobates:21:13
dendrobatespvo: yes21:13
pvoer do RS folks need to register?21:13
dendrobatesyes, it would be helpful for scheduling.21:13
pvook21:13
dendrobatesyou'll be able to mark yourself as required for certain blueprint discussions21:14
anotherjessedendrobates: the nasa folks are pushing through the paperwork to go21:14
*** captcha12 has joined #openstack-meeting21:14
jaypipes#action: ALL register for summit if going at http://goo.gl/nw5G21:14
dendrobatesanotherjesse: there may be a chance of sponsorship for key individuals that cannot get funding to attend.21:14
dendrobateslet me know if anyone needs help, but no promises21:15
jaypipesdendrobates: k, on to orm-refactor? :)21:15
dendrobates#topic ORM refactoring21:16
dendrobatesSo I am guessing most people saw my email to the ml21:16
* jaypipes would like to get resolution on this and get it merged today or tomorroww...21:16
* anotherjesse too21:16
*** littleidea has joined #openstack-meeting21:16
dendrobatesok so....21:16
* joshuamckenty also21:16
jaypipeslots of stuff held up for it right now..21:16
dendrobatesI 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
* joshuamckenty concurs21:17
jaypipes#agreed21:17
jbryce#agreed21:17
anotherjesse#agreed21:17
pvo#agreed21:17
_0x44#agreed21:17
comstud#agreed21:17
vishy#agreed21:17
* joshuamckenty has deep secret love for redis21:17
soren#agreed21:17
jbryce(and #agreed is an admin only function if you want it to show up in the logs with a summary)21:17
adjohn#agreed21:17
xtoddx#agreed with joshuamckenty's secret love21:17
dendrobatesany dissension21:17
vishy:(21:17
sorenjoshuamckenty: So you're doing the Redis backend? :)21:17
anotherjesseso we aren't supposed to do a #agreed to vote?21:17
jaypipesdendrobates: I will go ahead and create a blueprint for the re-addition of a noSQL adapter.21:18
vishyfine then: #disagreed21:18
jaypipesdendrobates: if ok with you?21:18
joshuamckentysoren, I did it the first time :)21:18
sorenanotherjesse: I think the idea is that the chair uses it to denote what was agreed.21:18
sorenjoshuamckenty: So you've got practice.21:18
dendrobates#action create a blueprint for the re-addition of a noSQL adapter.21:18
jbryceanotherjesse: you can use it to vote, but it won't get summarized21:18
joshuamckentysoren, good point21:18
anotherjessejaypipes / dendrobates re-adding redis should be relatively easy - since the models don't escape the api layer as anything more than dicts21:19
jaypipesanotherjesse: yup.21:19
dendrobatessoren we'll get the voting right next time.21:19
edayso, 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 yet21:19
jaypipesanotherjesse: though the fakeldap stuff may be the bigger foobar.21:19
dendrobatesIt is not about redis.21:19
jbrycei think it's more about shared nothing no spof21:19
dendrobatesit's more about how we drop something from openstack, imho21:20
jaypipeseday: not redis specifically. could be memcache as far as I care...21:20
anotherjessejaypipes: the fake ldap eventually needs to be pluggable user system - eg backend to mysql or redis or ldap or ...21:20
_0x44eday: It's about going into a release with required dependencies, and then finishing the release with those dependencies just gone without a period of deprecation21:20
jaypipesanotherjesse: ++21:20
dendrobates_0x44: exactly21:20
jaypipes_0x44: yup.21:20
edaydendrobates: well, I think we still have the luxery of not having to worry about that until Austin is released :)21:20
_0x44eday: 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 precedent21:21
eday100% agree we need to deprecate once we have something we say we support, but we've not yet21:21
jaypipeseday: so you are saying prioritize the fakeldap rework over the re-addition of a noSQL adapter?  just trying to understand...21:21
jaypipeseday: if fakeldap didn't depend on redis, there would be no redis dependency.21:21
edayjaypipes: 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 model21:21
anotherjessejaypipes: they are separate - just mentioning it because fakeldap was written at a time when there was no centralized datastore (not even redis)21:22
jaypipesanotherjesse: I know, what I'm saying is that the fakeldap piece is the last remaining dependency on redis IINM21:22
*** gundlach has joined #openstack-meeting21:22
joshuamckentyjaypipes: so we need two patches21:22
joshuamckentyone to be off of redis entirely, and one to put it back in21:23
dendrobatesEven though we do not have users, it would surprise casual observers that thought redis was required to find it u nsupported.21:23
jaypipesjoshuamckenty: right, and I believe eday is trying to say it's better to be off redis entirely. right, eday?21:23
edayAlso, 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
jaypipesjoshuamckenty, eday: b/c then we could de-prioritize the re-adding of the nosql driver?21:23
jbrycesounds 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 forward21:24
dendrobatesthen we make a blueprint stating that and discuss it in November and deprecate it.21:24
_0x44I 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 limiting21:24
jaypipesjbryce: yes, but I think eday is saying if we remove the nosql dependency before Austin release, #1 will not be a problem :)21:24
gundlach_0x44: i disagree with that21:24
joshuamckenty#1 is a problem21:24
_0x44gundlach: You disagree that it could be used?21:24
joshuamckentybecause we're not just removing a dependency, we're adding one21:25
_0x44gundlach: Or that it should be prioritized?21:25
joshuamckentywe're adding a SQL dependency where we didn't have one before21:25
jaypipesjoshuamckenty: is it a problem if there is no more redis-dependent code before Austin release?21:25
gundlachno, i disagree that it's a priority.  rate limiting works fine for the scale Austin will need, without a separate server21:25
anotherjessejaypipes: not for us21:25
dendrobatesI think it is a priority and we have a volunteer to do it:  jaypipes21:25
jaypipesanotherjesse: meaning there is not a problem? or there is?21:25
gundlachand 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:25
dendrobatesit should not affect anyone else21:26
anotherjessejaypipes: there isn't a problem with not having redis - nebula doesn't use it21:26
joshuamckentyanymore21:26
* joshuamckenty sniffs21:26
jaypipesdendrobates: 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
dendrobatesre-adding of a nosql driver21:26
anotherjessejaypipes: vish and I will help21:27
jaypipesdendrobates: 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
jaypipesanotherjesse: cheers :)21:27
jaypipeseday: correct?21:27
dendrobateswe can then discuss all of this at the summit.  I will make the blueprint myself.21:27
jaypipesdendrobates: so, not for Austin, then...21:27
dendrobatesno, I mean discuss deprecating redis support21:28
jaypipesah...21:28
jbryceso for austin, re-add a nosql driver; for future release discuss necessity of nosql support21:28
dendrobatesjbryce: exactly21:28
edayif we are ok dropping redis, what is the technical reason to add some other NoSQL store?21:28
joshuamckentythere was no concensus (lazy or otherwise) yet on dropping redis21:28
edayI don't see any, especially given that we're moving towards a relational model with the ORM branch21:28
anotherjesseproving that we aren't pushing sql assumptions into the data?21:28
joshuamckentythere's simply a patch to add SQL support21:28
anotherjessedata layer21:28
jaypipesjbryce: 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:28
edayjoshuamckenty: it doesn't just add SQL, it reworks the entire data model and removes redis because fundamental things changed :)21:29
joshuamckentyright, but that wasn't the goal of the patch (to remove redis). It was to add an ORM21:29
jaypipesjoshuamckenty: ya, eday is right on that one.21:29
anotherjesseit was to make the data model explicit21:29
edayI 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 Austin21:30
anotherjesseand API interaction with it21:30
joshuamckentythere was an earlier (unfinished) effort to make the data model more explicit on top of redis21:30
jaypipessorry, but I'm going to agree with eday on this one...21:30
jbrycetying 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 decision21:30
dendrobatesthe my reasons from the ml:21:30
joshuamckentywe abandoned that at NASA b/c we had to switch from redis for security reasons21:30
creihtit seems like you will make more people mad if you add a no-sql backing for redis, and then just drop it a release later21:30
dendrobates * OpenStack should avoid making technical decisions for implementers.21:30
dendrobatesWe should only mandate a technology if we have to, for reasons like21:30
dendrobatesuniformity of the code, i.e the twisted debate, or because choice would21:30
dendrobatesbe difficult to implement.21:30
jaypipescreiht: right.21:31
xtoddxI don't think lack of NoSQL support "ties" it to SQL.  It is still pluggable, even if the plugin doesn't exist21:31
joshuamckentyi disagree21:31
joshuamckentywithout two plugins, a plugin architecture is just a myth21:31
jaypipesjoshuamckenty: true.21:31
joshuamckentyand if both plugins are SQL-shaped,21:31
joshuamckentythen you're tied to SQL21:31
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 totally21:31
creihtso write a null plugin :)21:31
dendrobatesunsupported.  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 first21:31
dendrobatesrelease, but good policy is good policy.21:31
xtoddxbut the data interface layer has no assumptions about being in sql, its just hashes21:31
xtoddxor dicts, rather21:32
anotherjessejoshuamckenty: I agree that it would flush it out .. for instance there are some places that do obj.foo instead of obj['foo'] still21:32
edayAlso, 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
creihtdendrobates: when was the first release that required redis? :)21:32
jaypipesdendrobates: yes, you are correct... I'm torn on this decision, like I mentioned on the ML.. :(21:32
jbryceeday: everyone already agreed to merge the orm branch21:32
joshuamckentycreiht: it was nova 0.621:32
*** klord has quit IRC21:32
dendrobateswe should not make security decisions  for implementors21:32
creihtdendrobates: and I agree with stable, non-beta products21:32
joshuamckentyIIRC21:32
jaypipesjbryce: 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
dendrobatesfor example you can compile Apache with -DBIG_SECURITY_HOLE21:33
anotherjesseproposal: since the "pluggable" daat layer is there - we can spent a couple days the first week of oct adding support for redis21:33
anotherjesseit is a "should have" not a "must have"21:33
joshuamckentyagreed21:34
xtoddx+121:34
edayjbryce: I thought it sounded like some folks  wanted to wait and discuss in November21:34
anotherjesseI like the idea of having it since it can ferret out any assumptions we've made in the api that is wrong21:34
jbryceeday: i think the discussion is around long-term inclusion of redis or other nosql rather than blocking the orm branch21:34
jaypipesanotherjesse: this whole argument is between "should have" and "must have". :) there's a good argument on both sides I think.21:34
dendrobateseday: we have agreed to merge orm-refactor21:34
edayjbryce: yup, just thought it had regressed for a second :)21:35
jbryce#info we will merge orm refactor for austin21:35
jaypipesdendrobates: OK, so...why don't we do this... take a vote for "should have" vs. "must have" (for Austin)21:35
anotherjessejaypipes: I would say it is a "must have" if it wasn't for the time constraints...  since having two backends would be nice21:35
jaypipesanotherjesse: right, but this is all about Austin21:35
jbryce#info discussion required at november design summit around long-term inclusion or deprecation of support for redis/nosql datastores21:36
jaypipesanotherjesse: which has a certain timeframe :)21:36
dendrobatesI think we can get it done.21:36
joshuamckentyso we need the same vote for the fakeldap backend21:36
jaypipesjbryce: yup, good #info.21:36
joshuamckentye.g., getting that off redis as well21:36
jaypipesjoshuamckenty: that would be easy enough...21:36
dendrobatesjoshuamckenty: is there a fakeldap branch?21:36
joshuamckentythere's a fakeldap module21:36
joshuamckentyI don't know if there's a branch21:36
jaypipesdendrobates: no, it's a module.21:37
dendrobatesso this is work that is not done yet.21:37
dendrobatesand it is only for fakeldap21:37
*** anotherjesse has quit IRC21:37
joshuamckentywell, that's what I meant by saying the goal was not redis removal21:37
jaypipesjoshuamckenty, vishy: we could try using dataflake.ldapconnection.tests.fakeldap...21:37
joshuamckentyooh, interesting. Or we could go back to keeper :)21:38
captcha12what is the fakeldap branch?21:38
* joshuamckenty ducks21:38
jaypipesha!21:38
jaypipescaptcha12: it's a module used in tresting nova.21:38
joshuamckentynothin like serializing json on disk21:38
joshuamckentyso vote for "must have"?21:38
joshuamckenty#disagree21:39
dendrobates-121:39
gundlach#disagree21:39
xtoddx-1 on "must"21:39
jbryceso 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
_0x44-121:39
vishyjaypipes: sure, it needs to support very little21:39
jaypipes#disagree21:39
jaypipesvishy: not disagreeing with you! ;)21:39
joshuamckentyjbryce: I think we've agreed that we "should" put redis support back in for austin. This is whether we "must" do it21:40
jaypipesjbryce: no, the must have option is to have rediis/nosql support in Austin's relaease21:40
gundlachjbryce: um, i thought 'must' vs 'should' were backwards from your descriptions.21:40
jbrycehmm...got my must have and should have backwards, didn't i?21:40
vishy#disagree on must have21:40
xtoddxi almost feel like redis is a solution looking for a problem, does anyone actually want to run on it?21:40
joshuamckentyyes21:40
joshuamckentyI do21:40
edayI 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:40
xtoddxdo you want to write it before austin?21:41
vishyi think a day of hacking using the old BasicModel will make it work21:41
jaypipesOK, so we are #agreed that redis/nosql support is a SHOULD HAVE for Austin.21:41
joshuamckentydude, I'm modelling earthquakes. < xtoddx21:41
xtoddxjoshuamckenty: wanna talk vish into writing it before austin21:41
joshuamckentyyup21:41
jaypipeswhat about the SHOULD vs MUST for the fakeldap rework?  I vote for MUST HAVE.21:41
joshuamckenty#info vish will add redis support in using BasicModel, hopefully in time for Austin21:41
vishyhehe21:42
xtoddx#agreed!21:42
vishythx josh21:42
joshuamckenty#agreed21:42
*** maple_bed has joined #openstack-meeting21:42
dendrobates#disagree, it's only used for testing21:42
_0x44Doesn't the outcome of fakeldap depend on whether or not redis is added back?21:42
joshuamckentynot really21:42
dendrobates_0x44: no it is separate from the data model21:42
jaypipesdendrobates: OK, but recognize that the fakeldap module is the last remaining redis dependent code.21:43
sorenUh, it's not just used for testing.21:43
joshuamckentyI think we're about to spend more time discussing it than the patch will take21:43
dendrobatesI say should have.  If it comes down to other features, I say drop it21:43
xtoddx#agreed joshuamckenty21:43
jaypipesdendrobates: without the fakeldap redis dependency, we could theoretically release Austin with no Redis dependency.21:43
dendrobatesjoshuamckenty: ha21:43
jbrycesoren: what else is it used for?21:44
joshuamckenty#info xtoddx will cherry pick the old (pre-redis) fakeldap forward as a patch21:44
sorenWEll, the fakeldap thing is used if you don't actually want to use ldap for your user backend. This seems common.21:44
dendrobatessoren: fakeldap is used for more than production?21:44
sorenIt's the default in the Ubuntu packages, for instance.21:44
dendrobateser testing21:44
dendrobatesoh21:44
joshuamckentyooh... we could make fakeldap back onto SQL, and use it as a performance test of the DB ;)21:45
sorenSince, 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
*** maple_bed has left #openstack-meeting21:45
jaypipessoren: but fakeldap requires redis :)21:45
joshuamckentylol21:45
jaypipesI love this catch22 ;)21:45
xtoddxjaypipes: we can get off of redis though, maybe move into the db.api layer21:46
sorenjaypipes: It does, yes.21:46
sorenjaypipes: I never said it didn't :)21:46
jaypipesit's the code equivalent of a Chinese finger-trap.21:46
dendrobatesyeah, but it's not our fingers we got stuck21:46
edaysoren: well, then your argument above contradicts itself, since it's the only thing using redis, no?21:46
jbryceso it's a must have to get fakeldap working without redis if redis is not a must have21:46
dendrobatessoren: so what are you suggesting?21:46
soreneday: Well, the orm branch hasn't been merged yet :)21:47
jaypipesjbryce: thus the catch22 ;)21:47
sorendendrobates: That someone makes the fakeldap thing hook into the ORM.21:47
edaysoren: it will be, that was already decided, and redis is gone for that end :)21:47
dendrobatesjbryce: they are unrelated21:47
sorendendrobates: I'm suggesting that now. I wasn't suggesting anything before. I was just sayin'.21:47
eday(well, for now at least)21:47
xtoddx1) merge orm, 2) move fakeldap into the db layer, 3) make a nosql db layer driver21:47
xtoddxright?21:48
soreneday: sorry, I'm having a hard time keeping up :)21:48
dendrobatesxtoddx: correct21:48
joshuamckentyeday: this is what I was pointing out earlier, when I explained that ORM change wasn't about removing redis21:48
creihtOr you could use ldap as your data store, and all your problems are solved :)21:48
jaypipesxtoddx: thank you for your clarity. YES!21:48
vishyeasier would be kill fakeldap and just make an AuthDriver that backends to orm21:48
edayjoshuamckenty: yeah, I was thinking about just non-auth before. I knoew auth was still using it for fake21:48
xtoddxvishy: true21:48
jaypipesvishy: already done with repoze.what.sql :)21:48
joshuamckentyxtoddx: what's the current cacheing layer on auth?21:48
dendrobatesso lets get volunteers for each part and end this.21:49
jaypipesdendrobates: ++21:49
dendrobatestalk with your code.21:49
xtoddxjoshuamckenty: the middleware uses the memcached middleware bundled with swift, but nothing durable21:49
edayjaypipes, so, you have it done and solved? :)21:49
jaypipeseday: what part? repoze.what.sql?21:49
dendrobateslet's stay on topic.21:50
jbryce#action vishy will add redis support in using BasicModel, hopefully in time for Austin21:50
edayjaypipes: the auth/fake ldap replacement21:50
dendrobates move fakeldap into the db layer: volunteer?21:50
jbrycejoshuamckenty also volunteered xtoddx to make fakeldap not depend on redis21:50
xtoddxi'll do it, it should be quick21:50
jbryce#action xtoddx to move fakeldap into db layer21:50
soren\o/21:51
xtoddxi'll kill fakeldap and just make a new auth driver that can be default in ubuntu packages21:51
dendrobatesmake a nosql db layer driver:21:51
dendrobatesjaypipes: are you taking that?21:51
jaypipesxtoddx: please take a looksie at repoze.who and repoze.what.21:51
jaypipesdendrobates: sure.21:51
xtoddxjaypipes: links?21:51
jaypipesdendrobates: but I think vishy already has that?21:51
joshuamckentyI believe anotherjesse and vishy offered to play in as well21:51
jbrycejaypipes: that's what it said earlier in the chat so i just copied it into an action....21:52
jaypipesxtoddx: http://docs.repoze.org/who/1.0/21:52
dendrobatesok all can play, but I';ll hold jaypipes responsible.21:52
jaypipesdendrobates: OK, so vishy, anotherjesse and me.21:52
jaypipesdendrobates: cool.21:52
joshuamckenty(well, technically *I* offered for vishy to play in, but who's counting)21:52
xtoddxjaypipes: thanks21:52
dendrobates#action vishy, jaypipes and anotherjesse to make a nosql db layer driver21:53
jaypipesxtoddx: http://what.repoze.org/docs/1.0/21:53
dendrobatesso we have agreement21:53
jaypipesyup21:53
jbryceis someone going to take point on getting the orm merge in?21:53
edayjbryce: I can just go mark as approved right now21:54
jaypipesjbryce: it's automated.  just have to set the merge prop to approve.21:54
jaypipeseday: do it! get to the chopper!21:54
vishyeday: adding a little patch for networking but i can propose it after21:54
jbrycejaypipes, eday: yep...just wanted to make sure it didn't get lost in the shuffle21:54
vishythere will need to be a few things fixed after merge21:54
edayany objects to landing it now?21:54
jaypipesjbryce: :)21:54
jaypipeseday: nope.21:54
dendrobatesLet's make sure we've had the proper review.21:54
edayerr, objections21:54
jaypipesdendrobates: it's been reviewed a lot.21:54
edaydendrobates: this discussion was the last "review"21:55
jaypipesdendrobates: termie and me did a full review as well as eday I believe and soren.21:55
soren+121:55
sorenIt's good stuff. Merge it :)21:55
dendrobatesjaypipes: thanks, I hadn;t checked21:55
dendrobatesok, go!21:55
edayok, marking it21:55
jaypipesdendrobates: no worries :)21:55
dendrobatesI smell a broken build email21:55
jbrycehaha21:55
edayprobably :)21:56
dendrobatestopic closed21:56
dendrobates#topic meeting time21:56
edaydid we need to discuss xtoddx's auth branch too, or save that for later?21:56
dendrobatessame time next week?21:56
dendrobateseday: ml21:57
adjohn+121:57
zulcan i make a suggest an hour earlier?21:57
adjohnplease no :(21:57
vishyi have about 4 branches based on orm which will need review as well :)21:57
dendrobateszul: you can if you want ninjas from japan to behead you21:57
zuldendrobates: i would pay to see that21:57
sorenzul: You can't see ninjas.21:58
zulsoren: right21:58
dendrobates#action everyone do code reviews21:58
ttxzul: look behind you.21:58
dendrobates#endmeeting21:58
openstackMeeting ended Tue Sep 14 21:58:35 2010 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:58
openstackMinutes:        http://eavesdrop.openstack.org/meetings/openstack-meeting/2010/openstack-meeting.2010-09-14-21.04.html21:58
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2010/openstack-meeting.2010-09-14-21.04.txt21:58
openstackLog:            http://eavesdrop.openstack.org/meetings/openstack-meeting/2010/openstack-meeting.2010-09-14-21.04.log.html21:58
creihtyay21:58
* jaypipes waits for adjohn to spring into ninja action.21:59
edaywhew21:59
dendrobatesthese things are difficult to discuss on IRC, the summit will help us out a lot.21:59
adjohnjaypipes: when you least expect it ;)21:59
jaypipeswasn't that bad :)21:59
jaypipesadjohn: :)21:59
dendrobateswe would have had much less confusion.21:59
* jaypipes blames all confusion on dendrobates 21:59
jaypipesheh21:59
*** kevnfx has quit IRC22:00
dendrobateseveryone else was confused. I am always right, even when I'm wrong. :)22:00
edaydendrobates: I think we need to deep-dive into some things to make sure we're on the same page before making some of these data model decisions too.. I think folks have different ideas of the direction we're going (no one is wrong... just different)22:00
joshuamckentythere is no "we"22:00
dendrobatesther is no spoon22:01
joshuamckentyexactly22:01
jaypipesjoshuamckenty: thank you Yoda. ;P22:01
jk0there is also no santa22:01
joshuamckentydude22:01
jaypipesjk0: damn it.  spoiler.22:01
joshuamckentyhow can you be so HURTFUL?22:01
jaypipesjoshuamckenty: hehe22:01
joshuamckentybut I agree with eday generally22:01
jaypipesya22:01
joshuamckentyeven if we clearly identify where we're divergent22:02
edaywe really need to identify the long-term "what" before deciding anything :)22:02
edayat least, as best we can22:02
*** jie has quit IRC22:02
*** creiht has left #openstack-meeting22:02
*** romain_lenglet has quit IRC22:03
*** pvo has left #openstack-meeting22:03
*** captcha12 has quit IRC22:03
*** jk0 has left #openstack-meeting22:04
*** gholt has left #openstack-meeting22:07
*** dabo has quit IRC22:07
*** joshuamckenty has left #openstack-meeting22:07
*** xtoddx has left #openstack-meeting22:18
*** murkk has left #openstack-meeting22:20
*** adjohn has quit IRC22:31
*** gundlach has quit IRC22:53
*** gundlach has joined #openstack-meeting22:57
*** dendrobates is now known as dendro-afk23:13
*** gasbakid has joined #openstack-meeting23:16
*** gundlach has quit IRC23:39
*** Rudd-O has quit IRC23:39
*** Youcef has quit IRC23:51
*** Rudd-O has joined #openstack-meeting23:52

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!