19:04:00 <notmyname> #startmeeting swift
19:04:01 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:04:04 <openstack> The meeting name has been set to 'swift'
19:04:05 * portante finally sees that as raising a hand
19:04:15 <notmyname> :-)
19:04:31 <portante> given that only three of us are here, we can prolly keep this short
19:04:46 <notmyname> the only agenda item that I know of is portante and/or zaitcev talking about diskfile refactors
19:04:57 <portante> great
19:05:07 <portante> do we all agree that it should be done?
19:05:12 <notmyname> well, you may have seen a little blog post :-)
19:05:13 <notmyname> http://swiftstack.com/blog/2013/07/10/erasure-codes-with-openstack-swift/
19:05:21 <portante> I have heard about it
19:05:23 <notmyname> #topic diskfile refactors
19:05:38 <notmyname> portante: yes, I think diskfile refactors are good
19:05:48 <portante> great, any other topcs?
19:05:51 <portante> ;)
19:05:53 <notmyname> lol
19:05:57 <portante> o/
19:06:06 <clayg> o/
19:06:12 <zaitcev> well, there's DB broker too
19:06:13 <portante> aquaducts?
19:06:19 <notmyname> portante: I have a questions
19:06:26 <portante> ah, so there are other people lurking
19:06:39 <notmyname> portante: how will a deployer be able to select a disk file implementation?
19:06:40 <portante> any other lurkers out there?
19:07:01 <notmyname> as in, your glusters stuff monkey patches swift, but IMO that's not great
19:07:04 <torgomatic> I don't know how a lurker would answer that question truthfully
19:07:14 <portante> right now we use the configuration file to just pick the python class of the outer layer
19:07:23 <notmyname> torgomatic: FWIW, I'm "not my name"
19:07:40 <notmyname> portante: as in a use=egg#... line?
19:07:44 <portante> yes
19:07:56 <torgomatic> the object server has a _diskfile() method that is now the one spot responsible for instantiation of a DiskFile object
19:08:03 <zaitcev> 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 <portante> the outer class is just a subclass of the servesr that invokes a different diskfile object
19:08:09 <notmyname> did I miss a patch that is doing that in swift right now?
19:08:19 <torgomatic> so if you wanted to cram something in there, that'd be a good spot maybe
19:08:48 <portante> torgomatic: take a look at the refactoring work, though
19:09:03 <torgomatic> portante: I reviewed the first patch in the series
19:09:27 <zaitcev> 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 <portante> don't you read the last page of the book before the rest? ;)
19:09:40 <portante> hate?
19:09:50 <zaitcev> Yeah, like *rawr*
19:10:09 <notmyname> zaitcev: it's funny to me reading that in your russian accent ;-)
19:10:12 <torgomatic> could make swift.obj.server.ObjectController() take an optional diskfile_class arg that defaults to the obvious thing
19:10:22 <portante> yes
19:10:29 <portante> see the refactoring work. :)
19:10:40 <portante> hint hint
19:10:45 <torgomatic> :)
19:10:53 <zaitcev> Actually that's in 30051 already, it's called disk_klass or something
19:11:09 <zaitcev> With German accent.
19:11:11 <portante> the parameter to the controller, I think so
19:11:21 <portante> i'm itialian, though
19:11:48 <portante> maybe I should have called is disk_pizza
19:11:52 <torgomatic> we should call it disc_klass just to be sure nobody can ever type it
19:12:02 <portante> yes!
19:12:07 <zaitcev> Oh god
19:12:36 <portante> seriously, though
19:12:42 <zaitcev> Seriously though, the biggest problem is, are we in time for Havana
19:12:42 <notmyname> portante: do you have specific topics or questions you want to raise in here today? beyond "do we want it?"
19:12:42 <clayg> 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 <torgomatic> anyhow, it sounds like the existing refactors could use some more reviewers, especially since they're chained together
19:12:48 <clayg> i.e. hash_ and class_
19:12:58 <portante> I would like to drum up support to get some review eyes on it
19:12:59 <notmyname> clayg: assert_
19:13:04 <portante> notmyname: ^^^
19:13:18 <notmyname> portante: I've been busy writing blog posts about erasure codes :-)
19:13:20 <clayg> portante: I'll look at it!
19:13:30 <clayg> don't know if you consider that a good thing :\
19:13:44 <portante> clayg: I do, thanks!
19:14:06 <clayg> oh phew, finally got to the first one :\
19:14:18 <zaitcev> 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 <portante> 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 <portante> the current code passes all the unit tests, but I have not run it against the functional tess
19:15:06 <portante> tests
19:15:10 <zaitcev> tell meee
19:15:47 <clayg> portante: we have a DiskWriter now right?  what's one more?
19:16:07 <portante> 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 <notmyname> DiscRighter?
19:16:56 <zaitcev> So, Peter, what's the wart?
19:16:56 <portante> 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 <clayg> 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 <portante> the DiskReader object inherits the open file from the DiskFile class, to avoid having to open it again
19:18:28 <portante> but the handoff point as to who closes that file is tricky
19:19:16 <portante> 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 <portante> if folks are open to it, I would not mind doing a guided walk through on hangouts or something
19:20:15 <cschwede> @portante: +1
19:20:32 <clayg> 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 <notmyname> portante: I think that's a good idea
19:20:37 <zaitcev> I see.
19:20:56 <portante> clayg: yes, perhaps
19:21:07 <portante> notmyname: regarding the guided hangouts walk through?
19:21:22 <notmyname> yes
19:21:41 <portante> do we have a swift email list that I should post a time request?
19:21:50 <clayg> notmyname: can you action portante to schedule that - maybe on the ML
19:22:03 <notmyname> no, there is just the openstack list
19:22:03 <portante> which ML?
19:22:14 <portante> k that is where I'll action it.
19:22:15 <portante> ;0
19:22:17 <portante> ;)
19:22:17 <clayg> 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 <notmyname> portante: I'd suggest choosing a time next week
19:22:32 <zaitcev> 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 <portante> how wed next week?
19:22:57 <notmyname> #action portante to chose a time for a guided walkthrough of the DiskFile refactors and progress
19:23:22 <portante> k
19:23:25 <notmyname> portante: works for me
19:23:32 <zaitcev> okay. At least portante has something to show. I need to catch up
19:23:36 <clayg> portante: yeah same time next week wfm, but you should send something out for folks that aren't here
19:23:43 <portante> yes
19:23:48 <notmyname> portante: you're talking about a google hangout, right?
19:23:50 <portante> I'll do that onthe openstack mailing list
19:23:54 <portante> yes
19:23:55 <clayg> :)
19:23:57 <portante> is that bad or good?
19:23:59 <notmyname> portante: the openstack-dev list
19:24:04 <clayg> heh
19:24:06 <portante> sorry, yes, openstack-dev
19:24:30 <notmyname> 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 <portante> okay, that would be great
19:24:49 <clayg> since david's not here I'll thorw out reviews for account-acl -> https://review.openstack.org/#/c/32808/
19:25:01 <portante> I'll do more work in the mean time on documentation and take in early review feedbavck
19:25:06 <clayg> I think it's a great feature, david's worked really hard and my eyes are getting squnity
19:25:30 <notmyname> #help requested on account-acl reviews https://review.openstack.org/#/c/32808/
19:25:47 <notmyname> anything else to cover for now (5 minutes left)
19:26:04 <portante> I am available for questions any time
19:26:26 <portante> I would say that one of the other refactorings that we need to do
19:26:49 <portante> is to address redundant operations on the marshall and unmarshall paths
19:27:18 <portante> for the servers, we access dictionaries repeatedly for the same value many many times over
19:27:56 <portante> 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 <portante> 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 <portante> or vice-versa
19:29:25 <portante> Also, Pete Z is starting to work on the DatabaseBroker refactoring
19:29:50 <portante> will be joining him on that after DiskFile winds down
19:29:54 <clayg> yay!
19:29:56 <portante> nothing else from here
19:30:09 <notmyname> cool
19:30:16 <notmyname> and I gotta run from this side.
19:30:25 <notmyname> portante: zaitcev: thanks for you time and effort
19:30:28 <portante> welcome
19:30:28 <zaitcev> np
19:30:33 <notmyname> thanks everyone for your time today
19:30:35 <notmyname> #endmeeting