19:02:30 <notmyname> #startmeeting swift
19:02:31 <openstack> Meeting started Wed Sep  3 19:02:30 2014 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:34 <openstack> The meeting name has been set to 'swift'
19:02:44 <notmyname> hello everyone
19:02:47 <elambert> howdy
19:02:50 <notmyname> who's here for the swift team meeting?
19:02:55 <mattoliverau> o/
19:02:56 <portante> o/
19:02:58 <peluse> and my bank account # is...
19:03:00 <cutforth> present
19:03:05 <gvernik> hello
19:03:16 <acoles> hi
19:03:38 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
19:03:44 <bnelson> hi
19:03:46 <notmyname> ^ agenda for today
19:03:48 <goodes> hi
19:03:55 <notmyname> #topic general stuff
19:03:56 * torgomatic is here for about 15 minutes
19:04:09 <notmyname> torgomatic: well, then let's go fast :-)
19:04:09 * elambert will also need to cut out early
19:04:59 <notmyname> why can't I ever find the link to the hackathon? I need to bookmark it
19:05:07 <notmyname> point is, if you're going, please register
19:05:25 <notmyname> #link https://www.eventbrite.com/e/openstack-swift-hackathon-tickets-12383404095
19:05:26 <elambert> https://www.eventbrite.com/e/openstack-swift-hackathon-tickets-12383404095
19:05:31 <notmyname> :-)
19:06:05 <notmyname> we've talked about this a lot in previous weeks, so not much to cover. if you have questions, ask tdasilva or myself
19:06:12 <notmyname> next up..paris
19:06:23 <notmyname> the conference sessions have been scheduled now
19:06:33 <notmyname> if you submitted a talk, you should have heard if it was accepted or not
19:06:49 <notmyname> that is for the conference part, not the technical sessions
19:06:57 <notmyname> so, on the topic of the technical sessions
19:07:27 <notmyname> I'm not sure what's going on with that this time. we have more programs and less space, and there's been a long thread ont he ML about how to organize it
19:07:53 <notmyname> I believe the technical sessions will try to emphasize cross-project things
19:08:19 <notmyname> and we should know soon how the scheduling will work. I think it will be different thant he webapp we've used in the past
19:08:57 <notmyname> so what I'm trying to say is that something will be happening. but I don't know what yet.
19:08:59 <notmyname> ;-)
19:09:29 <notmyname> I believe there will be some time set aside to specifically discuss some of the gap analysis things that we've talked about
19:09:46 <notmyname> and if you are there I'd very much appreciate your participating in that sessions
19:10:01 <peluse> for sure
19:10:02 <notmyname> are there any questions about the paris summit?
19:10:48 <notmyname> in other news, 2.1.0 final was cut on monday
19:11:01 <notmyname> thanks everyone for your work on it
19:11:41 <notmyname> there will be one more release for the juno integrated release. tentatively scheduled for october 6 RC date, with a final on oct 16
19:12:13 <notmyname> two other small things...
19:12:30 <notmyname> I threw together a short list of small things to work on
19:12:32 <notmyname> #link https://wiki.openstack.org/wiki/Swift/ideas
19:12:48 <notmyname> basically "I'm looking for something small to do" type things
19:12:58 <notmyname> feel free to edit it
19:13:09 <clayg> notmyname: that's a problem people have?
19:13:22 <mattoliverau> awesome
19:13:24 <notmyname> clayg: primarily for new contributors
19:13:26 <torgomatic> FWIW, on the recon one, use and support of "OPTIONS *" requests is a good way to ask a server what it is
19:13:47 <notmyname> and finally, the use survey
19:13:59 <notmyname> #link https://www.openstack.org/user-survey/
19:14:12 <notmyname> please fill this out
19:14:42 * torgomatic is out
19:14:47 <notmyname> this is used as direct evidence by people in the openstack community on what to prioritize and what's important in openstack overall
19:15:19 <cutforth> notmyname: thanks for the survey link/info.  i'll be sure to pass it on
19:15:20 <notmyname> please fill it out and talk about all the swift clusters you have. you can keep the info private
19:15:25 <notmyname> cutforth: thanks
19:16:34 <notmyname> especially as I talk to the TC and the DefCore people, this is stuff that is brought up to make claims about swift not being used. it is directly helpful to all of us to fill this out
19:16:55 <notmyname> #topic EC update
19:17:06 <notmyname> #link https://trello.com/b/LlvIFIQs/swift-erasure-codes
19:17:12 <notmyname> #link https://review.openstack.org/#/q/status:open+project:openstack/swift+branch:feature/ec,n,z
19:17:20 <notmyname> peluse: tsg: what's going on with EC this week?
19:17:29 <peluse> I need to go scrub trello real quick and make sure its up to date, have been away all morening... that said
19:17:46 <peluse> still in need of eyes on the EC patches that are out there
19:17:56 <peluse> tsg: you there for latest news on eventlet?
19:18:25 <tsg> eventlet 0.15.2 is finally out
19:18:29 <notmyname> cool
19:18:32 <peluse> awesome!
19:18:57 <tsg> there was a memory leak in the socket code that I had to help fix to make sure it was released last weekend
19:19:07 <peluse> so what are the next step on getting it usable for testing on the feature/ec branch? (for notmyname)
19:19:14 <notmyname> tsg: can you add a comment to the requirements file saying that >= that version will be required when EC lands? it will be a helpful note for all of us
19:19:16 <mattoliverau> tsg: nice work!
19:19:21 <tsg> sure!
19:19:24 <notmyname> tsg: thanks
19:19:28 <tsg> other patches: quorum_size patch is updated with Sam's comments
19:19:40 <tsg> footer patch - should be up there this week for review
19:20:12 <peluse> footer w/100-continue basked in?
19:20:28 <tsg> peluse: yes :)
19:20:32 <peluse> sweet
19:20:52 <notmyname> I'm told that as soon as a package hits pypi it will start being used in gate checks (ie latest released version that satisfies the requirements). so therefore we should already be running with that eventlet version
19:21:05 <peluse> so sounds like big patches in need of torgotmatic's eyes are (a) replicator framework and (b) quorum size
19:21:13 <peluse> argh, reconstructor
19:21:14 <tsg> notmyname: that is correct
19:21:32 <tsg> we are already running 0.15.2 eventlet
19:21:41 <notmyname> I did want to talk about process for ec patches
19:21:57 <peluse> OK
19:22:18 <notmyname> are we expecting to get two full reviews before landing, or are we looking for something softer since it will be rereviewed as is comes in to master?
19:22:44 <peluse> 2 full before landing on feature/ec if I'm not mistaken
19:22:44 <notmyname> I want to keep momentum up on getting it written, but of course I don't want bad code to land
19:23:21 <peluse> I think that worked well for SP and would be concerned that we'd end up with more work/delays when it comes time to merge to master if we change
19:23:49 <notmyname> yeah, but I also remember that being occasionally loosened for SP
19:24:24 <notmyname> so I guess the main question is if current work is blocked by needing reviews
19:24:29 <peluse> yeah, in the very early days when it was just me and torgomatic, he'd push stuff through with 1 review but I think we stayed with 2 as soon as the 3rd person joined in
19:24:46 <notmyname> :-)
19:24:50 <notmyname> ok, just checking
19:25:05 <peluse> but yes there is work blocked (sort of).  Would be easier to continue work on the other reconstructor portions if feature/ec had the reconstructor framework on it so we don't have a pile of dependencies all over the place
19:25:33 <peluse> BTW, thanks mattoliverau for looking at that one :)
19:25:36 <notmyname> peluse: which one is the first one that needs to land (first in the dependency chain)?
19:25:44 <mattoliverau> peluse: np
19:25:45 <peluse> I'll paste it in, one sec
19:26:14 <peluse> https://review.openstack.org/#/c/106910/  the framework for recon.  4 other major parts will depend on this - all outlined in the design spec at...
19:26:29 <notmyname> ok, great
19:26:31 <peluse> http://docs-draft.openstack.org/86/116486/3/check/gate-swift-specs-docs/7cc6c94/doc/build/html/specs/swift/erasure_coding.html
19:27:16 <notmyname> thanks. I put a link to that patch on the priority reviews page
19:27:24 <peluse> gracias
19:27:31 <notmyname> any other questions or discussion around the ongoing EC work?
19:27:43 <peluse> one more note...
19:27:49 <notmyname> ok
19:27:57 <peluse> reviews now are really important to make the most use of the time that those interested can spend at the hackathon
19:28:13 <peluse> that's all :)
19:28:35 <notmyname> good point
19:29:05 <notmyname> next...
19:29:13 <notmyname> #topic translations
19:29:20 <notmyname> #link https://review.openstack.org/#/c/97092/5
19:29:25 <notmyname> peluse: you asked what's up with that
19:29:51 <notmyname> I asked in -infra a little while ago...
19:29:53 <notmyname> "I believe we need/want those files to be inlcuded in our sdists. We get that cheap in that location iirc"
19:29:54 <peluse> my question here:  what's the big picture on this one?  is this a phased thing?  Are all the other projects doing it?  I just feel like something is missing wrt context on that patch
19:29:54 <notmyname> and
19:30:03 <notmyname> the exact location probably doesn't matter, but if we are consistent it makes the packaging and installation of .po(t) files much easier
19:30:13 <notmyname> both from clarkb
19:30:31 <notmyname> peluse: it seems to be a consistency thing
19:30:43 <notmyname> across all openstack projects, from what I can tell
19:30:53 <notmyname> has anyone else been a part of any of this?
19:31:07 <peluse> I guess I don't know enough to know what I'm reviewing for... just make sure the comment in the patch "test it this way" does what it says? (extracts strings) or are there other specs to be concerned about?
19:31:31 <peluse> s/specs/things
19:31:57 <notmyname> I don't know
19:32:04 <peluse> looking back at the bug there was a bunch of past conversation voicing concerns so I wasn't sure if those had been addressed offline or what
19:32:21 <peluse> here:  https://bugs.launchpad.net/swift/+bug/608725
19:32:22 <uvirtbot> Launchpad bug 608725 in openstack-i18n "swift should be internationalized/translated" [High,Confirmed]
19:33:16 <notmyname> sounds like we need to ask around. maybe start in -infra?
19:33:24 <clarkb> peluse: honestly I think the only way you fix those concerns is to start translating the strings. translators are in a position to file bugs against that stuff
19:33:43 <clarkb> peluse: but saying we shouldn't bother because the strings are bad is a good way to never get started
19:34:20 <peluse> clarkb, I've got nothing against it, just don't know enough about what's being proposed/potential issues/etc to give it a +2 so am asking here
19:34:46 <peluse> does anyone here have open concerns?
19:34:47 <clarkb> and yes chmouel's question has been answered at several summits. There are large groups of people operating the code that want this stuff translated apaprently. iirc IBM was one of them
19:35:40 <notmyname> clarkb: so how do we test it?
19:35:42 <clarkb> (and daisy is doing a lot of the work in this space so they are helping out)
19:36:06 <zaitcev> and then we see bug reports "swift-object-server: 出来ません".
19:36:15 <clarkb> to test it you can change your locale
19:36:15 <peluse> I did python setup.py extract_messages as it states in the patch and seemed to work fine.  If that's sufficient then I'm good
19:36:16 <clayg> zaitcev: :)
19:36:30 <clarkb> though changing locale may be one too many steps ahead
19:36:47 <clarkb> peluse: yes, if extract_messages updates the new location of the .pot file that is a reasonable test for this step
19:36:58 <clarkb> *update the file at the new location of the .pot file
19:37:03 <clarkb> I am failing at english here
19:37:23 <peluse> OK, will check it out... so real high level - what/who/when pulls these strings out of there?
19:37:28 <notmyname> clarkb: maybe you need to be translated. or your own pot files are in the wrong place
19:37:47 <mattoliverau> lol
19:37:54 <clarkb> peluse: any strings wrapped in the gettext format function (typically _()) will be extracted into the .pot file
19:38:16 <clarkb> peluse: zuul/jenkins will do this on every commit that is merged and sync that with transifex so that translators always have up to date .pot information
19:38:31 <peluse> so the pot file will change when we change strings in the code and we don't have to worry about it?
19:38:34 <clarkb> peluse: then once a day we sync the other direction and pull the .po files from transifex, commit them in your tree and push taht for review
19:38:55 <clarkb> peluse: for the most part that is correct. you have to worry about it when we do the daily sync the other direction
19:39:02 <peluse> nice
19:39:07 <notmyname> interesting
19:39:11 <clarkb> peluse: this will create a new change if there isn't one already and update that each day rather tahn creating a new change
19:39:12 <peluse> can I get this capability to use w/my teenage daughter?
19:39:36 <notmyname> heh
19:39:37 <clarkb> that change can be ignored until you are ready to sync if you prefer
19:40:06 <notmyname> clarkb: and so the patch pushed back into swift will have translated strings. and, ideally, we'd confirm that those are the correct translations?
19:40:17 * peluse is ready to test again (change location this time) and +2 if notmyname is good with it
19:40:42 <clarkb> notmyname: that is a tricky question :) I think most projects don't have the ability to vouche for all of the translations and there is a degree of trust between devs and translators on transifex
19:40:43 <clayg> notmyname: except for the part about confirming
19:40:55 <notmyname> right
19:41:03 <clarkb> notmyname: however you can enforce things on transifex side if you have individuals that you want to delegate that to
19:41:11 <notmyname> but assuming we all had a babelfish in our ear...
19:41:35 <notmyname> peluse: sounds ok to me
19:41:42 <peluse> hell, I'll volunteer for the English translations :)
19:41:44 <clarkb> notmyname: I would do that enforcement there rather than git. The git side is more that it didn't break code somehow eg if you take a string like "foo %s bar" and translate it to "bar foo" any substitution will fail
19:42:03 <acoles> peluse: careful, there are many variants of english ;)
19:42:06 <notmyname> clarkb: ok. thanks for the helpful info
19:42:16 <peluse> err... American translations I mean
19:42:44 <mattoliverau> So we can have an Australian translation with out all the z's and put back the missinh u's :P
19:42:51 <notmyname> peluse anything more on that patch?
19:42:56 <peluse> yeah, thanks clarkb.  was thinking that would just sit there if we didn't chat about it in a mtg
19:43:05 <clarkb> notmyname: peluse: then the erally high level testing would be to change locale and see that translated strings come out
19:43:10 * clayg wants to recruit glange for the esperanto local
19:43:14 <peluse> got it
19:43:15 <clarkb> we don't do that automagically today
19:43:36 <notmyname> mattoliverau: matt-o submitted a patchy?
19:43:47 <clarkb> notmyname: wow we need this
19:43:51 <clarkb> I will make my local en_au
19:44:14 <notmyname> ok, moving on :-)
19:44:20 <notmyname> #topic lwn article
19:44:28 <notmyname> #link http://lwn.net/Articles/457667/
19:44:35 <notmyname> portante: this is something you brought up
19:44:38 <notmyname> I haven't read it yet
19:44:42 <notmyname> what's up?
19:44:47 <mattoliverau> will do, and clarkb: do it, then move to Oz :)
19:44:50 <notmyname> title is Ensuring data reaches disk
19:45:11 <portante> the article goes over the steps need to sync data to disk
19:45:42 <portante> I am poking at this because I don't believe we do what it recommends, and wanted to bring this to folks attention to review
19:45:56 <notmyname> portante: ok. sounds like homework then :-)
19:46:18 <portante> In particular, a fsync() of the directory fd would be needed to ensure the renamed file on a PUT is properly persisted
19:46:36 <notmyname> interesting
19:47:01 <clayg> really?
19:47:02 <portante> for account, container and object, all directory operations are not fsync'd if I remember the code and am still able to read the current code correctly. :)
19:47:07 <notmyname> portante: ok, let's all go read it this week and compare it to what swift does (and submit patches as necessary)
19:47:49 <portante> the file system team at red hat sits across the hall from us on the performance team, so I can ask questions if necessary
19:47:59 <notmyname> cool
19:48:15 <portante> the article is nice in that is has the specific swift use case in it
19:48:17 <zaitcev> For the context, we had a conversation with Ric Wheeler in attendance, and I mentioned the 0-byte files as supposed being equivalent of lost+found. Ric bristled at that. He said it's an old myth that has no ground in reality.
19:48:20 <notmyname> #action go read http://lwn.net/Articles/457667/ and compare to what Swift is doing
19:49:03 <notmyname> portante: thanks for bringing it up
19:49:09 <portante> welcome
19:49:13 <notmyname> #topic priority reviews
19:49:18 <notmyname> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
19:49:26 <notmyname> I updated the priority reviews page
19:49:41 <notmyname> it now has a section at the top for things that IMO should land in the juno integrated release
19:50:00 <notmyname> there's also another section for EC work (with the current blocker linked)
19:50:29 <notmyname> cschwede will be looking at the keystone patch in the next day or so, so I think that's covered
19:50:52 <notmyname> the other things I listed have to do with performance and with improvements to known issues or limitations with existing features
19:51:00 <notmyname> eg improving global replication
19:51:38 <notmyname> also, seeing as many people end up using the integrated release and not the more frequent swift release, I also listed the config change to make bind_port explicit
19:51:58 <mattoliverau> good move
19:51:59 <notmyname> I'm sure other things will come up, but there are the ones that are currently open that I'd like to see land
19:52:15 <notmyname> basically, we've got 4 weeks
19:53:09 <notmyname> if you have other things to add to that list, let me know and let's get them added
19:53:17 <notmyname> mattoliverau: how's your abandon script working this week?
19:53:37 <mattoliverau> Good, I get BCC'd
19:53:50 <notmyname> I see that http://abandoner.oliver.net.au/abandoned_changes.html
19:53:52 <zaitcev> I wasn't sure about making bind_port obligatory, but on second thought it's better than springing a new default port on people.
19:53:53 <notmyname> I see that http://abandoner.oliver.net.au/abandoned_changes.html is empty
19:54:11 <mattoliverau> i reset the database when it went live, so the list will take 14 days to start populating
19:54:11 <notmyname> zaitcev: ya, that's the plan. to first make it explicit, then change the recommendation
19:54:12 <zaitcev> Because the consequences are better linked to the change, easier to notice and correct.
19:54:16 <notmyname> mattoliverau: ah ok
19:55:08 <notmyname> we've got about 5 minutes left in the meeting. are there any specific patches (beyond the translation one) that we need to discuss this week?
19:55:10 <mattoliverau> there is a bunch of changes what could be considered abaondoned but we'll give the owns 2 weeks to do something or nothing.
19:55:19 <notmyname> ok
19:55:21 <mattoliverau> now that they have been notified
19:55:50 <notmyname> good
19:56:12 <notmyname> ok, thanks everyone for coming
19:56:14 <notmyname> see you next week
19:56:16 <notmyname> #endmeeting