19:01:08 #startmeeting swift 19:01:09 Meeting started Wed Aug 6 19:01:08 2014 UTC and is due to finish in 60 minutes. The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:12 The meeting name has been set to 'swift' 19:01:17 o/ 19:01:17 hello everyone 19:01:22 who's here for the swift meeting 19:01:23 ? 19:01:25 hello 19:01:28 hello 19:01:29 here 19:01:30 present 19:01:33 o/ 19:01:36 yo 19:01:43 o/ 19:02:04 agenda is at https://wiki.openstack.org/wiki/Meetings/Swift as normal 19:02:05 o/ 19:02:07 hello 19:02:15 glad to see you all here 19:02:23 a few important things to talk about, I think 19:02:32 first up, some general housekeeping 19:02:38 #topic general housekeeping 19:02:42 two things 19:02:52 first, peluse is now in swift core. 19:02:54 yay! 19:02:58 woo! 19:02:59 woot! 19:03:02 congrats Paul 19:03:04 thanks!! 19:03:11 nice! congrats! 19:03:18 don't mess wit d'man! 19:03:22 Good. 19:03:24 :) 19:03:25 peluse: congrats 19:03:43 * peluse needs a tissue 19:03:45 and second up, the swift hackathon 19:03:49 peluse: heh 19:03:54 Hi 19:03:59 next week the hackathon invites will be public 19:04:14 it will be in boston during the bridge week between spet-and oct 19:04:22 err 19:04:27 september and october 19:04:39 nice! 19:04:40 space is pretty limited, I'm told, so register soon :-) 19:04:48 that's coming next wednesday 19:05:09 and thanks to tdasilva for coordinating that from the red hat side :-) 19:05:22 np 19:05:35 a could of other things 19:05:41 (going out of order on the agenda) 19:06:14 I'm hoping for a swift release in a few weeks (end of august timeframe) 19:06:28 I'll be looking at what's landed and what's outstanding to see when the best time is 19:06:38 this should give us time for another at the end of the openstack cycle 19:06:50 so be aware that's on the horizon 19:07:37 and, I'd like to give a little update on the EC mini-hackathon we had at box the past couple of days 19:07:42 it was really productive 19:07:51 we got a lot of the remaining work sketched out 19:08:02 the trello board is up to date with what needs to be done 19:08:03 https://trello.com/b/LlvIFIQs/swift-erasure-codes 19:08:21 frankly, there's a lot of work, but nothing that is particularly scary 19:08:37 please jump in and pick up tasks from there to work on 19:08:49 the swift spec for the erasure coding work is at http://specs.openstack.org/openstack/swift-specs/specs/swift/erasure_coding.html 19:08:56 that has a lot of the detail 19:09:14 sidenote: if you grab a task please make yourself a card member, if you're just intersted in tracking a task plase don't add yourself (but you can register for udpates) 19:09:15 and importantly, the trello stories have a number on them that corresponds to the spec sections 19:09:37 any questions on the EC work? 19:10:12 tushar (tsg) has some patches up on the ec branch that are pretty much ready to go 19:10:24 we did some code review and he made a coupld of improvements 19:10:37 but please look at them to see some of the read and write patch for ec 19:11:06 and please feel free to ask myself or peluse about the current status of stuff at any time 19:11:11 Can I join Performance Analysis card on Trillo for erasure code? 19:11:26 I've started pyeclib benchmark... 19:12:01 kota: just use the 'register' button inthe card to indicate interest or if you have a task you want to take that's specific you can add a new card, or add yourself to the card and make an activity note as to what scope you are looking at 19:12:33 peluse: Ok, thanks. 19:12:35 example: feel free to add a specific task to benchmakr pyeclin :) 19:12:40 i think mjseger might be interested in that (performance analysis) too, maybe i should ping him… 19:12:57 cschwede_: mjseger_ just joined :-) 19:13:03 ;) 19:13:08 yup, and multiple folks can and should benchmark too so multiple members is great (on the card) 19:13:21 hehe, nice :) 19:13:39 just trying to keep 'members' limited to people that are actively working so we know where things are in need of more resournces is all... 19:13:51 if someone finds that they aren't a member of the board, let me know and I'll add you 19:13:58 peluse: +1 19:14:39 any other questions about EC before we move on? 19:15:47 ok. /me takes deep breath 19:15:58 #topic swift TC gap analysis 19:16:08 ok, now for the "fun" one 19:16:21 up front, I want to say that this is mostly a report of what's happenign 19:16:32 here's the backstory: 19:16:59 over the years, the TC has created a set of rules for project joining as incubated and then moving to integrated projects within openstack 19:17:22 typical and inevitable 19:17:40 now that there is a set of rules, they are going to all the existing projects and seeing how these existing projects line up with the rules 19:18:00 this "gap analysis" then has been going on with all of the projects, and swift's turn during the TC meeting was yesterday 19:18:06 "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." -- Ralph Waldo Emerson 19:18:23 the etherpad with the rules is at https://etherpad.openstack.org/p/swift_gap_analysis 19:18:29 torgomatic: well quoted 19:18:32 and the meeting logs are at http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-08-05-20.02.html 19:18:33 thank you 19:18:37 here's the summary: 19:18:48 two major "gaps" were identified 19:19:03 importantly, gaps is in quotes, because they may or may not be 19:19:04 torgomatic: I also think you have rightly identified a major difference in swift vs the rest of openstack: on data path vs in control path 19:19:11 so, differences 19:19:29 these are our use of oslo libraries and our versioning/releases 19:19:30 that one fact does not appear to be considered by folks from that TC meeting 19:19:47 here's what happens next: 19:20:37 we've known than there are differences, but now we either need to get official approval that the differences are or or we need to change to match the rest of openstack 19:20:55 during the next weeks or months, this "conversation" will be had 19:21:25 either online before the summit or in person in paris 19:21:29 if we choose to change something, then that task will be tracked by the TC 19:22:15 and so we, as a community, need to choose what we do. importantly, if we do not want to change, we must convince the TC that the benefits of us being different are better than conformity with other openstack projects 19:22:38 I have already started an email thread with all the core devs, and this is something that will be an ongoing discussing 19:22:56 and I would like all of your input and help. either way you feel ont he matter 19:23:18 ok, that's my intro to it. what questions do you have? :-) 19:23:59 what is the forum for consolidating all the input from this community? 19:24:19 you have a core devs email, should we have an etherpad that enumerates the ideas? 19:24:27 portante: there isn't one yet. what would you prefer to use? etherpad? wiki? 19:24:49 +1 to etherpad 19:24:50 I'd like to invite the TC members to a discussion with the core devs of swift 19:25:12 portante: yes. but that would probably be better in person, IMO 19:25:17 portante: irl? 19:25:38 does it have to be decided by k-summit in Paris? 19:26:06 It seems like they want a decision sooner or later, but is there a deadline for deciding? 19:26:10 portante: the scope of the changes are such that I expect any changes to be made during the k cycle 19:26:19 no official deadline now 19:26:38 ie I don't expect changes to be made in the juno cycle 19:26:46 notmyname: I think we need to do changes over multiple releases, I don't think it is reasonable to expect all changes in one cycle 19:27:23 not that I am suggesting we make any changes, just that the nature of production use would require that 19:27:29 portante: of course. I expect that decisions over what, if anything, should be changed will be made by the end of the paris summit. I don't expect changes to be implemented until after that 19:27:49 further, I believe that we should have this discussion with the big production users, and get their feedback 19:28:07 it is not clear to me that this kind of change should only be decided by the devs 19:28:12 ops-in! 19:28:30 * notmyname is debating what to say in a public, logged forum ;-) 19:28:38 * torgomatic is not a fan of making a change merely for the sake of conformity 19:29:02 if I have to decide between forcing operators to do a bunch of work vs. having some conditionals in infra's scripts, I'm going with the operators 19:29:15 we have a chance to help educate the larger openstack community about what openstack swift really is 19:29:47 torgomatic: agreed, but let's see if we can't get that in an illustrated form ... 19:30:38 portante: indeed 19:30:46 we need to educate the TC about data plane APIs, they seem to be stuck on control plane APIs only 19:30:47 I think it's safe to say that if we present an argument against conformity, we will have a lot of work to do as a group that includes education and input from deployers 19:31:38 portante: note that on a mailing list thread this week, some have been advocating that openstack is indeed a provisioning layer for other technology 19:31:51 notmyname: I am not sure that taking up conformity as the root of this is accurate; it would communicate that swift is just like the other projects, and it is not 19:32:11 portante: yes, I think that's a good and right perspective 19:32:21 here's what I want to do next 19:32:48 I want to continue to hammer out some semblance of a "position" with the core devs over the next week or two 19:33:04 and I want to solicit input from the wider community (starting here today!) 19:33:35 and then, after we have some sort of internal plan, I want to begin engaging, face-to-face if possible, with the TC 19:34:29 but to be honest, the last 24 hours haven't been so good for me, and so I know I'm not mentally or emotionally ready to make decisions one way or the other 19:34:50 Until Sam's e-mail I didn't realize just how off-kilter Oslo has become. 19:35:24 for the record, sam (torgomatic) reference the mailing list post about up to 80% degredation when using oslo.messaging with swift 19:35:31 Version seems like a non-issue to me, semantic-schemantic. 19:35:42 heh 19:35:45 It's possible that I'm missing something, but if I'm right, using oslo.config would be a major regression in terms of functionality available to deployers 19:36:10 torgomatic: I think the same can be said for oslo logging too 19:36:15 to me, the release is a non-issue, just create community releases via github or something, no need to involve openstack mechanism 19:36:25 portante: +1 19:36:32 most likely; python's logging framework has been hammered on by lots of folks for a long time... and then there's oslo.logging 19:36:34 that's an interesting though 19:36:50 I only dealt with Olso through the Guru Meditation initiative, which seemed like taking an excellent idea and applying a dozen of opaque layers of useless abstractions, then not implementing basics that Swift needed. 19:36:57 torgomatic: to be fair, both use python's logging module. just we use a syslog handler and they don't 19:37:14 notmyname: thanks; I did not know that 19:37:14 notmyname: it can use the syslog handler too 19:37:17 but there's is "configurable" 19:37:36 clarkb: that's good to know too. thanks 19:37:37 * torgomatic retracts the comment about oslo.logging 19:37:47 clarkb: it's still incubated oslo, though, right? 19:37:55 clarkb: so therefore copy/paste 19:38:15 notmyname: yes I think so 19:38:22 clarkb: ok, thanks 19:38:56 to me the use of oslo.config and the possibility of breaking all existing middlewares (inside and outside of swift) looks really frightening 19:39:36 that will require a lot of work, not only from the current swift developers 19:40:04 and operators might delay upgrading of swift, because of lacking resources to update their custom middlewares 19:40:23 let's continue to debate it in email, and I'll set up an etherpad for continued discussion 19:40:26 does that sound good? 19:40:33 yup 19:40:36 notmyname: +1 19:40:37 +1 19:40:41 yep 19:40:48 +1 19:41:03 thanks, everyone. 19:41:15 +1 19:41:17 notmyname: lets be careful to treat the versioning and oslo issues separately, i'm seeing less resistance to the former 19:41:41 acoles: correct. they are differnt issues and it's not a black/white choice of all or nothing 19:42:39 now, normally we cover patches in the meeting, but to be honest the gap analysis stuff has kinda taken it all out of me for today. I'd be happy if someone wanted to cover some stuff in #openstack-swift, but would anyone object to ending the meeting now? 19:43:09 cool by me 19:43:20 no problems here 19:43:33 thanks everyone for attending and for your work in swift. 19:43:36 #endmeeting