*** adjohn has joined #openstack-meeting | 02:34 | |
*** littleidea has quit IRC | 02:56 | |
*** littleidea has joined #openstack-meeting | 03:14 | |
*** adjohn_ has joined #openstack-meeting | 04:02 | |
*** adjohn has quit IRC | 04:04 | |
*** adjohn_ is now known as adjohn | 04:04 | |
*** adjohn has quit IRC | 08:11 | |
*** littleidea has quit IRC | 09:21 | |
*** littleidea has joined #openstack-meeting | 09:40 | |
*** littleidea has quit IRC | 09:49 | |
*** klord has joined #openstack-meeting | 13:20 | |
*** dendrobates is now known as dendro-afk | 13:59 | |
*** dendro-afk is now known as dendrobates | 14:05 | |
*** littleidea has joined #openstack-meeting | 15:01 | |
*** replicant has joined #openstack-meeting | 16:37 | |
*** niemeyer has joined #openstack-meeting | 16:38 | |
*** kevnfx has joined #openstack-meeting | 16:45 | |
*** kevnfx has quit IRC | 17:16 | |
*** dendrobates is now known as dendro-afk | 17:52 | |
*** kapil__ has joined #openstack-meeting | 17:52 | |
*** niemeyer_ has joined #openstack-meeting | 17:52 | |
*** niemeyer has quit IRC | 17:54 | |
*** replicant has quit IRC | 17:54 | |
*** ttx has joined #openstack-meeting | 17:57 | |
*** littleidea has quit IRC | 18:02 | |
*** dendro-afk is now known as dendrobates | 18:16 | |
*** littleidea has joined #openstack-meeting | 18:20 | |
*** User481 has joined #openstack-meeting | 19:15 | |
*** dabo has joined #openstack-meeting | 19:49 | |
*** anotherjesse has joined #openstack-meeting | 19:52 | |
*** joshuamckenty has joined #openstack-meeting | 19:54 | |
*** _cerberus_ has joined #openstack-meeting | 19:55 | |
*** xtoddx has joined #openstack-meeting | 19:56 | |
*** kapil__ has quit IRC | 19:57 | |
*** niemeyer_ has left #openstack-meeting | 19:57 | |
*** vishy has quit IRC | 19:59 | |
*** vishy has joined #openstack-meeting | 20:00 | |
*** gustavomzw has joined #openstack-meeting | 20:25 | |
*** Rudd-O has joined #openstack-meeting | 20:30 | |
*** keshav2 has joined #openstack-meeting | 20:31 | |
*** gholt has joined #openstack-meeting | 20:31 | |
*** littleidea has quit IRC | 20:31 | |
*** kevnfx has joined #openstack-meeting | 20:38 | |
*** romain_lenglet has joined #openstack-meeting | 20:39 | |
*** kevnfx has left #openstack-meeting | 20:41 | |
*** kevnfx has joined #openstack-meeting | 20:41 | |
*** anotherjesse has quit IRC | 20:43 | |
*** jbryce has joined #openstack-meeting | 20:44 | |
*** Youcef has joined #openstack-meeting | 20:48 | |
dendrobates | woohoo 10 minutes to go. | 20:50 |
---|---|---|
*** anotherjesse has joined #openstack-meeting | 20:50 | |
joshuamckenty | We should have some credits run automatically | 20:52 |
* joshuamckenty prompts "My sister got bit by a llama once..." | 20:53 | |
*** adjohn has joined #openstack-meeting | 20:53 | |
*** pvo has joined #openstack-meeting | 20:54 | |
anotherjesse | movie trivia [sponsored by coca cola] asks: what hollywood hulk co-stars with Jennifer Lopez in The Wedding Planner? | 20:55 |
vishy | s/hulk/hunk ? | 20:56 |
anotherjesse | that was a joke (referencing josh's pre-movie credits" | 20:56 |
*** jbarratt has joined #openstack-meeting | 20:56 | |
*** murkk has joined #openstack-meeting | 20:57 | |
*** kevnfx has left #openstack-meeting | 20:57 | |
joshuamckenty | um... | 20:57 |
joshuamckenty | Jim Carey? | 20:58 |
zul | gday | 20:58 |
*** comstud has joined #openstack-meeting | 20:59 | |
jbryce | anotherjesse: lou ferrigno! | 20:59 |
*** kevnfx has joined #openstack-meeting | 21:00 | |
soren | o/ | 21:00 |
vishy | jybryce: lol | 21:00 |
anotherjesse | ok, danceparty time | 21:00 |
*** _0x44 has joined #openstack-meeting | 21:00 | |
joshuamckenty | (dance) | 21:00 |
*** jaypipes has joined #openstack-meeting | 21:00 | |
joshuamckenty | oh, bother. No skype gestures | 21:00 |
dendrobates | I'll give everyone a few minutes to show before we start | 21:00 |
* joshuamckenty sighs. | 21:00 | |
jaypipes | joshuamckenty: whatup? :) | 21:01 |
*** jk0 has joined #openstack-meeting | 21:01 | |
*** creiht has joined #openstack-meeting | 21:01 | |
* joshuamckenty misses his (dance)(party) goodness from skype | 21:01 | |
jaypipes | joshuamckenty: re: CLI options/config processing, see here: http://wiki.openstack.org/CommonOptionsProcessing | 21:02 |
xtoddx | (headbang) | 21:02 |
*** jie has joined #openstack-meeting | 21:02 | |
jaypipes | joshuamckenty: I'll be emailing the ML later this week to officially propose that. | 21:02 |
joshuamckenty | ah, nice, danke (jaypipes ) | 21:02 |
jaypipes | np | 21:02 |
joshuamckenty | do you follow up your blueprints with an ML email? | 21:03 |
joshuamckenty | I've just been abandoning them in the ether ;) | 21:03 |
Rudd-O | OK | 21:03 |
Rudd-O | her eI am | 21:03 |
Rudd-O | -) | 21:03 |
*** pvo has left #openstack-meeting | 21:04 | |
Rudd-O | and so is keshav2 from cloud.com | 21:04 |
jaypipes | joshuamckenty: yes, I do the spec on the wiki, tied to a blueprint. | 21:04 |
dendrobates | #start-meeting | 21:04 |
*** pvo has joined #openstack-meeting | 21:04 | |
jaypipes | joshuamckenty: the ML email is just to notify people of the spec. | 21:04 |
jaypipes | joshuamckenty: and get feedback of course | 21:04 |
dendrobates | #startmeeting | 21:04 |
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 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 21:04 |
dendrobates | oops | 21:04 |
dendrobates | welcome everyone | 21:04 |
dendrobates | as usual the agenda is at http://wiki.openstack.org/Meetings | 21:05 |
dendrobates | #topic old business | 21:05 |
dendrobates | last meetings action items. | 21:05 |
dendrobates | ACTION: 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 |
soren | Oh, dear. | 21:06 |
dendrobates | yes soren? | 21:06 |
jaypipes | dendrobates: I think ewan had that answered... | 21:06 |
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:06 |
dendrobates | Ewan found Apache's policy, that doesn;t have to be ours | 21:07 |
jaypipes | dendrobates: gotcha | 21:07 |
dendrobates | but it probably should | 21:07 |
dendrobates | So my suggestion is that we use APL2 for everything. Any disagreement? | 21:07 |
jaypipes | dendrobates: well pretty much everything in OS is Apache2... | 21:07 |
jaypipes | #agreed | 21:07 |
joshuamckenty | #agreed | 21:07 |
anotherjesse | #agreed | 21:07 |
adjohn | #agreed | 21:07 |
jbryce | #agreed | 21:07 |
xtoddx | #agreed | 21:07 |
joshuamckenty | #agreed Use APL2 for docs as well as source code | 21:08 |
* joshuamckenty thinks that this only works for dendrobates | 21:08 | |
dendrobates | ok let's consider it closed then. | 21:08 |
jaypipes | yep :) | 21:08 |
joshuamckenty | can I propose | 21:08 |
pvo | yay | 21:08 |
dendrobates | I think it works for everyone. | 21:08 |
joshuamckenty | that we dual license with CC0 as well? | 21:08 |
joshuamckenty | just to be annoying? | 21:09 |
creiht | dendrobates: Does that cause any issues with RS cloud docs being CC licensed? | 21:09 |
dendrobates | joshuamckenty: that sounds like extra work. | 21:09 |
jaypipes | creiht: I don't believe so, no. | 21:09 |
dendrobates | does it give us anything? | 21:09 |
_0x44 | dendrobates: Is that extra work for us, or for legal? | 21:09 |
creiht | then find by me | 21:09 |
soren | It sounds like someone volunteering to do extra work, is what I hear. | 21:09 |
anotherjesse | joshuamckenty: yeah - I don't have permisssion to contribute under other licenses | 21:09 |
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 |
joshuamckenty | oh, merde | 21:09 |
joshuamckenty | right | 21:09 |
joshuamckenty | nm | 21:09 |
dendrobates | if we wanted to use the cc with the non-comercial clause that maybe, but I don;t really want that | 21:10 |
jaypipes | KISS. | 21:10 |
joshuamckenty | cc0 is essentially public domain | 21:10 |
jbryce | i say we do 1 for now | 21:10 |
jaypipes | APL2 for all. | 21:10 |
joshuamckenty | it makes it easy to excerpt for books | 21:10 |
dendrobates | ok topic closed. | 21:10 |
jaypipes | the fact that RS cloud docs is CC won't intefere. | 21:10 |
dendrobates | #topic summit | 21:10 |
dendrobates | The next design summit has been announced http://goo.gl/OD4X | 21:10 |
dendrobates | November 9-12 | 21:11 |
dendrobates | in San Antonio TX | 21:11 |
joshuamckenty | why texas? | 21:11 |
jk0 | yeah, I vote Wisconsin | 21:11 |
creiht | hah | 21:11 |
adjohn | Tokyo please :) | 21:11 |
jk0 | :D | 21:11 |
jaypipes | he | 21:11 |
dabo | Honolulu, please | 21:11 |
jaypipes | heh even. | 21:11 |
romain_lenglet | I second for Tokyo | 21:11 |
dendrobates | joshuamckenty: because the kind gentleman that is paying requested it :) | 21:11 |
joshuamckenty | in seriousness, though | 21:11 |
soren | I hear Bahamas is nice in November. | 21:11 |
joshuamckenty | Right | 21:11 |
joshuamckenty | can we start a pool for an alternate location for crocus? | 21:12 |
ttx | ans starts with B | 21:12 |
soren | ttx: Oh, right. | 21:12 |
xtoddx | i vote for New Orleans, so I can split time between opentstack and rubyconf | 21:12 |
zul | montreal | 21:12 |
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 |
dendrobates | this is Rackspaces chance to show off our headquarters | 21:12 |
dendrobates | yes it is fixed | 21:12 |
dendrobates | Please register your attendance on Launchpad at http://goo.gl/nw5G | 21:12 |
jaypipes | dendrobates: ah, ok. missed that, sorry. | 21:13 |
dendrobates | It is free and open to everyone, but we need to know if your coming. | 21:13 |
dendrobates | Info about blueprints and sessions will eventually appear at http://wiki.openstack.org/Summit/Bexar | 21:13 |
pvo | dendrobates: | 21:13 |
dendrobates | pvo: yes | 21:13 |
pvo | er do RS folks need to register? | 21:13 |
dendrobates | yes, it would be helpful for scheduling. | 21:13 |
pvo | ok | 21:13 |
dendrobates | you'll be able to mark yourself as required for certain blueprint discussions | 21:14 |
anotherjesse | dendrobates: the nasa folks are pushing through the paperwork to go | 21:14 |
*** captcha12 has joined #openstack-meeting | 21:14 | |
jaypipes | #action: ALL register for summit if going at http://goo.gl/nw5G | 21:14 |
dendrobates | anotherjesse: there may be a chance of sponsorship for key individuals that cannot get funding to attend. | 21:14 |
dendrobates | let me know if anyone needs help, but no promises | 21:15 |
jaypipes | dendrobates: k, on to orm-refactor? :) | 21:15 |
dendrobates | #topic ORM refactoring | 21:16 |
dendrobates | So I am guessing most people saw my email to the ml | 21:16 |
* jaypipes would like to get resolution on this and get it merged today or tomorroww... | 21:16 | |
* anotherjesse too | 21:16 | |
*** littleidea has joined #openstack-meeting | 21:16 | |
dendrobates | ok so.... | 21:16 |
* joshuamckenty also | 21:16 | |
jaypipes | lots of stuff held up for it right now.. | 21:16 |
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 |
* joshuamckenty concurs | 21:17 | |
jaypipes | #agreed | 21:17 |
jbryce | #agreed | 21:17 |
anotherjesse | #agreed | 21:17 |
pvo | #agreed | 21:17 |
_0x44 | #agreed | 21:17 |
comstud | #agreed | 21:17 |
vishy | #agreed | 21:17 |
* joshuamckenty has deep secret love for redis | 21:17 | |
soren | #agreed | 21: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 | #agreed | 21:17 |
xtoddx | #agreed with joshuamckenty's secret love | 21:17 |
dendrobates | any dissension | 21:17 |
vishy | :( | 21:17 |
soren | joshuamckenty: So you're doing the Redis backend? :) | 21:17 |
anotherjesse | so we aren't supposed to do a #agreed to vote? | 21:17 |
jaypipes | dendrobates: I will go ahead and create a blueprint for the re-addition of a noSQL adapter. | 21:18 |
vishy | fine then: #disagreed | 21:18 |
jaypipes | dendrobates: if ok with you? | 21:18 |
joshuamckenty | soren, I did it the first time :) | 21:18 |
soren | anotherjesse: I think the idea is that the chair uses it to denote what was agreed. | 21:18 |
soren | joshuamckenty: So you've got practice. | 21:18 |
dendrobates | #action create a blueprint for the re-addition of a noSQL adapter. | 21:18 |
jbryce | anotherjesse: you can use it to vote, but it won't get summarized | 21:18 |
joshuamckenty | soren, good point | 21:18 |
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 |
jaypipes | anotherjesse: yup. | 21:19 |
dendrobates | soren we'll get the voting right next time. | 21:19 |
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 |
jaypipes | anotherjesse: though the fakeldap stuff may be the bigger foobar. | 21:19 |
dendrobates | It is not about redis. | 21:19 |
jbryce | i think it's more about shared nothing no spof | 21:19 |
dendrobates | it's more about how we drop something from openstack, imho | 21:20 |
jaypipes | eday: not redis specifically. could be memcache as far as I care... | 21:20 |
anotherjesse | jaypipes: the fake ldap eventually needs to be pluggable user system - eg backend to mysql or redis or ldap or ... | 21:20 |
_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 |
jaypipes | anotherjesse: ++ | 21:20 |
dendrobates | _0x44: exactly | 21:20 |
jaypipes | _0x44: yup. | 21:20 |
eday | dendrobates: well, I think we still have the luxery of not having to worry about that until Austin is released :) | 21:20 |
_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 |
eday | 100% agree we need to deprecate once we have something we say we support, but we've not yet | 21:21 |
jaypipes | eday: so you are saying prioritize the fakeldap rework over the re-addition of a noSQL adapter? just trying to understand... | 21:21 |
jaypipes | eday: if fakeldap didn't depend on redis, there would be no redis dependency. | 21:21 |
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:21 |
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 |
jaypipes | anotherjesse: I know, what I'm saying is that the fakeldap piece is the last remaining dependency on redis IINM | 21:22 |
*** gundlach has joined #openstack-meeting | 21:22 | |
joshuamckenty | jaypipes: so we need two patches | 21:22 |
joshuamckenty | one to be off of redis entirely, and one to put it back in | 21:23 |
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 |
jaypipes | joshuamckenty: right, and I believe eday is trying to say it's better to be off redis entirely. right, eday? | 21:23 |
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 |
jaypipes | joshuamckenty, eday: b/c then we could de-prioritize the re-adding of the nosql driver? | 21:23 |
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 |
dendrobates | then we make a blueprint stating that and discuss it in November and deprecate it. | 21:24 |
_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 |
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 |
gundlach | _0x44: i disagree with that | 21:24 |
joshuamckenty | #1 is a problem | 21:24 |
_0x44 | gundlach: You disagree that it could be used? | 21:24 |
joshuamckenty | because we're not just removing a dependency, we're adding one | 21:25 |
_0x44 | gundlach: Or that it should be prioritized? | 21:25 |
joshuamckenty | we're adding a SQL dependency where we didn't have one before | 21:25 |
jaypipes | joshuamckenty: is it a problem if there is no more redis-dependent code before Austin release? | 21:25 |
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 |
anotherjesse | jaypipes: not for us | 21:25 |
dendrobates | I think it is a priority and we have a volunteer to do it: jaypipes | 21:25 |
jaypipes | anotherjesse: meaning there is not a problem? or there is? | 21:25 |
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:25 |
dendrobates | it should not affect anyone else | 21:26 |
anotherjesse | jaypipes: there isn't a problem with not having redis - nebula doesn't use it | 21:26 |
joshuamckenty | anymore | 21:26 |
* joshuamckenty sniffs | 21:26 | |
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 |
dendrobates | re-adding of a nosql driver | 21:26 |
anotherjesse | jaypipes: vish and I will help | 21:27 |
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 |
jaypipes | anotherjesse: cheers :) | 21:27 |
jaypipes | eday: correct? | 21:27 |
dendrobates | we can then discuss all of this at the summit. I will make the blueprint myself. | 21:27 |
jaypipes | dendrobates: so, not for Austin, then... | 21:27 |
dendrobates | no, I mean discuss deprecating redis support | 21:28 |
jaypipes | ah... | 21:28 |
jbryce | so for austin, re-add a nosql driver; for future release discuss necessity of nosql support | 21:28 |
dendrobates | jbryce: exactly | 21:28 |
eday | if we are ok dropping redis, what is the technical reason to add some other NoSQL store? | 21:28 |
joshuamckenty | there was no concensus (lazy or otherwise) yet on dropping redis | 21:28 |
eday | I don't see any, especially given that we're moving towards a relational model with the ORM branch | 21:28 |
anotherjesse | proving that we aren't pushing sql assumptions into the data? | 21:28 |
joshuamckenty | there's simply a patch to add SQL support | 21:28 |
anotherjesse | data layer | 21:28 |
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:28 |
eday | joshuamckenty: it doesn't just add SQL, it reworks the entire data model and removes redis because fundamental things changed :) | 21:29 |
joshuamckenty | right, but that wasn't the goal of the patch (to remove redis). It was to add an ORM | 21:29 |
jaypipes | joshuamckenty: ya, eday is right on that one. | 21:29 |
anotherjesse | it was to make the data model explicit | 21:29 |
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 |
anotherjesse | and API interaction with it | 21:30 |
joshuamckenty | there was an earlier (unfinished) effort to make the data model more explicit on top of redis | 21:30 |
jaypipes | sorry, but I'm going to agree with eday on this one... | 21:30 |
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 |
dendrobates | the my reasons from the ml: | 21:30 |
joshuamckenty | we abandoned that at NASA b/c we had to switch from redis for security reasons | 21:30 |
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 |
dendrobates | * OpenStack should avoid making technical decisions for implementers. | 21:30 |
dendrobates | We should only mandate a technology if we have to, for reasons like | 21:30 |
dendrobates | uniformity of the code, i.e the twisted debate, or because choice would | 21:30 |
dendrobates | be difficult to implement. | 21:30 |
jaypipes | creiht: right. | 21:31 |
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 |
joshuamckenty | i disagree | 21:31 |
joshuamckenty | without two plugins, a plugin architecture is just a myth | 21:31 |
jaypipes | joshuamckenty: true. | 21:31 |
joshuamckenty | and if both plugins are SQL-shaped, | 21:31 |
joshuamckenty | then you're tied to SQL | 21: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 totally | 21:31 |
creiht | so write a null plugin :) | 21:31 |
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 |
dendrobates | release, but good policy is good policy. | 21:31 |
xtoddx | but the data interface layer has no assumptions about being in sql, its just hashes | 21:31 |
xtoddx | or dicts, rather | 21:32 |
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 |
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 |
creiht | dendrobates: when was the first release that required redis? :) | 21:32 |
jaypipes | dendrobates: yes, you are correct... I'm torn on this decision, like I mentioned on the ML.. :( | 21:32 |
jbryce | eday: everyone already agreed to merge the orm branch | 21:32 |
joshuamckenty | creiht: it was nova 0.6 | 21:32 |
*** klord has quit IRC | 21:32 | |
dendrobates | we should not make security decisions for implementors | 21:32 |
creiht | dendrobates: and I agree with stable, non-beta products | 21:32 |
joshuamckenty | IIRC | 21:32 |
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 |
dendrobates | for example you can compile Apache with -DBIG_SECURITY_HOLE | 21:33 |
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 |
anotherjesse | it is a "should have" not a "must have" | 21:33 |
joshuamckenty | agreed | 21:34 |
xtoddx | +1 | 21:34 |
eday | jbryce: I thought it sounded like some folks wanted to wait and discuss in November | 21:34 |
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 |
jbryce | eday: i think the discussion is around long-term inclusion of redis or other nosql rather than blocking the orm branch | 21:34 |
jaypipes | anotherjesse: this whole argument is between "should have" and "must have". :) there's a good argument on both sides I think. | 21:34 |
dendrobates | eday: we have agreed to merge orm-refactor | 21:34 |
eday | jbryce: yup, just thought it had regressed for a second :) | 21:35 |
jbryce | #info we will merge orm refactor for austin | 21:35 |
jaypipes | dendrobates: OK, so...why don't we do this... take a vote for "should have" vs. "must have" (for Austin) | 21:35 |
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 |
jaypipes | anotherjesse: right, but this is all about Austin | 21:35 |
jbryce | #info discussion required at november design summit around long-term inclusion or deprecation of support for redis/nosql datastores | 21:36 |
jaypipes | anotherjesse: which has a certain timeframe :) | 21:36 |
dendrobates | I think we can get it done. | 21:36 |
joshuamckenty | so we need the same vote for the fakeldap backend | 21:36 |
jaypipes | jbryce: yup, good #info. | 21:36 |
joshuamckenty | e.g., getting that off redis as well | 21:36 |
jaypipes | joshuamckenty: that would be easy enough... | 21:36 |
dendrobates | joshuamckenty: is there a fakeldap branch? | 21:36 |
joshuamckenty | there's a fakeldap module | 21:36 |
joshuamckenty | I don't know if there's a branch | 21:36 |
jaypipes | dendrobates: no, it's a module. | 21:37 |
dendrobates | so this is work that is not done yet. | 21:37 |
dendrobates | and it is only for fakeldap | 21:37 |
*** anotherjesse has quit IRC | 21:37 | |
joshuamckenty | well, that's what I meant by saying the goal was not redis removal | 21:37 |
jaypipes | joshuamckenty, vishy: we could try using dataflake.ldapconnection.tests.fakeldap... | 21:37 |
joshuamckenty | ooh, interesting. Or we could go back to keeper :) | 21:38 |
captcha12 | what is the fakeldap branch? | 21:38 |
* joshuamckenty ducks | 21:38 | |
jaypipes | ha! | 21:38 |
jaypipes | captcha12: it's a module used in tresting nova. | 21:38 |
joshuamckenty | nothin like serializing json on disk | 21:38 |
joshuamckenty | so vote for "must have"? | 21:38 |
joshuamckenty | #disagree | 21:39 |
dendrobates | -1 | 21:39 |
gundlach | #disagree | 21:39 |
xtoddx | -1 on "must" | 21:39 |
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 |
_0x44 | -1 | 21:39 |
vishy | jaypipes: sure, it needs to support very little | 21:39 |
jaypipes | #disagree | 21:39 |
jaypipes | vishy: not disagreeing with you! ;) | 21:39 |
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 |
jaypipes | jbryce: no, the must have option is to have rediis/nosql support in Austin's relaease | 21:40 |
gundlach | jbryce: um, i thought 'must' vs 'should' were backwards from your descriptions. | 21:40 |
jbryce | hmm...got my must have and should have backwards, didn't i? | 21:40 |
vishy | #disagree on must have | 21:40 |
xtoddx | i almost feel like redis is a solution looking for a problem, does anyone actually want to run on it? | 21:40 |
joshuamckenty | yes | 21:40 |
joshuamckenty | I do | 21:40 |
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:40 |
xtoddx | do you want to write it before austin? | 21:41 |
vishy | i think a day of hacking using the old BasicModel will make it work | 21:41 |
jaypipes | OK, so we are #agreed that redis/nosql support is a SHOULD HAVE for Austin. | 21:41 |
joshuamckenty | dude, I'm modelling earthquakes. < xtoddx | 21:41 |
xtoddx | joshuamckenty: wanna talk vish into writing it before austin | 21:41 |
joshuamckenty | yup | 21:41 |
jaypipes | what 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 Austin | 21:41 |
vishy | hehe | 21:42 |
xtoddx | #agreed! | 21:42 |
vishy | thx josh | 21:42 |
joshuamckenty | #agreed | 21:42 |
*** maple_bed has joined #openstack-meeting | 21:42 | |
dendrobates | #disagree, it's only used for testing | 21:42 |
_0x44 | Doesn't the outcome of fakeldap depend on whether or not redis is added back? | 21:42 |
joshuamckenty | not really | 21:42 |
dendrobates | _0x44: no it is separate from the data model | 21:42 |
jaypipes | dendrobates: OK, but recognize that the fakeldap module is the last remaining redis dependent code. | 21:43 |
soren | Uh, it's not just used for testing. | 21:43 |
joshuamckenty | I think we're about to spend more time discussing it than the patch will take | 21:43 |
dendrobates | I say should have. If it comes down to other features, I say drop it | 21:43 |
xtoddx | #agreed joshuamckenty | 21:43 |
jaypipes | dendrobates: without the fakeldap redis dependency, we could theoretically release Austin with no Redis dependency. | 21:43 |
dendrobates | joshuamckenty: ha | 21:43 |
jbryce | soren: what else is it used for? | 21:44 |
joshuamckenty | #info xtoddx will cherry pick the old (pre-redis) fakeldap forward as a patch | 21:44 |
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 |
dendrobates | soren: fakeldap is used for more than production? | 21:44 |
soren | It's the default in the Ubuntu packages, for instance. | 21:44 |
dendrobates | er testing | 21:44 |
dendrobates | oh | 21:44 |
joshuamckenty | ooh... we could make fakeldap back onto SQL, and use it as a performance test of the DB ;) | 21:45 |
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 |
*** maple_bed has left #openstack-meeting | 21:45 | |
jaypipes | soren: but fakeldap requires redis :) | 21:45 |
joshuamckenty | lol | 21:45 |
jaypipes | I love this catch22 ;) | 21:45 |
xtoddx | jaypipes: we can get off of redis though, maybe move into the db.api layer | 21:46 |
soren | jaypipes: It does, yes. | 21:46 |
soren | jaypipes: I never said it didn't :) | 21:46 |
jaypipes | it's the code equivalent of a Chinese finger-trap. | 21:46 |
dendrobates | yeah, but it's not our fingers we got stuck | 21:46 |
eday | soren: well, then your argument above contradicts itself, since it's the only thing using redis, no? | 21:46 |
jbryce | so it's a must have to get fakeldap working without redis if redis is not a must have | 21:46 |
dendrobates | soren: so what are you suggesting? | 21:46 |
soren | eday: Well, the orm branch hasn't been merged yet :) | 21:47 |
jaypipes | jbryce: thus the catch22 ;) | 21:47 |
soren | dendrobates: That someone makes the fakeldap thing hook into the ORM. | 21:47 |
eday | soren: it will be, that was already decided, and redis is gone for that end :) | 21:47 |
dendrobates | jbryce: they are unrelated | 21:47 |
soren | dendrobates: 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 |
xtoddx | 1) merge orm, 2) move fakeldap into the db layer, 3) make a nosql db layer driver | 21:47 |
xtoddx | right? | 21:48 |
soren | eday: sorry, I'm having a hard time keeping up :) | 21:48 |
dendrobates | xtoddx: correct | 21:48 |
joshuamckenty | eday: this is what I was pointing out earlier, when I explained that ORM change wasn't about removing redis | 21:48 |
creiht | Or you could use ldap as your data store, and all your problems are solved :) | 21:48 |
jaypipes | xtoddx: thank you for your clarity. YES! | 21:48 |
vishy | easier would be kill fakeldap and just make an AuthDriver that backends to orm | 21:48 |
eday | joshuamckenty: yeah, I was thinking about just non-auth before. I knoew auth was still using it for fake | 21:48 |
xtoddx | vishy: true | 21:48 |
jaypipes | vishy: already done with repoze.what.sql :) | 21:48 |
joshuamckenty | xtoddx: what's the current cacheing layer on auth? | 21:48 |
dendrobates | so lets get volunteers for each part and end this. | 21:49 |
jaypipes | dendrobates: ++ | 21:49 |
dendrobates | talk with your code. | 21:49 |
xtoddx | joshuamckenty: the middleware uses the memcached middleware bundled with swift, but nothing durable | 21:49 |
eday | jaypipes, so, you have it done and solved? :) | 21:49 |
jaypipes | eday: what part? repoze.what.sql? | 21:49 |
dendrobates | let's stay on topic. | 21:50 |
jbryce | #action vishy will add redis support in using BasicModel, hopefully in time for Austin | 21:50 |
eday | jaypipes: the auth/fake ldap replacement | 21:50 |
dendrobates | move fakeldap into the db layer: volunteer? | 21:50 |
jbryce | joshuamckenty also volunteered xtoddx to make fakeldap not depend on redis | 21:50 |
xtoddx | i'll do it, it should be quick | 21:50 |
jbryce | #action xtoddx to move fakeldap into db layer | 21:50 |
soren | \o/ | 21:51 |
xtoddx | i'll kill fakeldap and just make a new auth driver that can be default in ubuntu packages | 21:51 |
dendrobates | make a nosql db layer driver: | 21:51 |
dendrobates | jaypipes: are you taking that? | 21:51 |
jaypipes | xtoddx: please take a looksie at repoze.who and repoze.what. | 21:51 |
jaypipes | dendrobates: sure. | 21:51 |
xtoddx | jaypipes: links? | 21:51 |
jaypipes | dendrobates: but I think vishy already has that? | 21:51 |
joshuamckenty | I believe anotherjesse and vishy offered to play in as well | 21:51 |
jbryce | jaypipes: that's what it said earlier in the chat so i just copied it into an action.... | 21:52 |
jaypipes | xtoddx: http://docs.repoze.org/who/1.0/ | 21:52 |
dendrobates | ok all can play, but I';ll hold jaypipes responsible. | 21:52 |
jaypipes | dendrobates: OK, so vishy, anotherjesse and me. | 21:52 |
jaypipes | dendrobates: cool. | 21:52 |
joshuamckenty | (well, technically *I* offered for vishy to play in, but who's counting) | 21:52 |
xtoddx | jaypipes: thanks | 21:52 |
dendrobates | #action vishy, jaypipes and anotherjesse to make a nosql db layer driver | 21:53 |
jaypipes | xtoddx: http://what.repoze.org/docs/1.0/ | 21:53 |
dendrobates | so we have agreement | 21:53 |
jaypipes | yup | 21:53 |
jbryce | is someone going to take point on getting the orm merge in? | 21:53 |
eday | jbryce: I can just go mark as approved right now | 21:54 |
jaypipes | jbryce: it's automated. just have to set the merge prop to approve. | 21:54 |
jaypipes | eday: do it! get to the chopper! | 21:54 |
vishy | eday: adding a little patch for networking but i can propose it after | 21:54 |
jbryce | jaypipes, eday: yep...just wanted to make sure it didn't get lost in the shuffle | 21:54 |
vishy | there will need to be a few things fixed after merge | 21:54 |
eday | any objects to landing it now? | 21:54 |
jaypipes | jbryce: :) | 21:54 |
jaypipes | eday: nope. | 21:54 |
dendrobates | Let's make sure we've had the proper review. | 21:54 |
eday | err, objections | 21:54 |
jaypipes | dendrobates: it's been reviewed a lot. | 21:54 |
eday | dendrobates: this discussion was the last "review" | 21:55 |
jaypipes | dendrobates: termie and me did a full review as well as eday I believe and soren. | 21:55 |
soren | +1 | 21:55 |
soren | It's good stuff. Merge it :) | 21:55 |
dendrobates | jaypipes: thanks, I hadn;t checked | 21:55 |
dendrobates | ok, go! | 21:55 |
eday | ok, marking it | 21:55 |
jaypipes | dendrobates: no worries :) | 21:55 |
dendrobates | I smell a broken build email | 21:55 |
jbryce | haha | 21:55 |
eday | probably :) | 21:56 |
dendrobates | topic closed | 21:56 |
dendrobates | #topic meeting time | 21:56 |
eday | did we need to discuss xtoddx's auth branch too, or save that for later? | 21:56 |
dendrobates | same time next week? | 21:56 |
dendrobates | eday: ml | 21:57 |
adjohn | +1 | 21:57 |
zul | can i make a suggest an hour earlier? | 21:57 |
adjohn | please no :( | 21:57 |
vishy | i have about 4 branches based on orm which will need review as well :) | 21:57 |
dendrobates | zul: you can if you want ninjas from japan to behead you | 21:57 |
zul | dendrobates: i would pay to see that | 21:57 |
soren | zul: You can't see ninjas. | 21:58 |
zul | soren: right | 21:58 |
dendrobates | #action everyone do code reviews | 21:58 |
ttx | zul: look behind you. | 21:58 |
dendrobates | #endmeeting | 21:58 |
openstack | Meeting ended Tue Sep 14 21:58:35 2010 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:58 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2010/openstack-meeting.2010-09-14-21.04.html | 21:58 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2010/openstack-meeting.2010-09-14-21.04.txt | 21:58 |
openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2010/openstack-meeting.2010-09-14-21.04.log.html | 21:58 |
creiht | yay | 21:58 |
* jaypipes waits for adjohn to spring into ninja action. | 21:59 | |
eday | whew | 21:59 |
dendrobates | these things are difficult to discuss on IRC, the summit will help us out a lot. | 21:59 |
adjohn | jaypipes: when you least expect it ;) | 21:59 |
jaypipes | wasn't that bad :) | 21:59 |
jaypipes | adjohn: :) | 21:59 |
dendrobates | we would have had much less confusion. | 21:59 |
* jaypipes blames all confusion on dendrobates | 21:59 | |
jaypipes | heh | 21:59 |
*** kevnfx has quit IRC | 22:00 | |
dendrobates | everyone else was confused. I am always right, even when I'm wrong. :) | 22:00 |
eday | dendrobates: 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 |
joshuamckenty | there is no "we" | 22:00 |
dendrobates | ther is no spoon | 22:01 |
joshuamckenty | exactly | 22:01 |
jaypipes | joshuamckenty: thank you Yoda. ;P | 22:01 |
jk0 | there is also no santa | 22:01 |
joshuamckenty | dude | 22:01 |
jaypipes | jk0: damn it. spoiler. | 22:01 |
joshuamckenty | how can you be so HURTFUL? | 22:01 |
jaypipes | joshuamckenty: hehe | 22:01 |
joshuamckenty | but I agree with eday generally | 22:01 |
jaypipes | ya | 22:01 |
joshuamckenty | even if we clearly identify where we're divergent | 22:02 |
eday | we really need to identify the long-term "what" before deciding anything :) | 22:02 |
eday | at least, as best we can | 22:02 |
*** jie has quit IRC | 22:02 | |
*** creiht has left #openstack-meeting | 22:02 | |
*** romain_lenglet has quit IRC | 22:03 | |
*** pvo has left #openstack-meeting | 22:03 | |
*** captcha12 has quit IRC | 22:03 | |
*** jk0 has left #openstack-meeting | 22:04 | |
*** gholt has left #openstack-meeting | 22:07 | |
*** dabo has quit IRC | 22:07 | |
*** joshuamckenty has left #openstack-meeting | 22:07 | |
*** xtoddx has left #openstack-meeting | 22:18 | |
*** murkk has left #openstack-meeting | 22:20 | |
*** adjohn has quit IRC | 22:31 | |
*** gundlach has quit IRC | 22:53 | |
*** gundlach has joined #openstack-meeting | 22:57 | |
*** dendrobates is now known as dendro-afk | 23:13 | |
*** gasbakid has joined #openstack-meeting | 23:16 | |
*** gundlach has quit IRC | 23:39 | |
*** Rudd-O has quit IRC | 23:39 | |
*** Youcef has quit IRC | 23:51 | |
*** Rudd-O has joined #openstack-meeting | 23:52 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!