19:00:29 #startmeeting swift 19:00:30 Meeting started Wed May 21 19:00:29 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:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:32 Hello. 19:00:34 The meeting name has been set to 'swift' 19:00:40 who's here? 19:00:44 o/ 19:00:46 me 19:00:51 \o/ 19:00:55 Me. 19:01:11 |-o-| 19:01:24 i am 19:01:26 * portante goes and gets his x-wing fighter! 19:01:35 :-) 19:01:53 :>o<: 19:02:00 I think most (all?) of you were at the summit last week 19:02:13 mostly I want to cover that. but a couple of other things too 19:02:21 #link https://wiki.openstack.org/wiki/Meetings/Swift 19:02:33 #topic summit follow-up 19:02:51 what worked at the summit? what didn't? what do you want to change for next time? 19:03:10 was the swift project pod useful? 19:03:14 yes 19:03:17 yes! 19:03:18 yes 19:03:18 notmyname: yes, i think so 19:03:22 great! 19:03:30 that was one of the greatest improvements 19:03:35 i thought the formal sessions went well 19:03:39 more ops feedback, like to see an ops summit like we have the design summit 19:03:40 creiht: cool 19:04:00 portante: more than just the ops session we had? what about the 2 days of ops track they had? 19:04:16 portante: that is, tell me more about your idea 19:04:34 make it more comfortable for the ops folks to give feedback 19:04:48 it seemed like they felt they were doing things wrong at times 19:04:53 at least in a few of the sessions 19:04:56 hmm 19:05:13 and instead would like to see them voice more 19:05:27 I think the room layout could have been better for that 19:05:43 yes, true, it was pretty bad for those kind of sessions 19:05:43 bring more people up front. rather than a big lecture hall format 19:06:04 yes, like concentric circles from center out 19:06:06 maybe a quick and easy survey before the next summit for topics ops are interested in? 19:06:21 so we can ensure we talk about them? 19:06:45 cschwede_: portante: you're thinking about swift-specific stuff? 'cause I know tom is working on that for openstack-wide things 19:07:10 portante: cschwede_: part of that has to do with the openstack user survey. which I'll try to get more input on next time 19:07:12 openstack wide, but I only attended one ops session for openstack wide and one for just swift 19:07:19 notmyname: yes, for swift-related stuff. i think it’s a little bit different thant for example nova-related ops 19:07:19 ah ok 19:08:14 I liked the ops session we had, and I got some good feedback from the ops-meetup track that was openstack-wide 19:08:42 things that I got from our ops session are: 19:08:44 ring validator (in swift-recon): eg test that something is running on the ports in the ring 19:08:44 deep health check to test all the way to drives (? or at least storage servers) 19:08:44 better ring deployment inside of swift itself 19:08:46 need internal net sec enforcement 19:09:32 +2 for better/easier ring deployment! 19:10:08 These are things we should put into LP (or the new specs repo) to track and try to get done. or decide we won't do 19:10:19 any other ops-related comments/feedback from the summit? 19:10:36 benchmarking? 19:10:52 i mean how to benchmark and some example benchmarks? -> docs 19:11:16 cschwede_: always a popular topic. we need to move from "here's a new benchmark tool" to "here's the patch that speeds stuff up" :-) 19:11:16 that said, using tools like getput.py and collectl 19:11:56 agreed, no new tool, but (better) docs and examples what to benchmark and things to watch for 19:12:02 ya 19:12:06 speaking of... 19:12:12 I think the docs session went ok 19:12:15 cschwede_: i think mseger is putting a link to getput into the docs 19:12:18 (creiht) 19:12:21 acoles: already done 19:12:30 notmyname: great 19:12:30 notmyname: yeah I have a lot on my todo list :) 19:13:00 creiht: my list: 19:13:03 refactor swift.openstack.org 19:13:03 use 3 sections: app devs, deployers/ops, dev contributors 19:13:03 make version docs apply to clear 19:13:05 multinode install: https://review.openstack.org/#/c/93788/ 19:13:07 SAIO: add link to vagrant SAIO, different instructions for different distress 19:13:09 undocumented areas: debugging tools, operating tools collection 19:13:11 look in to oslosphinx 19:13:13 idea: use the "file a bug for the docs on this page" js that the docs team has 19:13:40 there was a lot that came up asking for more and better docs I think 19:13:49 yeah 19:14:32 in general, there is a big need for education at a higher level too about what object storage is, where it's used, and why you should care 19:14:48 yes 19:14:55 and what it's benefits are 19:15:01 yes, and especially benefits of swift 19:15:05 and I've had a few conversations with different companies about that. so I hope we'll, as a community, make good progress there in the next few months 19:15:10 cschwede_: naturally :-) 19:15:10 it’s not just another object storage 19:15:56 cschwede_: /topic set in -swift ;-) 19:16:13 nice! 19:16:19 we should have called swift "store all the things" 19:16:33 so be careful of what you say in this channel! 19:16:38 notmyname: hehe, cool! 19:16:38 heh 19:16:42 lol 19:16:44 so far this week we've made progress on getting a -specs repo set up 19:17:21 I'll check on what needs to happen to get that finished 19:17:33 other follow-ups include what we decided for py3 19:17:50 chmouel will be working on getting a py3pep8 jobs set up as non-voting 19:17:53 for swift 19:18:27 once that passes, we'll fold it in to the existing linter job so it's gating and we don't revert syntax issues 19:18:35 and then we just hold our breath for eventlet 19:19:04 ok, helping new contributors 19:19:22 creiht you said you'd be able to tackle an improved doc for new contributors 19:19:25 still up for that? 19:19:30 yeah 19:19:37 great 19:19:52 as a new contributor (or potential new contributor) i'd like to help with that too 19:20:00 cool 19:20:00 elambert: great! thanks 19:20:26 one other thing we talked about is to (in an informal way) is to make use of a "nit" tag to be clear where a comment is "this would be nice but doesn't matter too much" 19:20:39 so that our comments are clearer to people who haven't been contributing long 19:21:11 did we settle on mentors or sponsors or something? 19:21:13 and also one other thing there... 19:21:15 core sponsors 19:21:19 portante: ya, that 19:21:20 :-) 19:21:35 yeah I was thinking maybe it would make sense to integrate that into the specs stuff 19:21:36 I think we were all interested in the idea 19:21:48 creiht: sponsors? 19:21:49 so each spec would have a sponsor which would have related reviews 19:21:51 yeah 19:22:09 might be easier to track that way instead of gerrit 19:22:10 I think that's a great idea to try 19:22:18 but that leaves out the usual bug fixes 19:22:19 I talked to the -infra team about it too 19:22:21 the specs themselves have to be +2'd, right? 19:22:35 acoles: ya. well, the specs have the same swift-core group as the code 19:22:35 but maybe those don't need a sponsor? 19:23:14 so gerrit can add a tag that shows up for a "core sponsor" thing. it's not great (and hard to describe via text). but it's something to consider 19:23:31 k 19:23:34 my first idea was to keep a wiki page and start assigning open reviews to different cores 19:23:52 and I don't think all reviews need sponsors 19:24:13 creiht: most likely not. I definitely thing all reviews do not need a spec 19:24:17 *think 19:24:19 right 19:24:41 i was wondering whether +2'ing a spec implies (moral) obligation to review subsequent code? 19:24:44 sponsors are helpful for keeping complex things on track 19:24:55 but we should encourage people to use specs as much as possible 19:25:04 acoles: I don't know yet. we haven't tried it yet :-) 19:25:23 acoles: I think that's a reasonable start, actually 19:25:45 notmyname: might slow down approval rate of specs :) 19:25:53 haha 19:25:54 acoles: heh. good point 19:26:06 never mind. that's a horrible idea! 19:26:09 :-) 19:26:34 yeah I don't think every spec requires a sponsor either 19:26:41 so the takeaway here, I think, is that I'll set up the wiki and start dividing up existing open patches among existing cores 19:26:54 and that's something we can track in the weekly meetings 19:26:58 sound ok? 19:27:32 yes 19:27:43 notmyname: lets try it and see 19:28:40 ok. I'll do that (number 3-ish on my list, after -specs and storage policies merge start) 19:28:42 notmyname: might want to try voluntary first 19:28:56 creiht: no! you get zaitcev's PBE patch! ;-) 19:29:10 and figure out how to make it easier for someone to request a sponsor to help 19:29:12 creiht: ya, voluntary start is good and then divide up what's left 19:29:52 ok, that sounds like a good plan 19:30:12 anything more on summit follow-up before we move to the storage policy merge plan? 19:30:52 hey! it's dfg! 19:31:07 hey! 19:31:20 #topic storage policies merge plan 19:31:30 it's actually just about almost finally here! 19:31:48 we talked last week about how we are going to get storage policies on to master 19:31:55 here's the rough draft: https://gist.githubusercontent.com/notmyname/7521817bd1027adc35a7/raw/609164665ec6c9ccdb0ee90a69f045df4081ca0a/gistfile1.txt 19:32:53 the important point is that by the end of this week, clayg should be able to propose the patch chain to master, feature/ec will not accept new stuff, and master will be in a freeze 19:33:16 then we all focus on reviewing the storage policy patches, and set them up to merge quickly one after the other 19:33:17 notmyname: are you going to send this to openstack-dev? 19:33:25 cschwede_: yes, and -operators 19:33:31 ok, thanks 19:33:39 that's my rough draft. probably add a little to it 19:33:49 are we still all in agreement about this plan? 19:34:50 sounds good to me 19:34:55 (If you don't say anything, I'm assuming you agree) 19:35:42 I agree with that plan 19:35:53 I think there are a couple of patches on feature/ec (like the docs one) that need to be reviewed and merged to feature/ec 19:36:02 today or tomorrow 19:36:04 yes 19:36:13 now's the time to do that 19:36:36 any other questions about what's happening around storage policies and how it's landing on master? 19:36:56 naturally, I'd expect a formal Swift release after it lands 19:37:45 whats the procedure for testing the merge? 19:37:46 ok, let 19:38:06 * elambert apologizes for noob question 19:38:13 elambert: same as normal testing of patches. pull it in to your dev or lab and run tests on it :-) 19:38:27 :-) 19:38:29 elambert: we've got a lot of built-in tests. and there are others that some deployers have too 19:38:41 and I hope they'll run those too 19:38:50 ok, so it will be run in anger before merge? 19:39:06 I like that :-) 19:39:10 hah 19:39:44 ok, let's move on. if there are other questions, feel free to ask me 19:39:51 * elambert nods 19:40:04 I have "Parallel object auditor patch: what else needs to be done?" on the agenda, but I don't know why I added that.... 19:40:06 #topic Parallel object auditor patch: what else needs to be done? 19:40:13 anyone? 19:40:14 I added that :) 19:40:27 The patch has been around for a while. 19:40:28 otoolee: ah! what's up? what needs to be done 19:40:36 otoolee: what's the link to the patch? 19:40:57 I just wanted to know if anyone needs anything else done to or with it? 19:41:23 #link https://review.openstack.org/#/c/59778/ 19:41:55 Yes. 19:42:08 Sorry, I was logging in and you beat me to it. 19:42:11 creiht: you had some comments a while back on this. would you be able to take another look? 19:42:24 well I'm still not fond of the idea :) 19:42:27 heh 19:42:31 but as I told otoolee I'm just one dev 19:42:40 if others like the idea, by all means :) 19:42:56 Thanks creiht :) 19:43:24 otoolee: so, realistically, unless it gets some attention later this week, nothing will happen to it until after storage policies are merged 19:43:34 That's cool. 19:43:47 looks like torgomatic was commenting on it too 19:43:49 I just wanted to bring it to people's attention. 19:43:52 otoolee: thanks 19:44:01 if only there were a core sponsor for it.... ;-) 19:44:09 I think that torgomatic was fine with it .... 19:44:11 :) 19:44:14 sounds like notmyname is volunteering :) 19:44:33 creiht: you only volunteer when you say something is easy :-) 19:44:51 lol 19:45:09 so actually that reminds me of one other thing related to patches 19:45:24 creiht said that the priority reviews page has been helpful in the past 19:45:37 I'll get back to updating that 19:45:48 the summit etc kinda got me derailed there :-) 19:46:17 #topic open discussion 19:46:24 anything else on your mind? 19:47:27 note the keystone token size mailing list thread 19:47:37 interesting discussion there to track 19:48:23 last call... 19:48:59 thanks for coming! 19:49:00 #endmeeting