19:03:27 #startmeeting Swift 19:03:28 Meeting started Wed Jan 8 19:03:27 2014 UTC and is due to finish in 60 minutes. The chair is torgomatic. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:31 excellent 19:03:32 The meeting name has been set to 'swift' 19:03:51 so, the agenda is https://wiki.openstack.org/wiki/Meetings/Swift 19:04:15 how about we start with sysmeta status? I think the folks here know something about that one 19:04:31 hi 19:04:33 #topic sysmeta status 19:05:01 acoles: anything to report? 19:05:02 o/ 19:05:07 or anyone, really 19:05:43 so the sysmeta patch is close - i hope! 19:05:47 must be going well :) 19:06:04 i think i have two +1's 19:06:10 acoles: any substantive changes to folks who reviewed it earlier? 19:06:29 acoles: are there other immediate targeted uses beyond the federation thing? 19:06:49 acoles: (I mean I guess I can just look at the patchset--but an overview? like what happened to gatekeeper functionality) 19:06:56 swifterdarrell: no. gatekeeper middleware is back in the patch, same as before. main change is that it now leverages torgomatic;s wsgi manipulation 19:07:10 acoles: cool 19:07:15 so should look very familiar to what you reviewd before 19:07:17 peluse: account ACLs will be using it 19:07:23 thx 19:07:37 peluse: there's at least one patcset for that which depend on acoles' 19:07:43 *patchset 19:07:51 "torgomatic's wsgi manipulation"... is that a drinking game? 19:08:02 peluse: not if you like your liver 19:08:07 peluse: drink until WSGI makes sense 19:08:26 :) 19:08:36 if gatekeeper not configured then gatekeeper will be inserted after catch_errors IF catch_errors is first, otherwise gatekeeper is inserted first 19:08:48 i think the patch is ready to get in - i'm looking at it - and torgomatic's got a +2 on it 19:08:53 acoles: sounds good to me 19:09:18 * portante wants to look at it, but does not want folks to wait for him to move it forward 19:09:22 if anyone else really wants to get eyes on it they might stick a -1 on there so I don't approve it when/if I +2 19:09:23 good stuff acoles 19:09:51 swifterdarrell: I was still hoping otherjon might +1 it since his patch depends on it 19:10:17 also, object sysmeta support is not included as discussed in channel, that is pending figuring out semantics of POSTing changes to symeta on objects. just saying, 19:10:23 clayg: ya, but I think he'll just adjust/rebase to whatever lands--esp if it's very similar to hwo it used to be 19:10:41 yeah, doing persistent metadata on objects is kind of hard 19:10:41 swifterdarrell: it's even BETTER 19:10:49 :) 19:11:36 torgomatic: i don't see how making the sysmeta of an object tied to like of that timestamp (instead of the life of the resources) negates the usefulness of restricted sys meta on objects 19:11:41 torgomatic: acoles: cool--i'm perfectly happy punting on obj sysmeta since there's clear value in acct/container getting delivered sooner/with less effort 19:11:50 but... we can do that, and consolidate after_fn, later 19:12:20 i haven't found anything on the patch yet worth blocking it any longer 19:13:06 clayg: one issue is different bits of middleware competing to update subsets of sysmeta 19:14:34 torgomatic: acoles: clayg: k; is that sufficient for the agenda item (status update)? 19:14:39 good enough for me 19:14:41 next topic! 19:14:53 #topic python-swiftclient status 19:15:04 who knows about swiftclient's status? 19:15:25 torgomatic: there's some require-SSL patch that's really important and languishing 19:15:43 swifterdarrell: oh yeah; didn't that patch just flat-out break stuff for some folks? 19:15:45 torgomatic: I had problems w/it w/some self-signed cert I'd created a while back; so I didn't like it 19:16:16 But someone said I was crazy, and I think they might have been right, so I just went and did other things for a while 19:16:24 that's all I know 19:16:48 beyond that, it seems like there's a lot of patches for py3 support in the queue 19:16:49 swifterdarrell: fwiw I think the patch could easily add the feature without breaking backwards compat 19:17:23 swifterdarrell: have an ENVVAR and add the feature - then change the default whenver we *want* to bump the rev 19:17:45 clayg: the allow-insecure-ssl thing? 19:17:59 i told this to notmyname and he said "na" so I stayed out of it 19:18:28 swifterdarrell: yeah 19:18:58 * swifterdarrell shrugs; I just want --insecure to, well, allow all valid SSL certs (where in my crazy expereience, it didn't) 19:19:15 ....and my alrm didn't go off.. soory 19:19:21 he lives! 19:19:24 I like the default-verify behavior change 19:19:35 that part is probably quite solid 19:19:43 notmyname: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 19:19:45 swifterdarrell: I'm with you on that one 19:19:49 see 19:19:52 * clayg stays out of it 19:19:54 ah, cool 19:20:21 notmyname: torgomatic started; we finished sysmeta status update and are on python-swiftclient 19:20:39 yup, just glanced over the backlog 19:20:51 linear agenda ordering is for chumps ;) 19:21:26 I'm glad I actually looked at the agenda then 19:21:32 or put stuff on it 19:21:40 related to swiftclient, how's the progress on removing swiftclient as a Swift dependency coming? 19:21:42 So are there any action items here for python-swiftclient? I guess I could look at teh ssl thing again, but the most recent prob was one someone else (at HP?) had, so i dunno what I could add 19:21:48 * portante loves watching the team mess with notmyname's head in Perth 19:22:18 chmouel was working on python-swiftclient things 19:22:23 chmouel: around? 19:22:32 I saw a commit merge: 150f338 Remove swiftclient dep on direct_client 19:22:41 his last patch got through 19:22:54 ok, great 19:23:37 I'll look into where swiftclient is still used and go from there 19:23:45 looks like container-sync and dispersion-report are what's left 19:23:55 (and functional tests, but swiftclient is fine in there) 19:24:06 ok 19:24:16 i could look into dispersion-report if that helps 19:24:42 cschwede_: thanks. that'd be great 19:25:37 anything else on swiftclient? 19:25:51 not from me 19:26:33 #topic log #openstack-swift or not 19:26:41 ok, this one is mine 19:27:03 the question is as the topic says. should we publicly log #openstack-swift 19:27:11 on this topic, I have had my comments in #openstack-swift picked up and noticed by the powers at be today already 19:27:16 notmyname: NOW can we have a vote!? 19:27:20 heh 19:27:22 lol 19:27:35 notmyname: I don't see why not 19:27:49 portante: so this was exactly my concern. I know that's happened to you, so do we want to have the logs existing and searchable? 19:27:51 I vote sure 19:28:23 hang on hang on 19:28:24 I don't personally mind that, as I consider this semi-permanent anyways 19:28:26 The channel's already public, so maybe it makes it easier to find, but not any more public 19:28:47 #startvote Should #openstack-swift have public logs? yes, no, abstain 19:28:48 Begin voting on: Should #openstack-swift have public logs? Valid vote options are yes, no, abstain. 19:28:49 Vote using '#vote OPTION'. Only your last vote counts. 19:28:54 for others, what's happened (without too many details) is that portante has had others withing Red Hat contact him about something he said in channel 19:28:57 AUTOMATION! :) 19:29:04 #vote yes 19:29:08 #vote yes 19:29:12 #vote yes 19:29:14 #vote abstain 19:29:18 #vote yes 19:29:18 #vote abstain 19:29:19 #vote yes 19:29:25 #vote yes 19:29:33 #vote abstain 19:29:36 #vote yes 19:30:20 are other openstack channels logged? 19:30:24 #endvote 19:30:24 Voted on "Should #openstack-swift have public logs?" Results are 19:30:25 yes (7): peluse, acoles, keving, swifterdarrell, creiht, clayg, fbo 19:30:26 abstain (3): cschwede_, portante, torgomatic 19:30:31 * notmyname is internally debating 19:30:31 portante: yes 19:30:38 heh, too late 19:30:39 * clayg guesses it was probably like "he portante saw you were talking and generally being a baddass - keep it up" 19:30:40 notmyname: oop, sorry, jumped the gun there 19:30:48 clayg: lol 19:31:03 clayg: unfortunately, no. 19:31:09 torgomatic: no worries 19:31:10 http://eavesdrop.openstack.org/irclogs/ 19:32:00 it would be better to be transparent 19:32:05 portante: i think all (major) except ... swift :) 19:32:15 ah 19:32:26 BTW, if anyone (else) ever has someone approach them trying to limit what's said in any way in openstack IRC channels, I'd love to argue with them about it. 19:32:43 *them == the person trying to limit what's said 19:32:58 really, some folks already have logs 19:33:23 I'm fine with logging. I just didnt' want to turn it on without mentioning it in a meeting first (and this is our first meeting since it last came up) 19:33:27 I mean, I know my machine has them saved somewhere 19:33:37 ok, moving on :-) 19:33:39 so, anyone in the channel, plus anyone who works for the NSA 19:33:51 well, that's given 19:33:55 sssh maybe they are sleeping ... 19:34:39 #topic Swift 1.12.0 release 19:34:50 we did sysmeta already? 19:35:08 yes, acoles is doing a great job 19:35:19 yay. good job acoles! 19:35:21 :-) 19:35:27 ok, swift 1.12.0 release 19:35:33 here's what I'm thinking: 19:35:35 i got a bunch of help 19:36:06 when the sysmeta stuff lands, I'd like to seriously look into a 1.12 release 19:36:18 so, in the near term 19:36:55 the sysmeta functionality + (hopefully) swiftclient extraction + (maybe) account ACLs would be very nice for a release (+ the other stuff that's landed) 19:36:57 notmyname: can taht include account ACLs plz? 19:37:07 yes, I hope so 19:38:07 I haven't had a chance this week to sit down and look at the specific details of what will be in it, but I wanted to at least have a near-term marker for doing it 19:38:12 swifterdarrell: notmyname: I don't think account acl's are going to just fall in once sysmeta lands? I'm sure much fewer people have been looking at that because of the patch chain dependency 19:38:27 clayg: I hope so :) 19:38:34 clayg: as does otherjon, no doubt 19:39:18 clayg: wait, I misread what you typed 19:39:34 clayg: that's true, but the broad parts of account acls should be pretty good, I think. he's done a lot of work to ensure that the overall design is in the right direction 19:39:45 clayg: I'm hoping the ACL biz is straightforward w/a solid foundation of an already-merged sysmeta 19:40:30 clayg: because, if not, assuming the rough edges weren't related to actually persisting sysmeta, we should have already banged out any rough edges on the account ACL stuff concurrently w/the sysmeta patch 19:41:21 swifterdarrell: I just don't think anyone else has looked at it, I've mostly compromisied to the approach as disccused (but that wasn't what was in the patch last I looked) 19:41:50 clayg: k... we'll see how it shakes out :) 19:41:51 swifterdarrell: i had a look at it and have a question/idea about it, but we can talk after the meeting on #openstack-swift 19:41:54 eitherway, all of the same stuff (container vs. account format, json in headers, write vs read-write) is probably going to come up again in review 19:42:02 * clayg is assuming someone else *will* look at it 19:42:21 oh yeah! i forgot cschwede_ was looking at it! 19:42:24 * clayg hugs cschwede_ 19:42:25 cschwede_: sounds good; otherjon is the man to talk to, btw 19:43:01 notmyname: torgomatic: sorry for the de-rail; back to 1.12.0? 19:43:19 any other questions on 1.12? 19:43:38 notmyname: what's the cutoff for account acl's? 19:43:55 notmyname: i'm pretty sure sysmeta is close - i don't really understand what needs to happen with swiftclient 19:44:12 notmyname: are you just waiting for a list of features to land then then it goes? 19:44:32 there isn't a cutoff yet. but in-general, let's say end of next week would be a good time to have things for 1.12 landed 19:45:08 notmyname: ouch; that's a tight window for the acct acl IMO 19:45:41 lol, I thought I wsa playing the role of pessimist todate? 19:45:43 so let's make sure to review it :-) 19:46:54 that's a goal, bit yet a requirement (the target timeframe fro 1.12) 19:46:58 clayg: it's a team effort 19:47:11 notmyname: k 19:47:26 clayg: within a group full of pessimists, yes even you can look like an optimist at times :) 19:47:44 heh 19:47:57 swifterdarrell: notmyname: otherjon: ummm... does anyone have a link to the account acl patch? 19:48:29 clayg: it's probably on page 4 in gerrit? 19:48:35 (haha) 19:48:47 https://review.openstack.org/#/c/63227/ 19:48:54 thanks 19:49:11 wow that commit msg is epic 19:49:17 https://review.openstack.org/#/c/63227/ 19:49:48 so please go take a look a that 19:49:52 #link https://review.openstack.org/#/c/63227/ 19:50:22 is that on the priority review list? 19:50:37 any other 1.12 questions? I want to talk about the gate briefly here at the end of the meeting 19:50:37 torgomatic: topic open discussion 19:50:44 #topic open discussion 19:50:51 portante: maybe? I hope 19:50:59 * portante is being lazy 19:51:04 * notmyname hasn't looked at the priority review list this week in AUS yet 19:51:10 torgomatic: thanks 19:51:14 gate queue is 93 deep; 8 more and it breaks the graph ;) 19:51:22 so, as everyone knows, the gate is really backed up 19:51:24 it hit 101 today 19:51:26 http://not.mn/gate_status.html 19:51:29 that I saw 19:51:34 wow 19:51:44 but it needs to say over 100 for a while in order to make it into the graph, though, right? 19:51:45 looks like the queue is stopped 19:52:05 ya, it's an average of the time-bucket (12 hours currently) 19:52:36 jeblair and clarkb are here at LCA and I know they've been working on getting jenkins performing better 19:52:57 no started zuul jobs on http://status.openstack.org/zuul/ for the last hours 19:53:07 they're working hard on their side of it (jenkins just got too overloaded--something like a load average of 350) 19:53:35 but that's a small part of "there are >90 things in the gate and gate resets keep happening frequently" 19:54:10 i asked the rh openstack storage team if they are feeling the pain 19:54:12 so, I'd like to ask for continued patience with the -infra team for their part. they are actively working on getting the queues flowing 19:54:17 and they emphatically said yes 19:54:18 portante: and? 19:54:24 good to know 19:54:30 but nobody volunteered to take any action 19:54:37 the fact that gate jobs fail frequently is a separate concern 19:54:43 folks seem at a loss as to what to do 19:54:47 so I wanted to make that clear 19:55:03 portante: unfortunately, a lot of it is "try harder to not write bugs" 19:55:21 time to fork and land large pachsets each night? :) 19:55:31 but the topic came up again in this weeks openstack meeting 19:55:39 but they said they are spending a lot of time triaging failures in obscure code somewhere in openstack instead of regular work 19:56:06 I'm concerned about the additional dev time cost like that 19:56:28 I'm concerned that they still think they can make this all work :( 19:56:40 we see it too. we babysit patches and it take a lot of time instead of reviewing and writing swift code 19:56:50 it is too much, materially costing companies money to participate that they did not on and cannot plan for 19:57:03 creiht: agreed 19:57:09 4 minutes....typing faster 19:57:30 creiht: so while I agree to some extent, it's not "us" vs "them" 19:57:37 oh I know 19:57:56 we, as a community, need to figure out how to unclog the pipes 19:58:19 lol 19:58:26 the voice of reason from Perth 19:58:31 2 thigns we've talked about are automating the recheck comments and monitoring the gate queue resets 19:58:44 and we can actually do those things 19:58:46 that's the problem though... there is no community there, it is only "them" who knows how to do it right 19:58:47 torgomatic does that now for us. :) 19:59:25 creiht: I think there is a lot of pain felt by a lot of people. and many people are working on it 19:59:51 I'd like to see some changes in how integration tests work, but that didn't go so well when we presented at the team meeting. 19:59:51 time's just about up, fwiw, but we can keep talking in #openstack-swift 20:00:06 ...and there it goes 20:00:06 notmyname: yes, as there have been for a long time. How long will we continue to bang our heads against the wall until we realize that _perhaps_ a new approach may have to be considered 20:00:11 heh 20:00:11 #endmeeting