19:00:24 <notmyname> #startmeeting swift
19:00:25 <openstack> Meeting started Wed Nov 26 19:00:24 2014 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:28 <openstack> The meeting name has been set to 'swift'
19:00:34 <notmyname> hello, world
19:00:39 <notmyname> who's here for the swift meeting?
19:00:55 <kota_> o/
19:00:58 <gvernik> hello
19:00:58 <acoles> \o
19:01:32 <mahatic> o/
19:01:46 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
19:01:52 <notmyname> a few things to talk about today
19:01:57 <notmyname> I know cschwede isn't around
19:02:00 <notmyname> peluse: are you here?
19:02:04 <notmyname> (for later)
19:02:40 <notmyname> and I'm guessing the US thanksgiving is keeping others out
19:02:43 <cutforth> hello
19:02:57 <notmyname> #topic testing changes
19:03:06 * cutforth is glad i got daylight savings sorted out with UTC
19:03:12 <notmyname> cutforth: :-)
19:03:23 <notmyname> so...cool stuff in the openstack-infra world that affect us
19:03:31 <notmyname> #link https://review.openstack.org/#/c/137184/
19:03:54 <notmyname> tl;dr is that the tests run against swift patches should be reduced
19:03:55 <clayg> whoa - i'm late
19:04:11 <notmyname> in the commit message there's a link to the mailing list thread on it
19:04:28 <notmyname> looks like it hasn't landed yet, but I'm hoping it will soon
19:04:52 <mahatic> cool
19:05:13 <notmyname> I'm hoping this will reduce the chances for swift patches to fail in the check and gate queues. resulting in shorter times to land patches because of less need for "recheck"
19:05:38 <notmyname> (also, torgomatic bot thanks for posting those comments all the time)
19:05:45 <torgomatic> hehe :)
19:05:58 <notmyname> any questions about that change?
19:06:41 <notmyname> #topic swift CLI/SDK changes
19:06:59 <notmyname> this one is kinda big, and a follow up to what we talked about last week and at the summit
19:07:11 <notmyname> as a recap....well let me post the link
19:07:17 <notmyname> #link https://etherpad.openstack.org/p/kilo-swift-swiftclient
19:07:32 <notmyname> the bottom of that etherpad is where we've been taking notes on what to do
19:07:51 <notmyname> the general plan is to focus new client SDK dev work in openstack-sdk
19:08:18 <notmyname> I've been talking with that team this week, and mentioned it to ttx yesterday.
19:08:23 <clayg> notmyname: fwiw i haven't looked at the openstack sdk at all
19:08:42 <notmyname> clayg: I have a little. they're is very little there right now for swift
19:09:17 <notmyname> briancurtin has been most responsive in #openstack-sdks
19:09:45 <clayg> notmyname: do they have something that looks like "def api_action(parts, of, the, request, as=parameters): ... return status, headers, body"
19:10:16 <clayg> k, i should hang out in there
19:10:29 <notmyname> clayg: https://github.com/stackforge/python-openstacksdk/tree/master/openstack/object_store
19:10:41 <notmyname> they don't have much at all now
19:11:02 <clayg> notmyname: k, that's probably for the best!
19:11:27 <notmyname> :-)
19:11:43 <clayg> oh, no, it's OO :\
19:12:02 <clayg> that's at least one level too high for where we want to start ;)
19:12:10 <notmyname> hi briancurtin :-)
19:12:13 <briancurtin> hey
19:12:47 <notmyname> clayg: I think they'd be happy for us to make it better. so far briancurtin et al have been very receptive to ideas. of course nobody has proposed code yet ;-)
19:13:30 <sweston> asselin: mmedvede the next version of the script is posted.  will be testing it again today.  now, all of the subtree splits are done on a single cloned merge repo.  this will be much easier for us to track and update the history on the entire repository.
19:13:32 <clayg> notmyname: ack, i should get on that!
19:13:44 <clayg> notmyname: be nice to get in there before things 1.0 on us
19:13:45 <notmyname> AFAIK there isn't yet any high-level design for "here's what the SDK must look like". which is good
19:13:50 <notmyname> clayg: +1000
19:14:16 <briancurtin> yep, not a whole lot is nailed down, it's all fairly malleable, especially at the higher-levels
19:14:19 <notmyname> briancurtin: is that true? any existing thing yet?
19:14:21 <sweston> (sorry, guys, wrong room)
19:14:46 <clayg> sweston: it's cool - we're just hanging out
19:15:16 <notmyname> briancurtin: cool. great to hear
19:16:09 <notmyname> we haven't yet discussed how reviews will work for swift stuff in openstack-sdk. ie who reviews, who approves, etc. I want to figure that out when/if it becomes a problem
19:16:25 <notmyname> briancurtin: is there anything we should be aware of there?
19:16:32 <clayg> notmyname: let's start with patches.
19:16:39 <notmyname> clayg: right. my thoughts exactly
19:16:41 <notmyname> :-)
19:16:58 <clayg> k, enough on that then - unless we want to talk tatics of most important patches or design
19:17:06 <notmyname> anyone else ahve any questions about it?
19:17:17 <briancurtin> yeah there's not a lot of process here (yet), just want to enable
19:18:27 <notmyname> ok, next topic
19:18:35 <notmyname> thanks for saying hi, briancurtin!
19:18:48 <notmyname> #topic EC status update
19:19:09 <notmyname> peluse: clayg: torgomatic: what's going on with EC this week?
19:19:40 <notmyname> what's top of the list to review?
19:19:42 <clayg> well you merged the don't store errors in the ring, so we need to merge master and update the node index stuff
19:19:46 <torgomatic> well, the error-limiting patch just landed, so that'll make the plumbing better for indexes
19:19:48 <clayg> merge master, fix node index
19:19:52 <torgomatic> clayg++
19:19:53 <clayg> yay yay yay!
19:20:02 <notmyname> gogogogogogogo!
19:20:16 <clayg> after that sam is going to write a GET path and the whole world is going to change
19:20:49 <torgomatic> at a minimum, it'll rotate slightly slower
19:21:19 <notmyname> anyone have any questions on EC?
19:22:02 <clayg> peluse: notmyname: torgomatic: I'd acctually like to know how to do the master merge if someone could shoulder surf maybe?
19:22:20 <notmyname> clayg: ya, I can do that with you today
19:22:23 <torgomatic> clayg: sure, I'll head over once the meeting is done
19:22:28 <torgomatic> that's all I have about EC
19:22:37 <clayg> i'm sorta interested in doing more pushing ec refactors into master and merging them back in this round than we did with storage policies - it's something I feel like I could help with
19:22:49 <notmyname> cool
19:22:52 <clayg> notmyname: torgomatic: kk
19:22:57 <clayg> that's it on EC from me
19:23:04 <notmyname> ok, thanks
19:23:11 <notmyname> #topic priority reviews
19:23:17 <notmyname> I wanted to ask about a couple
19:23:38 <notmyname> what are we waiting on for fsync() dirs? https://review.openstack.org/#/c/126923/
19:23:48 * clayg yawns
19:23:49 <notmyname> acoles: tdasilva: ?
19:24:06 <acoles> i had two queries...
19:24:29 <tdasilva> notmyname: ppai has been doing some research on the fsync tree question
19:24:33 <notmyname> ok
19:24:37 <clayg> OMG will this patch ever merged?!  https://review.openstack.org/#/c/131238/
19:24:37 <acoles> 1. do we need to run the fsync all the way up a new directory tree or is it sufficient to fysnc the leaf and assume the fs does the rest
19:24:38 <tdasilva> but so far he has only found out what i had already posted
19:25:16 <tdasilva> our understanding is that because of xfs journaling you only need to do on the leaf
19:25:25 <acoles> 2. is it ok to not worry so much about quarantined objects - proposal is to not fsync their dirs
19:25:25 <torgomatic> clayg: my recheck-bot's persistence will get it in there eventually
19:25:50 <clayg> acoles: fsyncs are for suckers - we have three copies it'll be fine
19:25:52 <tdasilva> maybe torgomatic could also take a lok at that
19:26:03 <notmyname> clayg: in 3 buffers ;-)
19:26:04 <clayg> tdasilva: maybe *after* EC GET
19:26:08 <acoles> clayg: lets rip em all out then!)
19:26:09 <clayg> notmyname: exactly!
19:26:16 * clayg is totally down
19:26:22 <torgomatic> acoles: I'm much less worried about losing a known-broken thing than a good one, especially if the consequence is that the broken guy stays put until the next auditor run and then gets removed
19:26:37 <torgomatic> er, quarantined
19:26:38 <notmyname> acoles: by gut reaction is that quarantines don't need dir fsyncs. they're already known bad
19:27:05 <acoles> torgomatic: i put an example on the review where the known bad doesnt stay around
19:27:41 <acoles> torgomatic: notmyname : i'm not digging in on the quarantines but wanted a discussion (so good we're having it)
19:27:43 <clayg> idk, i guess i've seen crazy looking directories that might have been the result of a missing fsync after a put, but it's more likely the missing fsync after a rsync
19:28:17 <torgomatic> acoles: if the FS loses a file during a rename (using the rename() syscall), the FS is broken
19:28:49 <torgomatic> it's either got to move or not-move... isn't that one of those atomic things?
19:29:04 <clayg> torgomatic: yeah!
19:29:35 <notmyname> torgomatic: isn't that FS dependent? but for XFS that's supposed to be true
19:29:37 <clayg> we could probably put it in and it'll turn out it's a noop that's like maginally more safe on some other filesystem
19:30:01 <clayg> acoles: tdasilva: torgomatic: notmyname: the only question is really the benchmark right?
19:30:02 <acoles> torgomatic: its when you rename to another dir, then fsync the original dir (entry gone) then lose the destination dir
19:30:07 <clayg> well I guess acoles has other questions
19:30:26 <notmyname> tdasilva: so ppai is still doing research?
19:30:37 <notmyname> or is that already done and recorded in gerrit?
19:30:37 <clayg> acoles: why do we fsync the /tmp dir?!
19:30:57 <acoles> clayg:?
19:31:03 <tdasilva> notmyname: I asked him to ping xfs guys on the question of going up the tree to fsync all the new dirs
19:31:12 <clayg> .... i thought put's start out (orignal dir) in /tmp
19:31:21 <torgomatic> acoles: right; I'm saying that if your FS code returns from that fsync() and the file doesn't have a directory entry *somewhere*, the FS is broken
19:31:22 <clayg> well... /srv/node/sdX/tmp but w/e
19:32:00 <tdasilva> torgomatic: yes, that's exactly what I heard from one of our xfs guys
19:32:01 <acoles> clayg: ah, no the example i found was during replication and quarantining, not PUT path
19:32:08 * clayg feels like he's never gone looking for "complete" uploads in /tmp
19:32:08 <tdasilva> same thing about the leaf dir
19:32:47 <clayg> replication!?  I think that almost definately needs less fsyncing that the intial write - i.e. I didn't think a suffix rsync currently had any fsyncing'
19:32:59 <acoles> torgomatic: what i have read is unclear on that
19:33:54 <torgomatic> acoles: I see
19:33:57 <clayg> bah, if someone said it's best practice to fsync somewhere, and the code is already written, and we benchmark and it's fine we probably don't have much to argue on do we?
19:34:08 <acoles> so backing up - the proposed change improves what we have at least! questions i have are whether more is needed
19:34:16 <notmyname> acoles: :-)
19:34:18 <clayg> OTOH if we benchmark it and it *sucks* we're probably not going to do it without making it optional
19:34:36 <torgomatic> acoles: hooray for shipping improvements! :)
19:35:10 <clayg> acoles: so are you +2 on the change as it stands?
19:35:48 <acoles> clayg: like you said, some benchmark would be good first, but otherwise yes
19:36:11 <notmyname> can anyone else commit to reviewing it?
19:36:39 <notmyname> hmm...looks like my name is already on it ;-)
19:37:23 <notmyname> other patch...
19:37:33 <notmyname> reworking splice/tee https://review.openstack.org/#/c/135319/
19:37:36 <notmyname> what's blocking on that?
19:37:48 <notmyname> torgomatic: you're +2. so just another reviewer?
19:38:07 <notmyname> swifterdarrell is on it, but he's out for the rest of the week
19:38:38 * clayg yawns
19:39:00 <notmyname> the clayg yawn. kinda like the creiht sigh ;-)
19:39:15 <clayg> a) that's mean
19:39:19 <clayg> b) they're not the same
19:39:20 <notmyname> lol
19:39:23 <clayg> ;)
19:39:31 <notmyname> torgomatic: bueller?
19:39:42 <torgomatic> notmyname: nothing's blocking on it IIRC
19:39:44 <notmyname> ok, thnaks
19:40:07 <notmyname> so for you non-USians, if you review it later this week, great! if not, we'll but darrell next week
19:40:07 <torgomatic> it's a safety improvement; as it stands now, you can write a caller of splice() that scribbles on your process's memory in unexpected and exciting ways
19:40:16 <torgomatic> we don't *have* any, but someone could write one
19:40:22 <notmyname> ya, it's a Big Deal (tm) IMO
19:40:36 <notmyname> ok, last patch
19:40:46 <notmyname> this is FYI
19:41:00 <torgomatic> so merge https://review.openstack.org/#/c/135319/ and footguns--
19:41:25 <notmyname> the defcore stuff has made some progress. this is what the foundation is using to determine what is openstack and what isn't.
19:41:44 <notmyname> there's a porposed patch for swift stuff. take a look if you are curious.
19:41:45 <notmyname> https://review.openstack.org/#/c/136677/
19:42:04 <notmyname> #topic open discussion
19:42:11 <notmyname> anything else you want to bring up?
19:42:51 <clayg> notmyname: it bugs me to know end I can't get probetsts to exit 0 when I have ssync on
19:42:53 <torgomatic> yes... let me get the link
19:43:04 <torgomatic> https://review.openstack.org/133315
19:43:15 <clayg> https://review.openstack.org/#/c/136548/
19:43:30 <clayg> oh yeah... that's a good one sam
19:43:41 <clayg> looks like we need two - i'll take one
19:44:07 <torgomatic> there are bytestrings that (a) are invalid UTF-8, (b) py2 accepts them, but (c) py3 doesn't, making objects with those names bad news for Swift's hypothetical py3 future
19:44:36 <notmyname> torgomatic: there's a whole lot of future. it might in fact have not-python2 in it
19:44:48 <clayg> torgomatic: we're doing full py3 support right after we add the v1.1 api and rewrite the objet server in go right?
19:45:04 <notmyname> clayg: sounds about right ;-)
19:45:12 <notmyname> ok, I'll review the unicode one too
19:45:34 <notmyname> clayg: what do you need on the ssync test one? just another reviewer?
19:45:34 <torgomatic> well, when someone talks about rewriting Swift, my usual response starts with "go", so... maybe?
19:46:18 <notmyname> so cschwede sent me a PM a while back: "Feel free to assign me tasks...."
19:46:38 <acoles> notmyname: yes, I'm already +2 on it (ssync probetest one)
19:46:38 <notmyname> so, therefore, cschwede can you review https://review.openstack.org/#/c/136548/ please?
19:46:39 <notmyname> ;-)
19:47:24 <notmyname> anything else to bring up in the meeting this week?
19:47:30 <clayg> notmyname: yeah, if you use vagrant-swift-all-in-one (or try it out) it's easy enough to set your localrc file to build you an ssync saio and just run probetests on master then again on the patch
19:47:30 <tdasilva> notmyname: I also asked cschwede to review the fsync patch
19:47:49 <notmyname> cschwede: can do all the reviews!
19:48:13 <tdasilva> :-)
19:48:17 <notmyname> clayg: cool. good info. thanks
19:48:29 <notmyname> ok, if nothing else, let's adjourn
19:48:45 <tdasilva> happy thxgiving everyone
19:48:46 <notmyname> thanks eveyone form attending. have a great rest of the week!
19:48:52 <notmyname> #endmeeting