21:00:14 <notmyname> #startmeeting swift
21:00:14 <openstack> Meeting started Wed Sep 14 21:00:14 2016 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:15 <joeljwright> woooo!
21:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:18 <openstack> The meeting name has been set to 'swift'
21:00:20 <notmyname> who's here for the swift meeting?
21:00:25 <notmyname> joeljwright's excited!
21:00:31 <joeljwright> :)
21:00:33 <ntata> Hello!
21:00:35 <mathiasb> \o
21:00:36 <bkeller`> o/
21:00:37 <m_kazuhiro> o/
21:00:39 <kei_yama> o/
21:00:40 <jrichli> o/
21:00:41 <Guest59079> Hi
21:00:47 <kota_> hello
21:00:55 <tdasilva> hi
21:01:00 <clayg> ON TIME
21:01:07 <notmyname> clayg: whoa!
21:01:17 <clayg> hold on bbiab
21:01:22 <mattoliverau> o/
21:01:23 <kota_> clayg: no delayed!
21:01:28 <timburke> o/
21:01:29 <sgundur_> hi
21:01:34 <notmyname> clayg: nah, I figure you'll just give acoles_ a hard time ;-)
21:01:54 <notmyname> Guest59079: mmotiani?
21:01:58 <acoles> LATE :/
21:02:07 <pdardeau> also late o/
21:02:09 <Guest59079> notmyname: Yes :-)
21:02:10 <notmyname> acoles: guess who was on time?
21:02:14 <cutforth> o/
21:02:18 <acoles> notmyname: I saw
21:02:59 <notmyname> agenda for this week is below. summary is to cover the things needed for the release and to go over some golang plans, based on a call several of us had last friday
21:03:01 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:03:14 <notmyname> welcome, everyone
21:03:16 <notmyname> #topic release prep
21:03:32 <notmyname> as I said last week, the newton release is at the end of the month
21:03:40 <notmyname> #link https://releases.openstack.org/newton/schedule.html
21:03:54 <notmyname> which means that our final release has to be done by then
21:04:17 <notmyname> so here's the good news: based on how we work and do releases generally, we can tag and release at any time
21:04:47 <notmyname> the "bad" news then, is that there's several things that would be really good to have in the release, and if that's going to happen, they need to be landed asap
21:05:17 <notmyname> and by asap, mostly I mean in time to tag a release next week
21:05:51 <notmyname> I'll be traveling next week (sun-thurs), but I'd like to tag something in the 2nd half of next week
21:06:06 <notmyname> so let's look at reviews
21:06:07 <notmyname> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
21:06:32 <clayg> #asifwehaven'talllookedatthereviewsalready
21:06:37 <notmyname> I took all the stuff I knew of and people brought to my attention and put it in 3 buckets
21:06:40 <notmyname> lol
21:06:47 <notmyname> clayg: you've been doing great!
21:06:58 <acoles> looks like https://review.openstack.org/#/c/348495/ has merged today so can be struck off the list
21:06:59 <patchbot> patch 348495 - swift - Make container sync copy SLO manifests (MERGED)
21:07:07 <notmyname> nice!
21:07:39 <notmyname> I updated the wiki page
21:08:08 <notmyname> ok, the last 2 int he top section are related to EC. also, both are by acoles
21:08:28 <clayg> swift 2.acoles
21:08:29 <notmyname> they are being reviewed, actively, now, and acoles is super busy responding to it :-)
21:08:58 <notmyname> https://review.openstack.org/#/c/215276/ by kota_ and clayg
21:08:58 <patchbot> patch 215276 - swift - Enable object server to return non-durable data
21:09:10 <clayg> notmyname: and timburke
21:09:17 <kota_> ;-)
21:09:20 <notmyname> and https://review.openstack.org/#/c/355958/ by tdasilva and mattoliverau
21:09:20 <patchbot> patch 355958 - swift - EC - eliminate .durable files
21:09:29 <clayg> so basically it's like the worst possible three reviewers if the goal is to get it landed :\
21:09:36 <notmyname> heh, yeah
21:09:52 <acoles> plus I can't remember how it worked after a year
21:10:06 <mattoliverau> lol
21:10:20 <acoles> but it *does* work
21:10:33 <clayg> i'm in no rush to land the eliminate .durable files - ondisk formats are forever
21:10:34 <notmyname> acoles: I'm sure it will be great (eventually)
21:10:50 <notmyname> if you are looking for a way to help get the release done, then start going down the list on the wiki would be helpful
21:10:53 <clayg> i mean if it's perfect and helpful great - otherwise - let's not try to get in something in a pinch
21:11:20 <notmyname> right. TBH, I want to see one of those EC ones land. I'd be happy with that
21:11:26 <mattoliverau> clayg: but think about the inodes.. wont anybody think about the inodes :)
21:11:42 <clayg> mattoliverau: didn't you -1 it!?
21:11:43 <notmyname> and we don't need to rush. we'll have another release like a month after barca
21:11:47 <acoles> clayg: notmyname also those two conflict so perhaps we should pick one
21:11:54 <mattoliverau> clayg: sure, I hate inodes :P
21:12:02 <clayg> mattoliverau: i love some inodes - i'm saying we should prioritize stuff that is going to land over stuff that is not
21:12:05 <tdasilva> acoles: i was wondering about that
21:12:18 <notmyname> acoles: do you have a preference?
21:12:21 <clayg> optomistic gets would be really great - the linked bugs are terrible
21:12:39 <notmyname> acoles: code complexity wise
21:13:44 <acoles> notmyname: complexity wise eliminating .durables is simpler, but I'd prefer optimistic GETs because its older, enables kota's works and does fix some bugs
21:14:05 <notmyname> ok, that's the author and one reviewer saying optimistic gets. so let's do that ;-)
21:14:19 <acoles> plus the reason clayg gave - we really don't want to screw up on diskfile format
21:14:22 <kota_> +1
21:14:25 <mattoliverau> kk
21:14:43 <clayg> this is going well!
21:14:48 <notmyname> wiki updated
21:15:13 <notmyname> also, I am very very grateful to tom fifield for removing the wiki captcha for me. so much easier
21:15:49 <notmyname> wow. at this rate, we'll be done by the end of the meeting. anything else to scratch off the list? ;-)
21:15:53 <mattoliverau> notmyname: but now we won't know when you get replaced by a robot
21:16:07 <acoles> notmyname: oh yeah that captcha was so annoying
21:16:16 <notmyname> mattoliverau: "replaced". yes. I am. not. a robot. hello, fellow human
21:16:45 <notmyname> so focus on patch 215276 (and we've already go reviewers on that)
21:16:45 <patchbot> https://review.openstack.org/#/c/215276/ - swift - Enable object server to return non-durable data
21:16:48 <mattoliverau> I knew Swift stack was doing something, no wonder y'all dont sleep :P
21:17:04 <mattoliverau> +1
21:17:15 <notmyname> I know oshrit is still looking at patch 210099 for container sync and wants to see it land
21:17:16 <patchbot> https://review.openstack.org/#/c/210099/ - swift - Add process level concurrency to container sync
21:17:46 <notmyname> kota_: because it has the dependency on acoles's patch and because it's big and hasn't had reviews, I can't see how we'll get global EC landed for this release
21:18:22 <notmyname> if you are looking for something to do, look under the "would be nice to land" patches
21:18:46 <kota_> hmm....
21:19:13 <acoles> did I read earlier that jrichli might review patch 210099?
21:19:14 <patchbot> https://review.openstack.org/#/c/210099/ - swift - Add process level concurrency to container sync
21:19:22 <notmyname> acoles: I think she said that
21:19:36 <clayg> acoles: yeah i'm pretty sure she said she would do that for sure (this is so mean)
21:19:47 <acoles> thats agreed then ;)
21:19:55 <clayg> so. mean.
21:20:03 <joeljwright> :D
21:20:12 <kmARC> :)
21:20:21 <jrichli> i will take a look tonight :-)
21:20:28 <acoles> yay!
21:20:28 <mattoliverau> ^ people reading this from logs is why you come to meetings ;)
21:20:29 <jrichli> had just put it on top of list
21:20:55 <clayg> it's like we're trying to reinforce that she should *not* listen to us - this crap would never work on me.
21:21:04 <notmyname> for now, I'm feeling good about the release (with patch 215276 landed), and I'll be happy to tag when that lands. no need to rush big stuff, and no other critical bugs that I know of
21:21:05 <patchbot> https://review.openstack.org/#/c/215276/ - swift - Enable object server to return non-durable data
21:21:34 <clayg> notmyname: and after patch 215276 swift is done right?  no need to review any of the other stuff?
21:21:35 <patchbot> https://review.openstack.org/#/c/215276/ - swift - Enable object server to return non-durable data
21:22:03 <notmyname> not release related, but donagh is awesome on https://review.openstack.org/#/c/354767/
21:22:04 <patchbot> patch 354767 - swift - Corrections for the API specifications in api-ref
21:22:35 <notmyname> clayg: no. still review other stuff down the list, but 215276 is the last thing to push for in the release
21:22:48 <notmyname> other stuff is very very nice to have
21:22:56 <acoles> what about https://review.openstack.org/#/c/323950/
21:22:57 <patchbot> patch 323950 - swift - Refactor locale tests and fix unicode issue
21:22:58 <jrichli> donagh : yay for correct docs!
21:23:20 <acoles> did patch 323950 fix a bug or just fix some tests?
21:23:21 <patchbot> https://review.openstack.org/#/c/323950/ - swift - Refactor locale tests and fix unicode issue
21:23:39 <acoles> it is one of cschwede's
21:23:45 <notmyname> when I looked, it seems that there was a bug
21:23:53 <clayg> acoles: it does *not* fix a bug - nor tests - it makes it more likely to hit bugs in prod - but it actively hides the issue in tests :'(
21:24:06 <notmyname> but discussion refocused into a different one
21:24:07 <clayg> there migth be bugs
21:24:09 <acoles> clayg: oic
21:24:13 <notmyname> https://bugs.launchpad.net/swift/+bug/1580678
21:24:15 <openstack> Launchpad bug 1580678 in OpenStack Object Storage (swift) "UnicodeDecodeError when rebalancing a ring" [High,In progress] - Assigned to Christian Schwede (cschwede)
21:24:21 <clayg> oh... maybe i'm not looking at the rigth chagne - yeah that's the one
21:24:31 <clayg> i looked into it - we need to fix our mock of gettext in unittests
21:24:50 <clayg> acoles: you remember the bug in the object controller that bc found?
21:24:56 <notmyname> ah, ok. I hadn't seen your comments
21:25:12 <clayg> the unicode args from the ring made the gettext string unicode and the non-ascii utf-8 bytestring blew up?
21:25:20 <acoles> clayg: yes, think I did something on a bc bug
21:25:22 <clayg> so we had to turn the non-ascci utf8 bytestring into unicode
21:25:44 <clayg> so cschwede makes it so that *all* the gettext strings are unicode so that we will definately blow up if we try to put non-ascci bytestrings in there
21:26:00 <clayg> ... but no in tests - in tests non ascii bytestrings still go into bytestrings and we just cray
21:26:03 <clayg> *cry
21:26:40 <notmyname> clayg: yet you put a +1 on the patch
21:26:42 <acoles> got it
21:26:58 <clayg> notmyname: yeah we should totally fix that!  i like the idea of using unicode more so we can't cheat
21:27:01 <clayg> py3 is coming
21:28:10 <notmyname> I mean that it sounds like you don't like the proposed solution, but you gave it a +1. I may just need to look at it closer
21:28:41 <clayg> i like hte propsed solution but the patch needs more work - i'd be happy to make it a -1 or even fix it (after optomistic gets)
21:28:51 <notmyname> got it
21:29:07 <notmyname> acoles: ever feel like we're just trying to keep up with clayg? ;-)
21:29:45 <acoles> notmyname: I gave up on that ages ago
21:29:46 <notmyname> ok, anything else on release patches to bring up in here in this meeting?
21:30:31 <notmyname> great. then everyone should know what to do to help out to get the release done
21:30:35 <notmyname> moving on to golang
21:30:39 <notmyname> #topic golang update
21:31:23 <notmyname> last friday dfg, nadeem, clayg, acoles, tdasilva, and myself talked on a video chat about the repconn progress
21:31:24 <patchbot> (last [--{from,in,on,with,without,regexp} <value>] [--nolimit]) -- Returns the last message matching the given criteria. --from requires a nick from whom the message came; --in requires a channel the message was sent to; --on requires a network the message was sent on; --with requires some string that had to be in the message; --regexp requires a regular expression the (1 more message)
21:31:34 <notmyname> ugh
21:31:46 <notmyname> so let's see if I can summarize it correctly
21:32:21 <notmyname> we've been talking about getting the golang obj replicator into the repconn branch and that would be what we first merge
21:32:59 <notmyname> however, that separation is not very good from the golang perspective, based on what we know will happen right after because of the shared code with the obj server
21:33:12 <notmyname> so, here's the new new new plan
21:33:38 <notmyname> nadeem is refactoring the hummingbird branch
21:33:43 <notmyname> clayg is working there too
21:33:55 <notmyname> https://review.openstack.org/#/c/365849/
21:33:55 <patchbot> patch 365849 - swift (feature/hummingbird) - go: fix replicator policy bugs / big refactor
21:34:38 <clayg> notmyname: oh i haven't looked at that patch yet
21:34:47 <notmyname> and the goal is to (1) extract the stuff we know we don't want to land (like the start of a proxy server and the bench client) away from the feature/hummingbird branch and (2) selectively expose things with swift-init integration
21:34:50 <clayg> i was looking at making probetests work and swift-init boss the hummingbird entrypoints around
21:35:01 <notmyname> yeah, related :-)
21:35:15 <clayg> the swift-init stuff was ok, and fixed an issue with the user/drop_privledges stuff that's good-ish probably
21:35:25 <clayg> ... but now I don't know if we should put repconn on the replication daemon :'(
21:35:40 <notmyname> so we'll have a blob of golang that includes more than just the basic object replicator, but nothing but the object replicator will be exposed via swift-init
21:35:45 <clayg> meanwhile redbo is working on ... the container server
21:35:52 <clayg> you'd think we don't have a plan - and you'd be right
21:36:00 <notmyname> redbo: (why?)
21:36:27 <notmyname> clayg: it's more of a general idea with a buch of other things going on to
21:36:35 <clayg> notmyname: cause they already have the hummingbird replicator deployed?
21:36:47 <clayg> womm^Hcluster
21:37:00 <redbo> Why container server?
21:37:25 <clayg> notmyname: you ever feel like we're just trying to keep up with redbo?
21:37:35 <notmyname> clayg: I gave up on that years ago ;-)
21:37:41 <clayg> well played
21:37:43 <notmyname> redbo: well, more like why now. I just want to focus on getting golang in master ASAP (or whatever that looks like according to the TC)
21:37:54 <clayg> notmyname: I think when I get on with nadeem some more we'll get things moving back in the right direction
21:38:33 <notmyname> and the first parts AFAICT is getting the object server feature-compatible with the python one and the swift-init integration and repconn
21:38:42 <clayg> i'm not really sure what the answer is for how to have experiemnts like bench clients and cluster tools and container/proxy serives living on after a good swath of feature/hummingbird comes onto master
21:38:44 <pdardeau> golang in master ASAP?
21:39:03 <notmyname> pdardeau: in the sense of golang==better for users, yes
21:39:25 <redbo> I wanted to see if it would be faster
21:39:29 <notmyname> pdardeau: and in the sense of "master" being shorthand for whatever the TC will let us ship
21:39:44 <clayg> so awesome
21:39:55 <pdardeau> notmyname: thx, the second part was what i was curious about
21:40:36 <notmyname> yeah. "master" is a lot easier to type than "the results of whatever the TC election brings and further conversation based on teh current political winds". also, it's what I really want, ultimately ;-)
21:41:00 <pdardeau> notmyname: +1
21:41:27 <notmyname> anything more to cover on golang in the meeting?
21:41:28 <clayg> notmyname: that's only because you haven't been fighting with GOPATH - it would be *so* much easier to have a python/ directory in a go project than the other way around
21:42:13 <clayg> notmyname: umm... vagrant-swift-all-in-one has a hummingbird branch - patches welcome - everyone should try to spin up some golang - it's wip but basically - it'll be great
21:42:28 <notmyname> cool
21:42:41 <mattoliverau> cool
21:43:00 <notmyname> #topic open discussion
21:43:15 <notmyname> barcelona is coming up soon. I hope to see you all there
21:43:35 <notmyname> I'll set up an etherpad in the next few days to start collecting topics for the sessions
21:43:47 <notmyname> any questions about the summit?
21:44:20 <notmyname> ok
21:44:26 <kota_> just fyi, swift3 cut a release yesterday.
21:44:27 <notmyname> oh, meeting next week
21:44:32 <notmyname> kota_: yay
21:44:37 <zaitcev> I saw swift3 release.
21:45:00 <kota_> try it if you're interested in
21:45:13 <notmyname> I'll be traveling next week, so I propose skipping next week's meeting. anyone opposed? (by opposing, you are volunteering to lead the meeting)
21:45:57 * torgomatic_ stays extra quiet
21:46:07 <notmyname> yeah, that's what I expected ;-)
21:46:16 <mattoliverau> lol
21:46:24 <notmyname> no worries. stay active in -swift, and everything will be just fine :-)
21:46:29 <joeljwright> :)
21:46:31 <notmyname> I'll be online as much as I can
21:46:54 <notmyname> anything else last-minute for this week's meeting? questions? comments? or are we done?
21:47:22 <acoles> should we try to land this for the release https://review.openstack.org/#/c/354767/ or are we not yet publishing from the swift repo?
21:47:22 <patchbot> patch 354767 - swift - Corrections for the API specifications in api-ref
21:47:42 <clayg> acoles: timur says that change is better
21:47:48 <clayg> acoles: i say we land it
21:47:57 <clayg> acoles: does it need a +A?  I got a +A
21:48:01 <jrichli> acoles: I think these get built with each commit
21:48:18 <notmyname> acoles: AFAIK, it doesn't matter. since we publish docs at every commit, it only matters if docs are shipped with packages. I don't think ever happens
21:48:31 <notmyname> point is, land them whenever, and they're immediately available
21:48:49 <acoles> notmyname: oic. also I wasn't sure if the switch had been thrown so that this content is the published content
21:49:00 <notmyname> acoles: actually, I don't know the answer to that
21:49:16 <notmyname> but I can find out
21:49:17 <acoles> notmyname: we'll find out if clayg add +A :)
21:49:23 <notmyname> heh, that too :-)
21:49:43 <clayg> how can you *not* +A that -> http://docs-draft.openstack.org/67/354767/14/check/gate-swift-api-ref/8a76c27//api-ref/build/html/?expanded=show-object-metadata-detail#show-object-metadata
21:49:47 <clayg> it's beautiful
21:50:32 <notmyname> last call
21:50:32 <patchbot> (last [--{from,in,on,with,without,regexp} <value>] [--nolimit]) -- Returns the last message matching the given criteria. --from requires a nick from whom the message came; --in requires a channel the message was sent to; --on requires a network the message was sent on; --with requires some string that had to be in the message; --regexp requires a regular expression the (1 more message)
21:50:44 <acoles> last --with last
21:50:44 <patchbot> [21:50:34] <notmyname> last call
21:50:44 <jrichli> :-)
21:50:59 <notmyname> go home patchbot. you're drunk
21:51:04 <mattoliverau> lol
21:51:10 <jrichli> i still kinda like the new patchbot
21:51:19 <timburke> don't have to go home, but you can't stay here
21:51:23 <notmyname> ok, I think we're done
21:51:33 <notmyname> thanks for your work on swift
21:51:41 <notmyname> #endmeeting