19:04:00 #startmeeting swift 19:04:01 Meeting started Wed Jul 10 19:04:00 2013 UTC. The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:04:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:04:04 The meeting name has been set to 'swift' 19:04:05 * portante finally sees that as raising a hand 19:04:15 :-) 19:04:31 given that only three of us are here, we can prolly keep this short 19:04:46 the only agenda item that I know of is portante and/or zaitcev talking about diskfile refactors 19:04:57 great 19:05:07 do we all agree that it should be done? 19:05:12 well, you may have seen a little blog post :-) 19:05:13 http://swiftstack.com/blog/2013/07/10/erasure-codes-with-openstack-swift/ 19:05:21 I have heard about it 19:05:23 #topic diskfile refactors 19:05:38 portante: yes, I think diskfile refactors are good 19:05:48 great, any other topcs? 19:05:51 ;) 19:05:53 lol 19:05:57 o/ 19:06:06 o/ 19:06:12 well, there's DB broker too 19:06:13 aquaducts? 19:06:19 portante: I have a questions 19:06:26 ah, so there are other people lurking 19:06:39 portante: how will a deployer be able to select a disk file implementation? 19:06:40 any other lurkers out there? 19:07:01 as in, your glusters stuff monkey patches swift, but IMO that's not great 19:07:04 I don't know how a lurker would answer that question truthfully 19:07:14 right now we use the configuration file to just pick the python class of the outer layer 19:07:23 torgomatic: FWIW, I'm "not my name" 19:07:40 portante: as in a use=egg#... line? 19:07:44 yes 19:07:56 the object server has a _diskfile() method that is now the one spot responsible for instantiation of a DiskFile object 19:08:03 So, it's not exactly what's commonly understood as "monkey patching", when code changes global semantics of classes or functions by assigning to htem. I think. 19:08:06 the outer class is just a subclass of the servesr that invokes a different diskfile object 19:08:09 did I miss a patch that is doing that in swift right now? 19:08:19 so if you wanted to cram something in there, that'd be a good spot maybe 19:08:48 torgomatic: take a look at the refactoring work, though 19:09:03 portante: I reviewed the first patch in the series 19:09:27 I wanted to get away from overloading _diskfile(), _get_account_broker(), and _get_container_broker(). But honestly I do not have a whole lot of reasoning, I just hate when API implementors (even in-tree ones) do stuff like that 19:09:28 don't you read the last page of the book before the rest? ;) 19:09:40 hate? 19:09:50 Yeah, like *rawr* 19:10:09 zaitcev: it's funny to me reading that in your russian accent ;-) 19:10:12 could make swift.obj.server.ObjectController() take an optional diskfile_class arg that defaults to the obvious thing 19:10:22 yes 19:10:29 see the refactoring work. :) 19:10:40 hint hint 19:10:45 :) 19:10:53 Actually that's in 30051 already, it's called disk_klass or something 19:11:09 With German accent. 19:11:11 the parameter to the controller, I think so 19:11:21 i'm itialian, though 19:11:48 maybe I should have called is disk_pizza 19:11:52 we should call it disc_klass just to be sure nobody can ever type it 19:12:02 yes! 19:12:07 Oh god 19:12:36 seriously, though 19:12:42 Seriously though, the biggest problem is, are we in time for Havana 19:12:42 portante: do you have specific topics or questions you want to raise in here today? beyond "do we want it?" 19:12:42 I added klass to daemon onetime and always regretted it, pep8 acctually says to use a trialing _ to avoid keyword naming conflicts 19:12:47 anyhow, it sounds like the existing refactors could use some more reviewers, especially since they're chained together 19:12:48 i.e. hash_ and class_ 19:12:58 I would like to drum up support to get some review eyes on it 19:12:59 clayg: assert_ 19:13:04 notmyname: ^^^ 19:13:18 portante: I've been busy writing blog posts about erasure codes :-) 19:13:20 portante: I'll look at it! 19:13:30 don't know if you consider that a good thing :\ 19:13:44 clayg: I do, thanks! 19:14:06 oh phew, finally got to the first one :\ 19:14:18 That was rather vague post, I saw it. It said "we have proposals on the table" but did not link to blessed proposals. Man, they even publish contestants of government tenders for secret misslies. 19:14:28 there is one wart in it that I would love to have some mind share on, that is with the new DiskReader class 19:15:03 the current code passes all the unit tests, but I have not run it against the functional tess 19:15:06 tests 19:15:10 tell meee 19:15:47 portante: we have a DiskWriter now right? what's one more? 19:16:07 the submits leading up to the last one were done to address the API changes that affect existing code, hiding interfaces to make it easier to identify the nature of an on-disk implementation 19:16:12 DiscRighter? 19:16:56 So, Peter, what's the wart? 19:16:56 the DiskReader and DiskWriter classes are helper classes that allow an implementation to change how reads and writes are performed with the caller using a simple interface to get them 19:17:28 portante: I'm not sure how that last comment was directed at - everyone here agree's it's a good idea asfaik - I acctually think you've made a lot of good progress already; it's not surprising you have to rattle the cage in the last mile 19:18:03 the DiskReader object inherits the open file from the DiskFile class, to avoid having to open it again 19:18:28 but the handoff point as to who closes that file is tricky 19:19:16 a with context is used to hide the caller having to know when it should close it, but the app_iter object still needs it open long after PUT API code starts the wsgi response 19:19:50 if folks are open to it, I would not mind doing a guided walk through on hangouts or something 19:20:15 @portante: +1 19:20:32 portante: k, i'll need to familiarize myself then; i sorta want to say if you have stuff like that leaking between classes and it looks weird; it's probably because they should be the same class? Or everything under a module of some kind? Like a single class that's passed to functions which can be swapped out via entrypoint... 19:20:36 portante: I think that's a good idea 19:20:37 I see. 19:20:56 clayg: yes, perhaps 19:21:07 notmyname: regarding the guided hangouts walk through? 19:21:22 yes 19:21:41 do we have a swift email list that I should post a time request? 19:21:50 notmyname: can you action portante to schedule that - maybe on the ML 19:22:03 no, there is just the openstack list 19:22:03 which ML? 19:22:14 k that is where I'll action it. 19:22:15 ;0 19:22:17 ;) 19:22:17 portante: let's do it before the next meeting but maybe with some runway so I can read the code before-hand 19:22:24 portante: I'd suggest choosing a time next week 19:22:32 portante: I would move that open from DiskFile.reader() into DiskReader.__init__(). It's not like you're re-using the old _fp that init of DiskFile sets up 19:22:33 how wed next week? 19:22:57 #action portante to chose a time for a guided walkthrough of the DiskFile refactors and progress 19:23:22 k 19:23:25 portante: works for me 19:23:32 okay. At least portante has something to show. I need to catch up 19:23:36 portante: yeah same time next week wfm, but you should send something out for folks that aren't here 19:23:43 yes 19:23:48 portante: you're talking about a google hangout, right? 19:23:50 I'll do that onthe openstack mailing list 19:23:54 yes 19:23:55 :) 19:23:57 is that bad or good? 19:23:59 portante: the openstack-dev list 19:24:04 heh 19:24:06 sorry, yes, openstack-dev 19:24:30 portante: google hangouts are fine. maybe I can figure out how to use the openstack swift page I have there to officialize it or something 19:24:40 okay, that would be great 19:24:49 since david's not here I'll thorw out reviews for account-acl -> https://review.openstack.org/#/c/32808/ 19:25:01 I'll do more work in the mean time on documentation and take in early review feedbavck 19:25:06 I think it's a great feature, david's worked really hard and my eyes are getting squnity 19:25:30 #help requested on account-acl reviews https://review.openstack.org/#/c/32808/ 19:25:47 anything else to cover for now (5 minutes left) 19:26:04 I am available for questions any time 19:26:26 I would say that one of the other refactorings that we need to do 19:26:49 is to address redundant operations on the marshall and unmarshall paths 19:27:18 for the servers, we access dictionaries repeatedly for the same value many many times over 19:27:56 that kind of work will like to making it easier to see where a DiskFile or DatabaseBroker interface layer can be clearly defined 19:28:22 much of the lead up work to the current refactoring has been analyzing that layer to make sure it does not spill over into the lower layers 19:28:35 or vice-versa 19:29:25 Also, Pete Z is starting to work on the DatabaseBroker refactoring 19:29:50 will be joining him on that after DiskFile winds down 19:29:54 yay! 19:29:56 nothing else from here 19:30:09 cool 19:30:16 and I gotta run from this side. 19:30:25 portante: zaitcev: thanks for you time and effort 19:30:28 welcome 19:30:28 np 19:30:33 thanks everyone for your time today 19:30:35 #endmeeting