19:00:23 <notmyname> #startmeeting swift
19:00:24 <openstack> Meeting started Wed Jul 16 19:00:23 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:25 <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:40 <notmyname> weekly swift team meeting time. thanks for coming. who's here?
19:00:45 <gvernik> hello
19:01:18 <acoles> hi
19:01:20 <peluse_> I'm sorta here (in another meeting but can pay attention)
19:01:22 <portante> o/
19:01:31 <Tyger> I'm lurking
19:02:24 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
19:02:30 <notmyname> agenda for today ^
19:02:41 * notmyname refreshes and sees nothing else
19:02:55 <notmyname> ok, so not a ton to cover, but some good stuff I think
19:03:08 <notmyname> first up: in-person meeting
19:03:14 <notmyname> #topic in-person meetup
19:03:18 <peluse_> somewhere cool
19:03:30 <notmyname> peluse_: so you're saying no AZ?
19:03:50 <notmyname> we've had 2 community-wide in-person meetups. one in austin and one in denver
19:03:52 <peluse_> heh, pretty hot here now... well, I'm in your neck of the woods today but still hot back at home
19:03:54 <notmyname> (denver-ish)
19:04:10 <mattoliverau> o/
19:04:11 <peluse_> San Diego?
19:04:12 <notmyname> so let's look to the fall to see what's reasonable
19:04:44 <notmyname> first, before figuring out the location (which is really up to who's paying for it ;-), let's talk dates
19:05:02 <notmyname> the paris summit is the first week of november
19:05:30 <notmyname> some of us, but not all, will be going. both for budgeting and for family reasons, we probably shouldn't have another big travel thing the week before
19:05:54 <notmyname> and after that gets really tricky with US thanksgiving and christmas plans that people have
19:05:58 <peluse_> agree
19:06:04 <peluse_> maybe Oct sometime
19:06:04 <notmyname> which means that we should do it before november
19:06:11 <peluse_> :)
19:06:45 <notmyname> I suggest something like the first week of october or the last of september
19:06:54 * portante likes that
19:07:01 <peluse_> personally would prefer early Oct
19:07:08 <peluse_> but late Sep works too
19:07:35 <peluse_> actually Oct is much better (new quarter)
19:07:37 <notmyname> peluse_: like the week of september 29?
19:07:40 <notmyname> ah, ok
19:07:48 <notmyname> (big company budgeting)
19:08:04 <notmyname> that would eg be the week of october 6
19:08:06 <peluse_> yup
19:08:12 <peluse_> to both comments
19:08:14 <acoles> end of FY for us ;)
19:08:19 <notmyname> acoles: oct?
19:08:24 <notmyname> acoles: or sept?
19:08:38 <acoles> oct. but don't worry about that
19:08:43 <notmyname> so if it were the week of october 6, that gives 3 weeks at home, then paris
19:08:52 <notmyname> kinda tight. we couldn't do it later
19:09:01 <peluse_> yeah, I'm OK with end of Sep too
19:09:37 <notmyname> I think I'd prefer week of sept 29, and fall back to week of oct 6 if that doesn't work
19:09:57 <peluse_> or wed Oct 1
19:10:14 <notmyname> ya, 2nd half of that week is fine
19:10:36 <notmyname> the other question is about how many days. austin was 3 days and denver was 4. what are your thoughts?
19:11:03 <mattoliverau> *cough* should have another in Jan/Feb around LCA in Oz *cough
19:11:08 <notmyname> lol
19:11:30 <tdasilva> i wasn't in austin, but 4 days in denver felt just about right
19:11:51 <portante> 4 days in denver seemed to work well
19:11:58 <acoles> agree. 4 was good
19:12:07 <notmyname> mattoliverau: if my LCA talk gets accepted, let's do a BoF there :-)
19:12:26 * elambert wanders in
19:12:27 <mattoliverau> notmyname: done :)
19:12:48 <notmyname> anyone opposed to a 4 day meetup and would prefer something else?
19:13:15 <notmyname> elambert: just talking about an in-person meetup in the fall
19:13:27 * elambert nods
19:14:10 <notmyname> FWIW, I've had one offer for a sponsor that is in the US northeast, so that looks to be a more likely location now. I know that factors in to dates
19:14:17 <peluse_> ditt on 4
19:14:22 <peluse_> ditto that is
19:14:34 <notmyname> (and it makes it easier for acoles and team to attend!)
19:14:44 <peluse_> back east would be a nice change too
19:14:47 <acoles> :)
19:14:51 <elambert> notmyname: if that falls through we might be able to sponser
19:15:07 <notmyname> who knows, maybe even gvernik could drop in from Haifa :-)
19:15:10 <notmyname> elambert: thanks
19:15:39 <gvernik> may be :)
19:16:11 <notmyname> ok, so here's what I'm hearing: shoot for a 4-day meetup in the US northeast during the week of september 29. if that week doesn't work, fall back to the next week
19:16:44 <peluse_> cool
19:17:03 <notmyname> moving on then
19:17:13 <notmyname> #topic logged user-agent string
19:17:22 <notmyname> #link https://review.openstack.org/#/c/102401/
19:17:37 <notmyname> that patch proposes making the user agent string saner (IMO)
19:17:52 <notmyname> but it changes existing log message values
19:18:14 <notmyname> I know of no application that will be impacted, but I wanted to bring it up here
19:19:22 <notmyname> are there any applications that you know of that rely on specific bytes in the logged user-agent string for the storage node logs
19:19:23 <notmyname> ?
19:19:25 <peluse_> I'm of the general opinion that if there's no good reason to change it then I wouldn't but not so passionate about that position that I'd argue this specific one
19:20:09 <notmyname> peluse_: I actually have a toy application that does look at the user agent, and this patch makes my app simpler. :-)
19:20:15 <creiht> peluse_: I hear that it is the biggest thing since policies! :)
19:20:24 <peluse_> ha!
19:20:33 <peluse_> lets do it then!! :)
19:20:43 <notmyname> (seeing as not much has landed, it probably is!)
19:21:49 <notmyname> anyone else feel more strongly that peluse_ on this patch that it's not broken so don't fix it?
19:22:19 * notmyname feels it's slightly scratched but not broken and it's a low-impact "fix"
19:22:34 * peluse_ can buy into that
19:22:45 <notmyname> also clearly the most important patch we have since we've talked about it for so long ;-)
19:22:57 <mattoliverau> Lol
19:22:59 <peluse_> slow news day I guess
19:23:12 <notmyname> ok, let's MERGE IT!
19:23:22 <Tyger> It's the most controversial patsh nobody cares about. I'm indifferent on it too and I wrote it.
19:23:32 <peluse_> heh
19:23:42 <mattoliverau> Having network issues on my phone :( sorry for slow replies
19:23:46 <notmyname> ok, I approved it. if you hate it, you have about 2 hours to stop it before jenkins finishes
19:24:06 <notmyname> #topic review reviews
19:24:09 <creiht> that's a bit optimistic
19:24:14 * notmyname thinks himself clever
19:24:24 <notmyname> creiht: :-)
19:24:28 <notmyname> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
19:24:38 <notmyname> ok, let's highlight a few of these
19:25:05 <notmyname> first up, meta-wise, this hasn't changed much since last week. which is kinda bad since not much has actually merged. review more!
19:25:38 <notmyname> acoles: anything blocking the keystone v3 stuff aside from needing a final reviewer?
19:25:54 <acoles> i have one +2 on the client patch
19:26:01 <acoles> https://review.openstack.org/#/c/91788/ thanks cschwede
19:26:20 <acoles> and i don't think much has happened on the ACL side since clayg took a look
19:26:40 <notmyname> ok
19:27:05 <notmyname> can we get a volunteer to review the client one? https://review.openstack.org/#/c/91788/
19:27:45 <notmyname> creiht: torgomatic: portante: :-) ?
19:28:00 <portante> okay, I'll volunteer
19:28:04 * torgomatic has no keystone
19:28:06 <notmyname> portante: thanks!
19:28:29 <peluse_> wrt other reviews, I'd like to see the current rev of the EC user docs land on feature/ec sooner than later so others can contribute in smaller separate patches
19:28:39 <notmyname> peluse_: link
19:28:40 <notmyname> ?
19:28:40 <acoles> portante: thanks
19:28:49 <peluse_> https://review.openstack.org/#/c/104713/
19:29:14 <notmyname> peluse_: I'll take that
19:29:20 <peluse_> gracias
19:30:01 <notmyname> I'll also take the final review on the eventlet case-changing behavior https://review.openstack.org/#/c/93780/
19:30:04 <acoles> peluse_: i'll try to take a look tomorrow
19:30:20 <notmyname> creiht: but you're more of an eventlet expert than me, so I'd love your view, if you have the time
19:30:27 <peluse_> acoles:  thanks.  note the EC spec is in swift-specs for review as well (but of course still under construction as well)
19:30:47 <acoles> peluse_: yes, seen that
19:30:57 <peluse_> EC spec:  https://review.openstack.org/#/c/106103/ (other link was user docs)
19:30:58 <notmyname> ya, -specs. we gotta come back to that topic in a moment
19:31:03 <peluse_> K
19:31:38 <notmyname> can anyone take the final review on the list-endpoints middleware? https://review.openstack.org/#/c/101665/
19:31:41 <notmyname> acoles: ^?
19:31:53 <tdasilva> peluse_: how are patches landing in feature/ec in regards to reviewers? is it as strict as master?
19:32:09 <peluse_> same process, yes
19:32:11 <acoles> notmyname: ok, tomorrow
19:32:13 <notmyname> tdasilva: not quite as strict, but still should be working code
19:32:15 <notmyname> acoles: thanks
19:32:48 <notmyname> ok, I wanted to bring up one other patch
19:32:52 <notmyname> gvernik's https://review.openstack.org/#/c/90066/
19:32:57 <tdasilva> peluse_: ok, was just wondering in terms of the documentation..i guess it should definetely not take too long to land and be more of a WIP
19:33:07 <notmyname> tdasilva: right
19:33:08 <peluse_> notmyname:  and to expand on that (and level set) the 'not quite as strict' means that we can build things up in multiple patches easier - still needs solid test code, reviews, etc, agreed?
19:33:17 <notmyname> peluse_: 100% agreed
19:33:54 <peluse_> tdasilva:  yeah, wanted the docs to land often so we don't have one long patch like with pokicies.  easier to manage and get more people to contribute
19:34:07 <tdasilva> peluse_: agreed
19:34:43 <notmyname> so for the account cache patch from gvernik
19:34:55 <notmyname> I'm a little concerned by it, but I haven't fully looked at it yet
19:35:38 * peluse_ hasn't reviewed it...
19:35:40 <gvernik> notmyname: what is the concern with it?
19:35:47 <notmyname> when I glanced at it this morning, it looks liek the question is if it's fixing something that's broken or something that is behaving as intended
19:36:09 <notmyname> gvernik: so I'm certainly not against it yet, but I have a concern. I haven't reviewed it yet
19:36:34 <notmyname> so I don't have a particular question about it, I think. just wanted to bring some attention to it
19:36:51 <tdasilva> haven't reviewed it, but it seems like the behavior described on the commit message is definetely broken
19:36:56 <notmyname> I'd especially like the view of those runnign big clusters on it. ie the impact of cache-invalidation
19:37:08 <gvernik> the problem was that it possible to create many containers and bypass the max container per account...this is how i found this
19:37:44 <notmyname> yes, and I'm not sure that's actually broken. ie soft limits, like with quotas, not hard limits that require strong consistency
19:38:01 <notmyname> s/quotas/our implementation of quotas/
19:38:31 <peluse_> interesting...
19:38:32 <gvernik> i see the point
19:38:34 <notmyname> gvernik: yes, so eg you can only do that for 30 seconds or until the cached value times out. so ya you can go over, just not for ever
19:39:09 <peluse_> "eventual limitations"
19:39:18 <notmyname> that's my concern, and that should be addressed in reviews, not necessarily here. but since it already has 1 +2, I wanted to bring it up
19:40:27 <notmyname> gvernik: I just left a quick -1 note on it
19:40:35 <notmyname> gvernik: and all that ^^ is the context ;-)
19:41:18 <notmyname> ok
19:41:31 <notmyname> I think that's all I wanted to cover for patches (reviewing reviews)
19:41:36 <notmyname> now, let's talk specs
19:41:41 <notmyname> #topic swift-specs
19:42:01 <notmyname> so we've had a few proposed
19:42:06 <notmyname> and none merged
19:42:12 <notmyname> and they're kinda just sitting there
19:42:19 <notmyname> which seems the worst of both worlds
19:42:50 <peluse_> wrt the spec is the expectation that its complete before it gets merged?
19:43:04 <notmyname> so the other day I was talking with torgomatic over lunch and he had IMo a pretty good idea: land them fast, but keep a one-line "status" at the top. something indicating if they are done or not
19:43:21 <peluse_> yup, that what I did in the EC spec - big WIP at the top
19:43:26 <notmyname> peluse_: ya. seems people want it to be done before looking at it, but it can't get there until people look at it
19:43:44 <peluse_> yup
19:43:49 <notmyname> and the historic connotation of WIP in gerrit is negative (ie not worth my time to review) people don't look at it
19:43:55 <notmyname> so, what do you think?
19:44:12 <peluse_> I think merge w/status for the same reason as the EC user doc should land - avoid one really long patch chain
19:44:29 <peluse_> and those working on the thing in question should be looking at it regarldess of WIP or not
19:44:31 <notmyname> how can we differentiate between "this is a spec we think is a good idea" vs "this is a spec of something describing the way it should be or was actually done"
19:44:41 <notmyname> peluse_: yes, exactly
19:44:56 <peluse_> status comment at the top of the doc
19:45:03 <notmyname> peluse_: my point is how do we track that without the specific phrase "work in progress" since that carries baggage
19:45:40 <peluse_> yeah, we can use a different phrase
19:46:14 <notmyname> ok, proposal: at the top of a doc: "status: XXX" where XXX is one of ... well that's kinda the question :-)
19:46:25 <peluse_> so not use the gerrit WIP, just merge and have the top of the doc explain what stage its in
19:46:27 <creiht> notmyname: maybe you should start a spec
19:46:28 <creiht> :)
19:46:30 <peluse_> yeah
19:46:42 <acoles> notmyname: can we have an 'approved' directory and move spec to a 'done' directory when code lands?
19:47:09 <notmyname> /slap creiht (http://en.wikipedia.org/wiki/Wikipedia:Whacking_with_a_wet_trout)
19:47:09 <peluse_> acoles:  i like that
19:47:10 <creiht> I kind of prefer that specs only land when they are approved
19:47:16 <creiht> there shouldn't be a WIP
19:47:16 <notmyname> acoles: I like that
19:47:23 <creiht> it should be submitted
19:47:26 <creiht> people discuss
19:47:29 <notmyname> creiht: what about different "approved" and not folders?
19:47:31 <creiht> gets refined and try again
19:47:36 <peluse_> creiht:  but then we can use gerrit to collaborate on the construction of the spec right?
19:47:45 <creiht> peluse_: right
19:48:28 <notmyname> creiht: makes sense, but we've got 4 now that have been sitting around for weeks and mattoliverau is the only one to do anything on them
19:48:32 <creiht> I just don't want to get overcomplicated, and suddenly we have jira implemented as a group of text files in a git repo :)
19:48:35 <notmyname> thanks mattoliverau!
19:48:38 <peluse_> I kidna like having the spec under version control during construction, think there's some benefit there.  the separeaet dirs would make it super clear though don't you think?
19:48:57 <peluse_> crc32:  :)
19:49:04 <peluse_> typo, sorry
19:49:28 <notmyname> creiht: right. I think that's a valid concern. -specs are for devs, so let's not try to make it some big project management tool
19:49:38 <creiht> gotta run sorry
19:49:45 <notmyname> creiht: so the question to you is, what would make it easier for you to review?
19:49:57 <creiht> heh
19:49:58 <notmyname> really, to everyone
19:49:59 <mattoliverau> Happy to do it, I find them interesting and exciting pieces of work :)
19:50:14 <creiht> well I've just been a bit busy
19:50:15 <creiht> ;)
19:50:22 <notmyname> what's needed to make them something useful to the devs?
19:50:27 <creiht> notmyname: I think it is too early to try to make change
19:50:29 <creiht> s
19:50:39 <creiht> it will take time for everyone to adapt
19:50:44 <creiht> so give it a bit longer
19:50:51 <notmyname> :-) ok
19:50:54 <creiht> and continue to remind others :)
19:50:59 <creiht> that's at least my opinions
19:51:03 <creiht> really got to go now :)
19:51:14 <acoles> so are we agreed that approving/landing a spec means 'now go ahead and write the code' not ' the code is all done'?
19:51:22 <notmyname> hay, everyone, go review specs! that's why I put it at the top of the review dashboard! ;-)
19:51:50 <notmyname> acoles: yes, IMo that's absolutely true. -specs are for _limited_ up front design. not for code docs
19:52:02 <peluse_> totally
19:52:19 <peluse_> its a tool to organize our thoughts and collaborate on design
19:52:37 <notmyname> launchpad is for project managers. docs are for users. specs are to get something done as devs
19:52:47 <notmyname> peluse_: ya, well said
19:52:55 <acoles> and the only problem is if -specs appear to be like documentation of what _has_ been done
19:53:45 <notmyname> I don't think we're there yet
19:54:48 <notmyname> so are we agreed that we should keep on for now and not try to fix something we haven't even fully tested yet?
19:54:53 <notmyname> or do we need to make changes?
19:54:59 <tdasilva> still unclear to me when specs would actually land...just before coding starts? or while coding is ongoing but we have a good enough idea of what the design looks like??
19:55:09 <peluse_> well, the EC spec for one isn't done and its proposed....
19:55:30 <peluse_> so it either continues as a long WIP chain or we land it with something in the doc, like it is now, that describes its state
19:55:31 <notmyname> tdasilva: both, IMO. and they could be updated while the code is being written
19:56:01 <peluse_> and its supporting code development as we speak :)
19:56:04 <acoles> tdasilva: my take was that they can run in parallel, but if your spec is approvedyou have more right to expect code reviews.
19:56:05 <tdasilva> ok...because in the EC case, coding is already on-going but I assume the design might still be a bit "fluid"
19:56:16 <peluse_> for sure!
19:56:19 <notmyname> ya
19:57:05 <peluse_> so personally I'd like to see it land so others can contribute commits/content without always pushing on my patch...
19:57:39 * peluse_ thinks he's probably said that enough already though :)
19:57:42 <mattoliverau> I agree, there is nothing stopping development in WIP.
19:58:26 <notmyname> so I think we all agree we don't really know what it looks like and we're still figuring it out. basically, "whatever works"?
19:58:40 <tdasilva> sounds good to me...
19:58:43 <tdasilva> notmyname: yeah
19:58:47 <notmyname> and in the short term, go review existing proposed specs and let's see what happens
19:58:49 <notmyname> sound good?
19:58:54 <tdasilva> yep
19:59:03 <notmyname> acoles: peluse_: sound good to you?
19:59:13 <acoles> yeah
19:59:20 <notmyname> torgomatic: ?
19:59:31 <torgomatic> sure
19:59:35 <notmyname> ok
19:59:44 <notmyname> oh, and wow. we got right up to the time
19:59:44 <peluse_> yup
19:59:52 <notmyname> what a fun meeting :-)
20:00:08 * notmyname sees torgomatic frowning after I wrote that
20:00:09 <mattoliverau> Nice work everyone!
20:00:10 <peluse_> cool, thanks!
20:00:15 <notmyname> thanks for coming
20:00:20 <notmyname> #endmeeting