16:01:27 <jgriffith> #startmeeting cinder
16:01:28 <openstack> Meeting started Wed May  1 16:01:27 2013 UTC.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:30 <bswartz> hi
16:01:32 <openstack> The meeting name has been set to 'cinder'
16:01:34 <varma> hi
16:01:35 <hemna> morning
16:01:36 <eharney> hi
16:01:39 <xyang> hi
16:01:41 <med_> \o
16:01:49 <jgriffith> Hey everyone.. good slushy morning to you
16:01:51 <DuncanT> hey
16:01:56 <med_> indeed, very slushy
16:01:56 <jungleboyj> Morning / evening to you all.
16:02:27 * bswartz wonders if he's missing something
16:02:30 <jgriffith> So here's the agenda for today: https://wiki.openstack.org/wiki/CinderMeetings
16:02:42 <jgriffith> bswartz: it's rain/snow mix in Colorado this morning
16:02:47 <jgriffith> bswartz: very unpleasant
16:02:49 <med_> lots of snow
16:02:50 <bswartz> ah, that's too bad
16:03:00 <hemna> nice and warm here today :)
16:03:04 <jungleboyj> Word is you guys are sending that our way jgriffith.  :-(
16:03:12 <jgriffith> hemna: rub it in
16:03:14 <med_> heh, good for farmers, etc.  Not too bad.
16:03:31 <jgriffith> I'm happy... I'll have hay this year, but at any rate... we digress :)
16:03:42 <jgriffith> #topic bp status updates
16:04:13 <jgriffith> Take a look at https://launchpad.net/cinder/havana
16:04:38 <jgriffith> Or better yet: https://blueprints.launchpad.net/cinder/havana
16:05:12 <jgriffith> I believe that's a pretty comprehensive list of what we talked about at the summit
16:05:26 <jgriffith> but if there are things missing please do let me know or get something proposed ASAP
16:05:37 <jgriffith> kmartin: I did not approve yours yet
16:05:40 <bswartz> jgriffith: pls add the share service blueprint
16:05:45 <DuncanT> Moving big I/O jobs out to a worker process
16:06:13 <jgriffith> kmartin: I had an equivalent but folks from NetApp protested so I removed it for now
16:06:32 <jgriffith> kmartin: I'm also not sure about having a Copyright on a blueprint TBH :)
16:06:33 <bswartz> jgriffith: https://blueprints.launchpad.net/cinder/+spec/file-shares-service
16:07:12 <jgriffith> DuncanT: ahh.. yes
16:07:15 <hemna> jgriffith, ok so you are going to do the state machine?
16:07:17 <jgriffith> part of the migration bp
16:07:21 <eharney> lio-support-via-targetd may be changing shape a bit from the original plan
16:07:41 <jgriffith> eharney: changes are *ok* just so we have something recorded
16:07:48 <jgriffith> eharney: or do you mean like "not doing it that way"
16:07:53 <hemna> and where is the "brick" BP ?
16:08:09 <jgriffith> hemna: brick is broken out into 4 or 5 sub-bps
16:08:22 <hemna> ok
16:08:24 <jgriffith> hemna: we'll go from there on how it gets packaged/distributed
16:08:33 <jungleboyj> jgriffith: We are working on getting DB2 support in Havana.  Any chance we can get that BP here too?
16:08:36 <eharney> jgriffith: looking at leveraging libstoragemgmt rather than writing a driver that uses jsonrpc with targetd -- so, still supports targetd, but may do other stuff too
16:08:37 <jgriffith> hemna: may be oslo, may be our own pypi upload etc
16:08:37 <DuncanT> jgriffith: I'll probably separate the I/O worker into a blueprint of its own
16:09:01 <jgriffith> eharney: that should be fine, feel free to update whiteboard etc as you go along
16:09:09 <eharney> jgriffith: ok i'll add some notes now
16:09:14 <jgriffith> DuncanT: is the milestone ok with you?
16:09:27 <jgriffith> eharney:
16:09:31 <jgriffith> not DuncanT sorry
16:09:45 <jgriffith> eharney: I wanted to check with you but took a chance and made it H2
16:10:13 <jgriffith> eharney: It would really be nice to have it in sooner rather than later and get it tested
16:10:22 <jgriffith> eharney: I'd also like to consider making LIO default
16:10:34 <jgriffith> eharney: so the more time on all of these different pieces in test the better
16:10:55 <eharney> jgriffith: hmm, certainly possible, i'll say stick with H2 for now and i'll let you know if concerns arise
16:11:07 <jgriffith> eharney: sounds fair
16:11:31 <jgriffith> hemna: I assigned state-machines to myself
16:11:31 <kmartin> jgriffith: sorry, I was late today. HP is requiring that we add the copyright to the blueprints.
16:11:45 <jgriffith> hemna: however if there's an interest or somebody gets to it first we can reassign
16:12:00 <jgriffith> kmartin: no worries, we'll just use the other version then :)
16:12:08 <DuncanT> The other blueprint that is missing is anything volume-encryption related
16:12:15 <jgriffith> DuncanT: haha :)
16:12:15 <hemna> ok I was kinda interested in helping with that and the brick project
16:12:26 <hemna> I have cycles to work on it at least
16:12:33 <jgriffith> hemna: yes... I put you down for the attach bp of course
16:12:46 <jgriffith> hemna: and there's going to be some other things I think that are going to creep in there
16:12:58 <hemna> we should just get together at some point and iron out the direction, if you want me to help.
16:13:03 <jgriffith> hemna: but we can sync up and work together
16:13:07 <jgriffith> hemna: :)
16:13:09 <hemna> ok sounds great.
16:13:10 <jgriffith> agreed
16:13:23 <jgriffith> DuncanT: back to encryption
16:13:27 <jgriffith> DuncanT: sighhhh
16:13:47 <jgriffith> DuncanT: we need to figure out what to do there
16:13:56 <med_> words can be copywritten. Just makes it hard when someone needs to go in and change the blueprint, likely need to add their own copyright atop.
16:14:12 <jgriffith> Let's have a topic later in the meeting to talk a bit about that
16:14:12 <med_> s/atop/below/
16:14:31 <DuncanT> jgriffith: I'll ping the guys from the summit and see if we can get a revised design sketched up
16:14:35 <jgriffith> med_: indeed... and really the product of a summit session doesn't really seem to get an HP copyright IMO
16:14:56 <jgriffith> DuncanT: I also recieved an email from them last night about a meeting to go through things again
16:14:57 <DuncanT> jgriffith: It has so many dependencies I'd be surprised if it gets sorted this cycle TBH
16:14:58 <med_> jgriffith, completely agree.
16:15:23 <jgriffith> Ok... so we were missing:
16:15:28 <DuncanT> jgriffith: I'm certainly interested in talking to them again... some sensible ideas were starting to fall out at the end
16:15:33 <jgriffith> 1. encryption (which is kinda TBD on how that looks)
16:15:59 <jgriffith> 2. and kinda missing the worker service (I've commented in Avishay's BP to break that up and add those sorts of details)
16:16:05 <jgriffith> Anything else?
16:16:27 <eharney> i will likely be submitting another one related to Gluster
16:16:47 <eharney> related to QEMU direct gluster support
16:16:48 <jgriffith> eharney: sure... sooner is better than later but I expect we'll have new ideas as we go along
16:17:00 <rushiagr> jgriffith: the share service blueprint
16:17:11 <jgriffith> rushiagr: bswartz yes I haven't forgotten you
16:17:34 <jgriffith> rushiagr: bswartz I'm cursious to learn more about the gluster changes and why they can make things work without a separate service
16:17:57 <jgriffith> rushiagr: bswartz also would like to find out if there's a way for you to collaborate with eharney and the folks from IBM that want GPFS
16:18:01 <thingee> jgriffith: are we onto new proposals now?
16:18:14 <jgriffith> thingee: sure
16:18:16 <jgriffith> :)
16:18:23 <thingee> if we're talking about what's missing
16:18:27 <med_> [topic] new BPs
16:18:31 <bswartz> jgriffith: we haven't done anything w/ gluster yet
16:18:44 <jgriffith> bswartz: let's come back
16:18:53 <jgriffith> #topic new bp's that we missed
16:19:04 <jgriffith> thingee: please go ahead
16:19:26 <thingee> switch to another web frame work and no pissing off ops in the upgrade
16:19:34 <jgriffith> thingee: haha!
16:19:40 <hemna> :)
16:19:45 <jgriffith> thingee: I can't believe I missed that one
16:19:55 <thingee> jgriffith: I just added it last night
16:19:56 <jgriffith> thingee: we already planned on doing it and going forward
16:19:56 <hemna> what are the other projects doing wrt the web frameworks?
16:19:58 <rushiagr> i had a chat with eharney yestday, and he seemed interested in shares service work
16:20:02 <jgriffith> thingee:  :)
16:20:10 <thingee> jgriffith: been pushing hard at work for switching to new projects ;)
16:20:12 <eharney> yes, i am going to try to get involved there
16:20:51 <jgriffith> eharney: rushiagr bswartz I promise I'll get to your shares service
16:20:54 <jgriffith> be patient
16:21:10 <rushiagr> jgriffith: cool
16:21:33 <jgriffith> thingee: link to your BP?
16:21:55 <thingee> https://blueprints.launchpad.net/cinder/+spec/web-framework-switch
16:22:33 <jgriffith> thingee: cool... thoughts on delivery milestone?
16:22:44 <thingee> oh man would I love h1
16:22:59 <thingee> don't think there would be enough time for reviewing though at this point
16:23:05 <xyang> thingee: does this support both python 3 and 2
16:23:08 <hemna> the sooner the better :)
16:23:09 <jgriffith> thingee: hehe me too... I can target it for H1, but that might be ambitious
16:23:15 <thingee> xyang: both
16:23:23 <thingee> we should be moving towards py3 compatible
16:23:34 <jgriffith> thingee: let's do H2 with the hope of seeing it very early
16:23:48 <jgriffith> thingee: seem reasonable?
16:24:15 <thingee> early is my goal of course so we have people catching any issues.
16:24:16 <thingee> sure
16:24:28 <thingee> I might just surprise y'all
16:24:41 <jgriffith> thingee: I won't be surprised :)
16:24:47 <med_> does that answer the question: Does pecan force a Python3 version change?
16:24:50 <jgriffith> thingee: I have high expectations :)
16:25:03 <jgriffith> med_: it doesn't force it no
16:25:06 <med_> nod.
16:25:11 <jgriffith> but I'll let thingee answer
16:25:13 <xyang> thingee: do we eventually need to rewrite everything in python 3?
16:25:18 <thingee> jgriffith: correct
16:25:24 <jgriffith> xyang: no
16:25:29 <thingee> xyang: that's a goal for sure
16:25:34 <thingee> maybe early I
16:25:37 <xyang> ok, good
16:25:37 <jgriffith> thingee: ?
16:25:38 <thingee> release
16:25:58 <jgriffith> xyang: thingee maybe I'm not clear on the question
16:26:09 <thingee> jgriffith: py3 compatible in cinder core, but not deps in early I
16:26:16 <jgriffith> thingee: k
16:26:28 <jgriffith> py3 compat is different than rewrite in py3 IMO
16:26:29 <jgriffith> :)
16:26:30 <thingee> jgriffith: lets shoot for getting rid of xml template crud in H2
16:26:32 <thingee> using wsme
16:26:40 <jgriffith> yep, sounds good
16:26:43 <thingee> I gotta make the bp to talk about that some more
16:26:59 <jgriffith> xyang: there's an OS wide effort to start working on py3 compat as well this cycle
16:27:08 <thingee> I've been mainly spending my time over the weekend trying to get paste to still be fine with the pecan stuff so people don't need to make config changes
16:27:39 <xyang> griffith: I saw that.  Not sure about the details.
16:27:50 <thingee> that is all for me.
16:28:10 <jgriffith> thingee: thx
16:28:41 <jgriffith> xyang: there's a subteam of folks volunteering to work on it
16:28:59 <jgriffith> xyang: not much detail yet but there's an etherpad of the session outcomes out there
16:29:00 <xyang> jgriffith: ok
16:29:15 <jungleboyj> jgriffith: Is this an appropriate time for me to put my plug for the DB2 BP?
16:29:16 <xyang> jgriffith: sure, I'll check it out
16:30:08 <jgriffith> jungleboyj: sure
16:30:15 <jgriffith> #topic DB2 BP
16:30:19 <jgriffith> jungleboyj: link please
16:30:25 <jungleboyj> https://blueprints.launchpad.net/cinder/+spec/db2-database
16:31:14 <jgriffith> jungleboyj: so my hesitation on this was...
16:31:29 <jgriffith> jungleboyj: it seems like a much broader feature than just a cinder feature
16:31:38 <DuncanT> jungleboyj: Are you looking at doing the same for nova or just cinder? Should this be OSLO work?
16:31:50 <jgriffith> jungleboyj: was curious as to why you wanted to start with Cinder, why it wasn't targetted for OSLO etc
16:31:54 <jgriffith> DuncanT: haha!
16:32:31 <jungleboyj> jgriffith: DuncanT: Good questions.  This is broader than just Cinder.  We have done the work, internally, to get all the services running on DB2.
16:32:52 <jgriffith> jungleboyj: I'd suggest making it a contribution to OSLO
16:32:56 <jungleboyj> We are now just working on the details for getting it back to the community.
16:33:08 <jgriffith> jungleboyj: IIRC there's some effort taking place to move the DB stuff there already
16:33:35 <thingee> jgriffith: +1
16:34:03 <jungleboyj> jgriffith: Ok, so, just to be clear, if we have changes to the migration scripts, etc. we would want to be tracking all of those against an OSLO BP?
16:34:15 <jgriffith> jungleboyj: well...
16:34:21 <jungleboyj> jgriffith: For all the projects?
16:34:32 <jgriffith> jungleboyj: I think common db code is a goal we already have
16:34:46 <jgriffith> jungleboyj: and I don't see the point in just modifying/updating cinder db only
16:34:59 <jgriffith> jungleboyj: you'll get more bang for your buck doing this OS wide
16:35:12 <hemna> +1
16:35:12 <jgriffith> heavier lift obviously, but ther'es a lot of shared code there
16:35:18 <DuncanT> I think fixing up migrate etc is a sub-task, after get DB into OSLO and doing the DB2 work there
16:35:40 <jungleboyj> jgriffith: Right.  We are able to run a combination of DBs, but I doubt real-world people do that.
16:35:41 <jgriffith> jungleboyj: don't get me wrong, I like the idea, just not sure it's a good approach to do it as a Cinder change
16:36:05 <jgriffith> jungleboyj: indeed, but people come up with interesting thing
16:36:07 <jgriffith> things
16:36:18 <jgriffith> jungleboyj: you should also be looking at reddwarf project
16:36:26 <jungleboyj> DuncanT: jgriffith:  Ok, this is helpful.  We are trying to figure out how we bring this in.
16:36:48 <jungleboyj> I think I may be blazing the trail a bit here.
16:36:48 <jgriffith> jungleboyj: I think you want a much broader audience than just us block storage folks :)
16:37:41 <jungleboyj> jgriffith: Ok, I will take this back and check into the OSLO aspect.  With that said, at some point we are going to want to say that the Cinder support is in.
16:38:00 <jungleboyj> jgriffith: The good news is that getting Cinder on DB2 was quite painless.  :-)
16:38:13 <jgriffith> jungleboyj: cool
16:38:21 <jgriffith> jungleboyj: the rest should be pretty much the same
16:38:34 <jgriffith> jungleboyj: all of that sqla code is pretty similar
16:38:48 <jgriffith> jungleboyj: the models/design are identical across cinder/nova
16:39:11 <jgriffith> Ok... I think that sort of covered item 2 on the agenda, but just incase
16:39:15 <jgriffith> #topic new proposals
16:39:20 <jgriffith> anything we missed?
16:39:20 <kmartin> jgriffith: do we need to talk about https://blueprints.launchpad.net/cinder/+spec/multi-attach-volume
16:39:23 <jungleboyj> jgriffith: In fact, I didn't have any code changes for Cinder, now that I look again.  It just worked.
16:39:33 <jungleboyj> jgriffith: Anyway, thanks for the discussion!
16:39:37 <jgriffith> jungleboyj: welcome
16:39:49 <jgriffith> kmartin: we did, but you missed it :)
16:40:10 <jgriffith> kmartin: I had an equivalent posted/accepted already
16:40:20 <jgriffith> kmartin: wait...
16:40:22 <jgriffith> you were here
16:40:32 <jgriffith> bahh
16:40:34 <kmartin> ok...thanks
16:41:02 <jgriffith> we can discuss it and the objections raised by esker and bswartz
16:41:14 <jgriffith> we'll save it for the end :)
16:41:17 <kmartin> ok
16:41:30 <bswartz> so to be clear, we don't object to this
16:41:36 <jgriffith> #topic status updates
16:41:41 <bswartz> the objections I rasied were ones others raised at the design dummit
16:42:06 <jgriffith> In terms of status, I think most of the focus has been on gettign bp's
16:42:11 <bswartz> I and Rob's comments were mostly to draw attention to the fact that some use cases for multi-attach-volume overlap with the share service stuff
16:42:13 <jgriffith> and decompressing after the summit :)
16:42:25 <jgriffith> bswartz: ok, thank you for the input
16:42:47 <jgriffith> So here's something I'd like to try this cycle :)
16:43:07 <jgriffith> I was thinking that we could have formal updates on work being done in the current cycle each week
16:43:21 <jgriffith> It would be a standing agenda item in the weekly or biweekly meeting
16:43:42 <jgriffith> The idea is, if you have a bp assigned to you for the current milestone
16:43:58 <jgriffith> you go in at least once a week and update the status/whiteboard whatever
16:44:05 <jgriffith> just some way for us to track progress
16:44:22 <jgriffith> I'd like to avoid the mad-dash or surprises the last week of the release cycle
16:44:30 <jgriffith> does that sound reasonable/useful to everyone?
16:44:36 <kmartin> jgriffith: sounds like a good idea, we did that in Grizzly for the FC changes
16:44:46 <jgriffith> kmartin: indeed
16:44:47 <bswartz> last week of the release or last week of the milestone?
16:44:52 <jgriffith> milestone
16:44:58 <bswartz> Are all the milestones problematic or just the last one?
16:44:59 <jgriffith> sorry
16:44:59 <xyang> jgriffith: sounds good
16:45:03 <jgriffith> all
16:45:13 <bswartz> okay I like it
16:45:21 <varma> sounds good
16:45:22 <jgriffith> bswartz: a number of us typically end up pulling all nighters the last couple days of each milestone
16:45:31 <jgriffith> doing reviews, baby-sitting CI etc
16:45:46 <bswartz> I'm aware of the CI issues
16:46:04 <kmartin> varma: hey, welcome!
16:46:28 <varma> kmartin: thanks, Kurt
16:46:31 <jgriffith> Most of them aren't CI issues any longer but things like merges, rebases etc
16:46:36 <xyang> hi varma
16:46:40 <jgriffith> varma: hey.. wann intro yourself?
16:47:07 <varma> jgriffith:sure
16:47:40 <hemna> varma, welcome!!
16:47:42 <jgriffith> varma: sorry... times up
16:47:46 <jgriffith> varma: just kidding :)
16:48:07 <varma> Proposed FC SAN Zone/Access Control Manager at the summit and working on zone manager and zone driver interfaces for cinder-fc-zone-manager bp to bring in FC SAN support to Cinder
16:48:19 <varma> hemna: thanks, Walter
16:48:25 <jgriffith> varma: very cool... real name?
16:48:30 <varma> Yep
16:48:37 <varma> Varma Bhupatiraju
16:48:43 <jgriffith> Nice to meet ya
16:48:45 <jgriffith> Ok...
16:48:52 <varma> xyang: thanks, Xing
16:49:00 <jgriffith> #topic behavior standardization
16:49:15 <jgriffith> So this is something I seem to be in the minority on
16:49:17 <med_> ruh roh, big brother.
16:49:37 <jgriffith> The concept of same expected behaviors regardless of driver/backend
16:50:03 <jgriffith> since I can't seem to get concensus on this, even though I think it's a bad idea
16:50:14 <jgriffith> ....  I have a possible compromise
16:50:23 <jgriffith> So for example: jdurgin DuncanT
16:50:39 <jgriffith> You want to be able to delete parent volumes of snaps
16:50:45 <jgriffith> (others may want this as well)
16:50:54 <bswartz> jgriffith: I think the actual issue is where we draw the line -- I don't think anyone disagrees that there needs to be a minumum bar
16:51:04 <jgriffith> My argument is bad to have different capabilities/behaviors for diff drivers etc
16:51:24 <jgriffith> DuncanT: jdurgin my proposal goes like this:
16:51:39 <jgriffith> What if we provided a flag in the conf file to enable this?
16:51:55 <jgriffith> Then that was the global behavior for the install
16:52:16 <DuncanT> Ok... still some complications with multi-backend though
16:52:18 <jgriffith> In other words, it's up to the OS-admin to set this correctly based on what his backend is
16:52:34 <jgriffith> DuncanT: how so?
16:52:46 <jgriffith> DuncanT: What I'm getting at is it's LCD
16:53:05 <med_> jgriffith, you're saying the admin defines what "standard" means to him
16:53:17 <jgriffith> med_: not entirely... but
16:53:19 <DuncanT> I'd still like a mechanism where a backend can express what it is capable of... the trouble with a switch is that people poke it to see what happens
16:53:34 <jgriffith> Ok...
16:53:38 <guitarzan> multibackend also has issues with the snapshots included in gb flag
16:53:42 <jgriffith> it seems my compromise won't fly either
16:53:44 <guitarzan> but I digress
16:53:44 <jgriffith> never mind
16:53:47 <DuncanT> I'm not necessarily against a switch to say 'enable not quite standard behaviours'
16:54:18 <DuncanT> But I'd like to maybe add a method to the drivers to express which of those behaviours they support
16:54:36 <jgriffith> DuncanT: ok, I'll just give up
16:54:36 <hemna> isn't that what the capabilities thing is about?
16:54:39 <hemna> or no.
16:54:49 <guitarzan> it could be
16:54:53 <DuncanT> These are not mutually exclusive or incompatable ideas I don't think?
16:54:54 <jgriffith> hemna: yes,but the proposal is to not have everything behave the same
16:55:00 <jgriffith> hemna: it would be wild wild west
16:55:08 <jgriffith> everybody does what they want as long as the report it
16:55:14 <jgriffith> they
16:55:16 <guitarzan> cats and dogs living together. mass hysteria!
16:55:20 <hemna> ugh
16:55:20 <jgriffith> guitarzan: haha!
16:55:35 <hemna> well that's bad mmmkay
16:55:38 <jgriffith> hemna: in other words no standard expected behaviors
16:55:51 <DuncanT> Define the 'correct' behaviour and have a switch to enable any none-standard behaviours seems fine
16:55:58 <guitarzan> I think the idea of having the provider define behavior globally is interesting
16:56:11 <jgriffith> guitarzan: it's the best compromise I could come up with
16:56:20 <guitarzan> again, multiple backend makes that hard
16:56:28 <jgriffith> guitarzan: so then HP for example could configure their cloud to allow delete parent vols
16:56:28 <guitarzan> but it's going to make everything hard :)
16:56:33 <DuncanT> but in order to actually make that work, some form of driver functionality expression is also needed
16:56:45 <jgriffith> if they throw in LVM or something that doesn't support that then oops
16:56:46 <DuncanT> Particularly for multi-backend
16:57:08 <DuncanT> I'd rather be smarter than 'ooops' if possible
16:57:17 <guitarzan> I think folks are going to have to go lowest common denominator if they want multiple backends to work exactly the same
16:57:47 <jgriffith> guitarzan: agree,,, and I still stand by my viewpoint that the behavior should be the same
16:57:59 <hemna> Do we even know how divergent the drivers are right now?
16:58:05 <DuncanT> hemna: Yes
16:58:12 <jgriffith> hemna: yes, and it's not horrid
16:58:20 <hemna> should we document this in a wiki or something right now?
16:58:35 <hemna> I know the FC drivers don't support copy volume to image/image to volume.
16:58:36 <jgriffith> hemna: kmartin already did that IIRC
16:58:40 <DuncanT> I think adding a way of getting better, more informative error messages out of drivers is a good thing
16:58:50 <jgriffith> DuncanT: sure, I agreee with that
16:58:59 <DuncanT> Even if in an ideal world / stable release they'd never get seen
16:59:11 <thingee> https://wiki.openstack.org/wiki/CinderSupportMatrix
16:59:26 <jgriffith> alright, let's move on... there's no point in me wasting time on this any more
16:59:30 <hemna> should the drivers that don't support features throw a warning/exception at startup?
16:59:31 <DuncanT> Adding your requirement that a flag is needed to enable certain none-standard behaviours I've no objection to
16:59:45 <jgriffith> everybody feel free to do what they like, I won't fight it any longer
16:59:54 <bswartz> jgriffith: we're out of time :-(
16:59:58 <hemna> doh
17:00:00 <jgriffith> Yay!
17:00:02 <jgriffith> :)
17:00:07 <jgriffith> #endmeeting