19:00:56 <notmyname> #startmeeting swift
19:00:57 <openstack> Meeting started Wed Apr 15 19:00:56 2015 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:01 <openstack> The meeting name has been set to 'swift'
19:01:11 <notmyname> who's here for the swift team meeting?
19:01:14 <mattoliverau> o/
19:01:16 <cschwede> o/
19:01:18 <ho> o/
19:01:21 <kota_> o/
19:01:24 <jrichli_> Here
19:01:29 <acoles> hi
19:01:34 <wbhuber> o/
19:01:42 <minwoob> o/
19:01:47 <gvernik> hello
19:02:04 <notmyname> good group here
19:02:05 <cutforth> hello
19:02:13 <notmyname> clayg: hurricanerix: courtesy ping
19:02:37 <notmyname> peluse is out at a meeting. torgomatic has another commitment
19:02:50 <notmyname> ok, let's get started
19:02:53 <notmyname> agenda is at
19:02:57 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
19:02:57 <clayg> o/
19:03:08 <notmyname> #topic EC status
19:03:44 <notmyname> had to get the ling
19:03:46 <notmyname> *link
19:03:47 <notmyname> #link https://github.com/openstack/swift/commit/e910f7e07d05dd2c6ada939d5704c3d4944c24b0
19:03:52 <notmyname> there it is! on master!
19:03:59 <notmyname> thank you everyone
19:04:02 <kota_> great!
19:04:14 <ho> cool!
19:04:20 <tsg_> awesome!!  :)
19:04:32 <notmyname> I've said this many times before, and I'll keep saying it: this is a huge feature that has been a whole-community effort. thank you
19:05:08 <notmyname> as a follow up to that, the feature/ec and feature/ec_review branches are gone
19:05:19 <notmyname> feature/ec has been tagged for historic purposes
19:05:30 <notmyname> but you can no longer submit reviews to them
19:05:44 <notmyname> and the rest of the pending changes have landed on master
19:05:51 <notmyname> we have a 2.3.0rc1 tag
19:06:09 <notmyname> unless major issues are discovered, then this will be our 2.3.0 release and included in openstack kilo on april 30
19:06:29 <notmyname> master is unfrozen
19:06:30 <notmyname> any questions on ec, the RC, or the release?
19:06:41 <wbhuber> just one minor q
19:06:50 <kota_> notmyname: one thing.
19:06:59 <notmyname> wbhuber: first
19:07:06 <kota_> notmyname: ok, waiting
19:07:31 <wbhuber> in the doc link, development_saio.rst, that has yet to include python_pyeclib as a dependency
19:07:57 <clayg> isn't that what requirements.txt is for?
19:08:15 <wbhuber> yes, but requirements.txt comes after installing swift
19:08:17 <clayg> I thought the docs only listed out like system packages which need to be installed
19:08:52 <clayg> wbhuber: i'm not sure I follow - can you do a patch or open a doc bug?
19:08:53 <notmyname> hmm..looks like it doesn't actually have a step to install swift's requirements.txt
19:08:56 <notmyname> it does for swiftclient
19:09:01 <wbhuber> i could open a doc bug
19:09:04 <tsg_> wbhuber: at the moment, we didn't have rpm format pkgs generally available for pyeclib and liberasurecode yet
19:09:15 <tsg_> only Debian packages
19:09:17 <notmyname> wbhuber: looks like an oversight. a bug (in swift) or evena  patch to the .rst file would be great!
19:09:17 <wbhuber> i see
19:09:19 <clayg> notmyname: well the setup.py will do it - it's all pbr'd and setup.cfg - probably won't work unless you pip install -e .
19:09:22 <tsg_> so we decided to stick with pypi
19:09:55 <wbhuber> there's a patch but not implemented, i think - https://review.openstack.org/#/c/169990/6..20/doc/source/development_saio.rst
19:10:12 <clayg> so I have given up on setup.py develop - it just never works with any version of setuptools you're likely to have installed on any release that's reasonable to develop on
19:10:21 <wbhuber> ok
19:10:23 <notmyname> clayg: womm
19:10:26 <clayg> cschwede and I recently fixed vagrant-swift-all-in-one by using pip install -e .
19:10:42 <clayg> notmyname: you almost cirtainly would have pip installed pyeclib by hand then
19:10:52 <notmyname> clayg: yup. totally did
19:10:53 <cschwede> clayg: yeah, and i can confirm that a fresh vagrant-saio has pyeclib installed
19:10:55 <clayg> or pip install -r requirements.txt - same different
19:10:59 <notmyname> yeah
19:11:03 <wbhuber> ok nifty
19:11:16 <notmyname> wbhuber: ok, so there's a gap in the SAIO docs. can you open a bug or submit a patch?
19:11:25 <clayg> cschwede: and it doesn't installed it *explicitly* - it just lets' setuptools/pbr/pip do it - but you cant spell it setup.py develop - you have to say pip install -e .
19:11:38 <clayg> pbr hasn't trained you all to do this yet!?
19:11:38 <wbhuber> i'll submit a patch
19:11:43 <notmyname> wbhuber: thanks!
19:11:50 <notmyname> kota_: you have a question?
19:12:00 <kota_> notmyname: ok
19:12:02 <kota_> notmyname: I know current reconstructor doing decode/encode because of the jerasure bug and we need to bump it later than Kiko. If you have a schedule for that, could I have it?
19:12:22 * notmyname looks to tsg_
19:12:28 <tsg_> kota_: thanks I was about to bring up update to 1.0.7
19:12:45 <tsg_> notmyname: that might be one requirements update that we'll need to take in
19:12:58 <tsg_> (pyeclib-1.0.7)
19:13:04 <clayg> also 1.0.7 will allow xor 3-3 yeah!?
19:13:10 <notmyname> tsg_: pre kilo?
19:13:11 <tsg_> clayg: correct!
19:13:12 <hurricanerix> notmyname: sorry, i am here =)
19:13:21 <notmyname> hurricanerix: hi!
19:13:32 <tsg_> notmyname: 1.0.7 has a number of bugs ironed out, so I recommend pre-K, yes
19:13:41 <clayg> notmyname: not before kilo - once liberty opens
19:13:55 <notmyname> tsg_: clayg: you just said 2 different things :-)
19:14:00 <clayg> tsg_: how are we going to pull that off!?
19:14:35 <notmyname> I can investigate bumping a dependency pre-kilo, but I don't know much about it right now
19:14:45 <clayg> notmyname: tsg_: kilo will *work* with 1.0.7 right?  but it *requires* at least 1.0.6 - that's a done deal at this point?
19:14:50 <tsg_> clayg: the pypi 1.0.7 release for pyeclib should be available by this afternoon - for requirements, I was hoping we could be explicit
19:15:06 <tsg_> clayg: correct .. at least 1.0.6
19:15:15 <notmyname> ok.
19:15:27 <notmyname> phrased a different way, will kilo break with 1.0.6?
19:15:35 <notmyname> or, what will break?
19:15:43 <clayg> notmyname: 1.0.7 isn't even out yet!  we've *all* been using 1.0.6
19:15:57 <notmyname> seems that way
19:16:02 <tsg_> clayg: liberasurecode 1.0.7 was waiting on a couple of fixes .. that's released
19:16:03 <clayg> it's as good as we need, and 1.0.7 will be even better!
19:16:13 <tsg_> Kevin and I working on 1.0.7 for this afternoon
19:16:30 <notmyname> tsg_: is there something in 1.0.6 that needs to hold the release?
19:16:46 <tsg_> notmyname: some reconstructor related fixes in the jerasure backend
19:16:52 <tsg_> those are important
19:16:56 <notmyname> ie so we can patch/backport/rc2 to get 1.0.7
19:17:22 <notmyname> tsg_: jerasure bugs or liberasurecode bugs?
19:17:25 <clayg> tsg_: you mean getting rid of the encode/decode hack?  that's a liberty dev cycle fix.
19:17:51 <tsg_> notmyname: bugs in the "jerasure" backend in liberasurecode, yes
19:17:53 <kota_> notmyname: if we could get 1.0.7 during rc timeline, it would be better to me.
19:18:29 <clayg> kota_: tsg_: why do you guys care?  if you don't like what's in kilo repackage?
19:18:34 <notmyname> kota_: what's preventing using 1.0.7 today?
19:18:54 <clayg> notmyname: a) it's not released b) no one will have time to package it for the kilo release
19:19:13 <notmyname> clayg: it's important the the dependency is working at release. I'm not convinced at this point, but I want to get the info
19:19:25 <kota_> notmyname: I found decode/encode thing is affecting our backend.
19:19:31 <clayg> notmyname: (except us - we'll probably re-package swift & pyeclib a few weeks into liberty - but we always do that)
19:19:38 <cschwede> is there any real risk in using 1.0.6?
19:19:48 <notmyname> right, that's what I've been trying to ask
19:20:01 <tsg_> there is no risk
19:20:14 <notmyname> kota_: will you be able to use the newer version of the dependency?
19:20:17 <tsg_> the reconstructors bug has been already fixed in that rev
19:20:18 <clayg> notmyname: cschwede: sounds like kota_ has some issue with the hack on his plugin?
19:20:29 <kota_> notmyname, tsg_: because we use unique info at encoding to each fragment so when re-encoding the fragment it's not original fragment on our backend.
19:20:54 <clayg> notmyname: ok kota_ has a real issue - the hack is acctually casuing a problem
19:21:04 <notmyname> kota_: will you be able to deploy liberasurecode 1.0.7 with swift 2.3.0 (with >=1.0.6 in the transitive dependency list)
19:21:22 <clayg> kota_: I would suggest if we can't bump the depencency (we probably can't) - we *could* roll a rc2 that includes a config option to do use encode/decode *or* rebuilt
19:21:27 <clayg> s/rebuilt/rebuild
19:22:01 <clayg> notmyname: kota_'s problem isn't 1.0.6 - it's the hack - the question is could he repackage and deploy swift kilo+ instead of swift kilo or do we need an rc2
19:22:02 <kota_> clayg: sounds reasonable, thanks
19:22:13 <notmyname> so far, I'd like to leave it as-is, if kota_ can use the newer version with the swift code
19:22:21 <clayg> notmyname: +10000000
19:22:33 <notmyname> oh, wait, is there code in *swift* that is breaking things? or just the dependency
19:22:55 <clayg> notmyname: kilo is beta - it wasn't tested with all backends - there's been an issue discovered with a non-tested backend - requires a bug fix that we want to do anyway
19:23:07 <notmyname> clayg: you don't have to over-sell me ;-)
19:23:18 <clayg> notmyname: the code would have to change - the 1.0.7 only helps kota_ because it allows us to remove the hack that's breaking him
19:23:29 <notmyname> swift code or liberasurecode?
19:23:42 <clayg> swift code
19:23:45 <acoles> sounds like kota needs a change in swift code
19:23:48 <notmyname> ok
19:24:06 <kota_> calyg, acoles: exactly, thanks
19:24:07 <clayg> well he *wants* a change - that we want to - the question is if he *needs* it in kilo and we have to spin an rc2
19:24:17 <notmyname> right. I understand now
19:24:18 <notmyname> thanks
19:24:48 <notmyname> so, kota_, do you absolutely require an rc2? ie if this isn't in kilo, are you stuck without EC for 6 months until the openstack liberty release?
19:25:05 <clayg> kota_: what is the problem with kilo (ec beta) having the hack - do you not expect to release/test with swift during liberty anyway?  what if we find a new issue 4 weeks from now?
19:25:14 <notmyname> or can you deploy eg kilo(swift2.3.0)+ a few commits
19:25:24 <notmyname> clayg: exactly my question
19:25:52 <kota_> notmyname, clayg: ah...thinking...
19:25:58 <clayg> kota_: :)
19:26:06 <clayg> kota_: no rush, it's cool ;)
19:26:26 * notmyname would be happy to work with kota_ to set up some 3rd party testing running the NTT EC library
19:26:36 <clayg> notmyname: what is the possiblity of an rc2 anyway?  I'd love to know if I work hard and find a bug I can fix it - but only if I do it before XYZ
19:26:59 <notmyname> clayg: looks like most of the other openstack projects are doing an RC2 next monday I think
19:27:00 <clayg> notmyname: oh - that's an awesome idea!
19:27:26 <clayg> notmyname: I mean the 3rd part testing - not doing an rc2 monday
19:27:29 <notmyname> :-)
19:27:37 <clayg> notmyname: but it's good to know we have a little bit of time
19:27:50 <clayg> notmyname: I'd be just as happy getting it "right enough" on the first go
19:27:55 <notmyname> kota_: what do you think?
19:28:21 <clayg> notmyname: i'm also looking into acoles etag issue - trying to understand why the scenario he described which *should* break - is acctually not causing a problem for me in practice
19:28:27 <acoles> clayg: if we make rebuild configurable but not bump to 1.0.7 then we'd have to make sure you can't select rebuild when using 1.0.6 right?
19:28:37 <clayg> acoles: "have to"
19:28:40 <acoles> clayg: wel that could just be because i am wrong
19:28:44 <notmyname> yes, me too. it's beta, and I'd really prefer not to do an RC for a non-open driver that the community doesn't have visibility in to
19:28:47 <clayg> acoles: it's *beta* - you might loose some data
19:29:35 <notmyname> clayg: also, as much as we put "beta" on it, someone will be using it for prod data somewhere
19:29:44 <notmyname> so fix stuff if we can
19:29:53 <acoles> clayg: notmyname i agree with you both!
19:29:56 <clayg> notmyname: you're going to give me an ulcer
19:29:56 <notmyname> kota_: ok, can we come back to this? I want to move on in the meeting
19:30:15 <kota_> well, I undestood it's beta and we could do testing as 3rd party so maybe not urgent for the rc, but I'd like to fix it as possible
19:30:34 <kota_> notmyname: thanks to consider that :)
19:30:36 <notmyname> kota_: yes, I agree with that!!!
19:30:54 <notmyname> kota_: I'd totally love a patch to swift master this afternoon as soon as tsg_ has the new version available
19:31:05 <clayg> kota_: ok - so your best bet is to find a bug in swift that *requires* a rc2 - then we can slip in the reconstruct config option ;)
19:31:06 <notmyname> but that wouldn't be in kilo
19:31:11 <notmyname> yes
19:31:13 <notmyname> clayg: yes
19:31:27 <kota_> clayg thanks!
19:31:43 <clayg> yeah that's the other thing - swift development will continue no matter what goes in kilo
19:31:46 <notmyname> ok, so as things stand now, there is no plan for an RC2. if somethign is found, we'll have one
19:31:59 <clayg> yay!
19:32:15 <notmyname> tsg_: and when you get upstream done, please submit a requirements update. no terrible rush on that, but sooner is better than waiting eg until july
19:32:16 <tsg_> notmyname: just got a final nod on a patch for 1.0.7 from Kevin - we will have pyeclib uploaded by 2pm PDT
19:32:19 <notmyname> thanks
19:32:30 <tsg_> notmyname: will do
19:32:33 <notmyname> thanks
19:32:35 <notmyname> mornign on
19:32:40 <notmyname> #topic summit planning
19:32:52 <clayg> notmyname: i'd like to make sure we do a good job testing swift with the new version of pyeclib
19:32:53 <notmyname> #link https://etherpad.openstack.org/p/liberty-swift-summit-topics
19:32:59 <notmyname> clayg: of course!
19:33:23 <notmyname> that etherpad is our scratch pad for summit planning
19:33:38 <notmyname> we will have 6 fishbowl sessions and 10 working sessions
19:33:51 <notmyname> and all day friday for "open"
19:34:10 <notmyname> fishbowl == larger session like previous summits
19:34:28 <notmyname> working == smaller session more similar to a room at a hackathon. focused discussion about code
19:34:48 <notmyname> friday will be like friday in paris. open ad-hoc discussions
19:35:28 <notmyname> any questions on logistics before we talk about some of the proposals?
19:36:27 <mattoliverau> no lets talk proposals :)
19:36:29 <notmyname> ok, let's go though some of the proposals. I want to get a general sense of popularity of them
19:36:42 <notmyname> encryption. acoles and jrichli
19:36:53 <notmyname> current state of on-disk encryption in swift
19:37:10 <notmyname> we talked about this at the hackathon, and I'm happy to see work kick off again for it
19:37:11 <mattoliverau> If you put the word encrytion in, every man and his dog will probably turn up like last summit
19:37:26 <notmyname> yeah, that leads to my question about it:
19:37:39 <notmyname> acoles: jrichli: do we need to have a second fishbowl one for it?
19:37:51 <jrichli> i would be up for it
19:37:59 <acoles> you mean in addition to a working
19:38:01 <acoles> ?
19:38:03 <clayg> notmyname: *two* fishbolw?
19:38:13 <notmyname> working session schedule titles will be intentionally obfuscated to prevent so many looky-lous from attending and not helping
19:38:15 <acoles> that makes a fishtank no? :)
19:38:17 <jrichli> sure
19:38:41 <notmyname> yeah, that's what I meant. as second session that is a fishbowl in addition to the existng proposed working session
19:38:49 <clayg> notmyname: is that like *our* plan?  or are other people doing this?
19:38:58 <notmyname> clayg: doing what?
19:39:07 <clayg> intentionally obfuscated
19:39:22 <notmyname> that's a global thing for the summit
19:39:30 <clayg> lol
19:39:33 <acoles> lets call it 'various minor improvements'
19:39:43 <mattoliverau> lol
19:39:45 <notmyname> lol
19:39:51 <clayg> acoles: no you title it "said every andriod app evar"
19:39:52 <notmyname> eg they don't want 300 people in a "docker" session
19:40:06 <clayg> THERE'S A DOCKER SESSION!?
19:40:08 <acoles> seriously, we must have a session where we can talk details and work out issues
19:40:10 <jrichli> acoles: "metadata of metadata" might scare people off :-)
19:40:14 <notmyname> clayg: not for you!
19:40:15 <acoles> ie smaller session
19:40:25 <notmyname> well, except storelets. we'll get to that in a minute
19:40:31 <acoles> jrichli: you're learning ;)
19:40:37 <cschwede> we should setup a honeypot session with docker in the title…
19:40:42 <notmyname> :-)
19:40:56 <clayg> oh goodness - this is going to be a great summit - i can't wait to see all of ya'll!
19:41:00 <kota_> lol
19:41:21 <clayg> notmyname: encrytpion needs a working seession too
19:41:24 <notmyname> ok, I added one
19:41:32 <notmyname> yeah, it's there
19:41:39 <notmyname> cschwede: test framework session
19:41:55 <clayg> notmyname: how much will the working sessions overlap - can I come to all of them (or the ones that don't lock the door "quick before clayg")
19:41:56 <notmyname> is this a newbie thing or something with new ideas onw hat to do?
19:42:05 <notmyname> clayg: no overlap
19:42:22 <jrichli> I meant it as a newbie thing
19:42:31 <notmyname> jrichli: ah ok. cschwede put hsi name on it
19:42:34 <clayg> title looks like newbie thing - but cschwede's a nice guy - he'll probably let us coopt it a bit at the end
19:42:51 <cschwede> notmyname: intro for newbies, howto add tests for your patches and tests to improve?
19:42:52 <notmyname> jrichli: cool. we might want to add some other "intro to swift" things to it too
19:42:55 <jrichli> yes, sorry i wasn't actually there when you called out my name earlier today
19:43:02 <notmyname> jrichli: cschwede: what do you think of that?
19:43:13 <acoles> so it could be (a) heres what we have for newbies and (b) what do we need to improve?
19:43:17 <jrichli> sure, as long as we can get deep and dirty into functests!
19:43:21 <notmyname> heh ok
19:43:22 <cschwede> jrichli: i just volunteered, remove me if you like to lead the session!
19:43:31 <clayg> notmyname: given "all newbie swift" and "how tests work today - how we'd like you to make them better" - i'd be interested in option 2
19:43:37 <jrichli> cschwede: that must be a joke
19:43:53 <notmyname> clayg: kk
19:44:01 <jrichli> cschwede: I suggested it because I need the info :-)
19:44:01 <notmyname> ops feedback session
19:44:05 <notmyname> mattoliverau: put it down
19:44:18 <notmyname> mattoliverau: I'll work on getting that one also added to the ops track session
19:44:20 <cschwede> jrichli: k :)
19:44:21 <mattoliverau> I did, cause I think its useful
19:44:35 <notmyname> a new feature of the schedule this summit will be that one session can be listed in 2 tracks
19:44:40 <notmyname> eg swift+ops
19:44:47 <clayg> killa
19:44:49 <mattoliverau> I put me down to run it, which I'm happy to do, but also cause I didn't want to volenteer anyone else :)
19:44:56 <notmyname> ok :-)
19:45:01 <clayg> i love mattoliverau doing it
19:45:05 <notmyname> Large Containers
19:45:07 <mattoliverau> cool
19:45:12 <clayg> i love mattoliverau doing that one too
19:45:13 <acoles> do it
19:45:16 <notmyname> I love this one, because I'd really love to see progress here in liberty!!!
19:45:17 <clayg> all mattoliverau all the time really
19:45:21 <gvernik> i like large containers...
19:45:23 <mattoliverau> lol
19:45:28 <notmyname> fishbowl or working, though?
19:45:43 <clayg> umm... hrd to say - probably fishbowl
19:45:45 <clayg> idk
19:45:58 <notmyname> bigger group discussing desing and presenting ideas or smaller one talking about the code you've got and with a whiteboard?
19:46:05 * notmyname doesn't know if a whiteboard is available
19:46:14 <clayg> i want to talk about some with guys high bandwidth and pick some things we think are a) doable b) useful c) moving us to the ultimate goal
19:46:20 <notmyname> mattoliverau: so far it's just your code, so what do you think?
19:46:22 <mattoliverau> either really
19:46:33 <notmyname> mattoliverau: then what's your preference?
19:46:38 <notmyname> gotta make a choice!
19:46:44 <clayg> jrichli: i'm really sorry - i used to always say "ya'll" but then in califiornia it's all "you guys" - which seems exclusionariy :\
19:46:45 <cschwede> i’d prefer smaller and in-depth talks for it
19:46:54 <mattoliverau> how about working.. unless there is a fishbowl free and I see how much more of the POC i can get done now that EC it out :)
19:47:09 <notmyname> ok
19:47:15 <mattoliverau> ok working for now
19:47:29 <notmyname> changing policies
19:47:33 <mattoliverau> s/ok/so/
19:47:35 <clayg> whoot!
19:47:36 <cschwede> yeah!
19:47:36 <jrichli> clayg: no worries.  I grew up in Delaware and said "you guys"
19:47:38 <notmyname> daisuke isn't here. kota_ do you know of it?
19:48:01 <acoles> notmyname: are there any obvious candidates to fill the 6 fishbowls - then everyhting else is working?
19:48:03 <kota_> notmyname: oh... either seems fine to him, I think.
19:48:14 <notmyname> acoles: next, one I think :-)
19:48:19 <acoles> k
19:48:30 <notmyname> kota_: thanks
19:48:33 <notmyname> storelets
19:48:36 <acoles> FISHBOWL!
19:48:39 <notmyname> I think this is a fishbowl session
19:48:47 <cschwede> large please!
19:48:54 <notmyname> yeah
19:49:03 <notmyname> increase part_power
19:49:14 <notmyname> it has a variable name in the title. probably a smaller session ;-)
19:49:33 <acoles> yup
19:49:43 <clayg> notmyname: yeah cschwede already has like the hard ring part written - so really it's just figuring out how to merge that and what the next patch would be
19:49:45 <notmyname> acoles: I love that you submitted this one. also, good luck, sounds hard ;-)
19:49:53 <clayg> (we might be able to do the first part before vancouver)
19:49:56 <notmyname> well, ok then
19:50:26 <notmyname> ec follow on work for next steps directly related to ec
19:50:34 <notmyname> I like this one and want it as a workign session
19:50:57 <mattoliverau> +1
19:51:02 <notmyname> ok
19:51:09 <notmyname> I added a few at the bottom right before the meeting
19:51:15 <notmyname> ec overview
19:51:22 <notmyname> a fishbowl session
19:51:36 <acoles> +1
19:51:47 <notmyname> as a summary and ops guide and etc. different than the next steps
19:52:06 <notmyname> python-swiftclient working session
19:52:10 <notmyname> to get some next steps there
19:52:12 <clayg> notmyname: be great if we could sneak in some early performance charictizations
19:52:18 <clayg> sigh poor swiftclient
19:52:23 <notmyname> clayg: yeah. start running those tests!!
19:52:59 <notmyname> ya, that's why I want to have a working session on swiftclient. so that we do have a plan for the next few months with it
19:53:05 <notmyname> any objections?
19:53:27 * notmyname looks at clock and realizes this meeting has gone by quickly
19:53:39 <mattoliverau> nope sounds good
19:53:41 <notmyname> acoles: how do you feel about a fast-post session?
19:53:52 <acoles> +1
19:53:53 <notmyname> working session
19:53:54 <notmyname> ok
19:54:02 <acoles> happy to lead if you like
19:54:03 <notmyname> global cluster improvements
19:54:14 <notmyname> acoles: done :-)
19:54:31 <notmyname> global cluster improvements is kinda nebulous, but there are a few things to look at
19:54:44 <notmyname> mabe ;-)
19:54:48 <kota_> +1
19:54:57 <notmyname> kota_: yeah, I knew YOU'D like it
19:55:31 <notmyname> last one there is tape storage
19:55:49 <cschwede> +2!
19:55:51 <notmyname> there have been a few things talked about, but not yet in the dev community. I'd like to try to get someone to talk on it
19:56:01 <notmyname> specifically, IBM and BDE
19:56:08 <notmyname> anyway, just and idea
19:56:24 <notmyname> so, for all of those, this isn't a final list at all, and it's totally unordered
19:56:43 <clayg> notmyname: isnt' there some specs up that folks wanted to talk about too?
19:56:48 <clayg> notmyname: should they like... be here?
19:56:48 <notmyname> please keep adding stuff, and if your name is there to lead, make and etherpad and make an outline
19:56:57 <notmyname> clayg: yeah, good point
19:57:08 <notmyname> probably could be one submission for every spec, really
19:57:10 <acoles> symlinks?
19:57:24 <notmyname> acoles: CRAZYTOWN
19:57:26 <cschwede> symlinks+containeralias
19:57:34 <notmyname> add it!
19:57:46 <kota_> ya, simlinks should be there!
19:57:52 <notmyname> keep adding stuff this week
19:57:53 <acoles> i'd like a session on that
19:57:59 <clayg> cschwede: they may be different things - the PUT == full replace nature of object's makes symlinks at the object layer simpler
19:58:24 <notmyname> I don't have a final date yet, but I'd expect that we'd have a really good idea of sessions by the end of next week
19:58:26 <cschwede> clayg: yes, different in implementation, but user-api should be similar and aligned i think
19:58:36 <clayg> cschwede: VERY good point
19:58:39 <notmyname> later, we'll rank them and schedule them
19:58:55 <notmyname> anything else to bring up in the last 2 minutes?
19:59:07 <notmyname> keep adding your ideas for the summit to the etherpad
19:59:48 <notmyname> I'll add an entry for the specs that are there
20:00:20 <notmyname> again thank you, everyone, on your hard work getting EC and 2.3.0 done!
20:00:26 <mattoliverau> I think we'll need a virtual tdasilva so he can join in.. unless the baby to be will keep him too busy ;) RE:summit
20:00:27 <notmyname> see you next week (and on IRC)
20:00:37 <notmyname> mattoliverau: :-)
20:00:45 <notmyname> mattoliverau: ipads with video chat
20:00:50 <notmyname> #endmeeting