Thursday, 2015-02-19

zaitcevlook that line 50 for the reverse transition http://paste.openstack.org/show/177211/00:04
zaitcevBut like Sam said, you can't mix and match simultaneously00:04
*** lcurtis has quit IRC00:08
*** nellysmitt has joined #openstack-swift00:19
*** nellysmitt has quit IRC00:24
*** rmcall has joined #openstack-swift00:31
*** zul has quit IRC00:32
*** dmorita has joined #openstack-swift00:32
*** jkremer has quit IRC00:35
*** david-lyle is now known as david-lyle_afk00:41
*** zul has joined #openstack-swift00:42
*** zhill has quit IRC00:50
openstackgerritLeah Klearman proposed openstack/swift: refactor kill_nonprimary_server  https://review.openstack.org/15721900:59
*** vishy has quit IRC01:07
*** vishy has joined #openstack-swift01:09
*** EmilienM is now known as EmilienM|afk01:36
*** zhill has joined #openstack-swift01:40
claygzaitcev: what sorcery is this cript!?01:44
claygfor some reason "this script" didn't autocorrect to a link to http://paste.openstack.org/show/177211/01:44
*** rdaly2 has quit IRC01:45
zaitcevclayg: I used it every time I want to upgrade Keystone, because sometimes the schema update fails01:45
zaitcevIt basically re-creates Keystone from scratch and loads all users into it.01:46
* clayg thinks he's being trolled01:46
zaitcevSince I must keep the Swift accounts as they were, it's essential to create users with the same IDs01:46
zaitcevAlthough Keystone's CLI does not permit it, the simple curl command in that script accomplishes that.01:47
claygah the good ol' bash escaped json piped to curl01:48
claygit's sorta crazy their api supports the pk in the json payload - there's bound to be a vector there :\01:48
zaitcevVector to what? It's an admin command.01:49
claygoh, ok01:51
*** devlaps has quit IRC01:55
*** SkyRocknRoll has joined #openstack-swift01:56
claygit seems keystone has embraced the eventually consistent mentality -> https://gist.github.com/clayg/4606afa9038cd30658e001:59
claygexcept I think they focused more on the "it's ok to return inconsistent results" and less on the "eventually they'll be consistent"01:59
mattoliverauLol02:00
zaitcevLooks pretty stable to me: odd tries fail, even tries pass. Something's flipping.02:01
claygyeah...02:03
*** km__ has joined #openstack-swift02:06
zaitcev"Originally the blueprint was for python-neutronclient only, but pluggable auth is a wide-reaching issue." -- nice, as if clients weren't complex enough02:07
claygoh my god oh my god oh my god - my devstack started swift!02:08
*** km has quit IRC02:08
*** nellysmitt has joined #openstack-swift02:20
*** nellysmitt has quit IRC02:24
claygholy shit, my devstack vm was firing up *10* apache processes just for keystone02:36
claygthey're only ~54M RSS, but like how much ram do they think I have in this vm?02:36
*** zhill has quit IRC02:40
openstackgerritPete Zaitcev proposed openstack/python-swiftclient: Fix crash with -l, -d /, and pseudo folders  https://review.openstack.org/15464802:47
*** zhill has joined #openstack-swift02:50
*** jrichli has joined #openstack-swift03:09
*** rmcall has quit IRC03:21
claygzaitcev: idk, i saw about to say why not just item.get('bytes', 0) - but I guess you and matt already had that dicussion?03:29
zaitcevYou mean me and Christian03:30
claygzaitcev: you are correct!03:30
zaitcevclayg: well, that certainly works, but this looks more regular to me.03:31
clayginteresting03:31
zaitcevPersonally I think the minimization of patch length is a non-goal.03:32
*** km has joined #openstack-swift03:32
claygzaitcev: thats because you haven't embraced the idea that every line of code you write is just a bug waiting to happen03:33
claygwell.... maybe that's just a difference between zaitcev's lines and clayg's lines :\03:33
claygi'm kidding i agree - write for clarity, but having to think about the unitialized None in item_bytes seems like where the bug really came from - setting a default at the top I think acctully nuters the bug harder03:34
*** km__ has quit IRC03:34
claygacoles_away: donagh: is it a good idea to publish the reseller prefixes?03:40
*** SkyRocknRoll has quit IRC03:53
*** SkyRocknRoll has joined #openstack-swift04:05
*** zaitcev has quit IRC04:09
*** nellysmitt has joined #openstack-swift04:21
*** nellysmitt has quit IRC04:25
*** silor has joined #openstack-swift04:31
clayggd keystone auth - what's the difference between a group and role?  I thought groups where just the role assigned to the user for the project within the domain!?04:47
clayghttp://docs.openstack.org/admin-guide-cloud/content/keystone-concepts.html does not have groups04:47
claygwhy do we have required_groups - wtf is a group04:48
claygoh heh04:52
* clayg is sorta embarassed04:52
claygrequired_groups was just a thing the tests made up04:53
clayg... to demonstrate the nested config opiton parsing thing04:53
klrmnclayg: wow, i didn't expect changing the tests to use self.container_brain.containter_name would cause OperationalError: database is locked exceptions that nose doesn't catch04:55
claygwat?04:57
claygklrmn: you are so in the right line of work - you're better at breaking software than anyone I know04:58
*** ppai has joined #openstack-swift05:03
*** jrichli has quit IRC05:09
klrmnclayg: it's eventlet, i don't have to try hard05:15
*** gyee has quit IRC05:36
*** sandywalsh has joined #openstack-swift05:38
*** sandywalsh_ has quit IRC05:40
*** ppai has quit IRC05:45
*** echevemaster has quit IRC05:47
*** ppai has joined #openstack-swift05:47
*** zigo has quit IRC05:54
*** zigo has joined #openstack-swift05:55
*** ppai has quit IRC06:14
*** nellysmitt has joined #openstack-swift06:22
dmoritanotmyname: I deleted 1 line from Swift (general) section in PriorityReview wiki page because that patch is already merged to master.06:23
*** nellysmitt has quit IRC06:26
*** ppai has joined #openstack-swift06:28
claygdmorita: nice work!06:29
*** ppai has quit IRC06:40
*** madhuri_ has quit IRC06:46
*** madhuri_ has joined #openstack-swift06:52
*** ppai has joined #openstack-swift06:52
*** bill_az has joined #openstack-swift07:05
*** bill_ibm__ has quit IRC07:05
claygacoles_away: donagh: phew, got a review on service tokens for ya!07:09
*** chlong has quit IRC07:19
*** ho has quit IRC07:26
*** nshaikh has joined #openstack-swift07:27
*** SkyRocknRoll has quit IRC07:34
*** SkyRocknRoll has joined #openstack-swift07:47
*** mmcardle has joined #openstack-swift07:48
claygdmorita: do you have any idea if kota is still looking at https://review.openstack.org/#/c/155542/ or should I dig back into it08:07
claygi'm not sure why i asked that, i'm about to shut down, i'll take my answer async ;)08:08
claygg'night08:08
*** rledisez has joined #openstack-swift08:10
openstackgerritKota Tsuyuzaki proposed openstack/swift: Fix efficient replication handoff delete  https://review.openstack.org/15729008:12
*** silor1 has joined #openstack-swift08:20
*** silor has quit IRC08:22
*** nellysmitt has joined #openstack-swift08:22
*** nellysmitt has quit IRC08:27
*** nellysmitt has joined #openstack-swift08:36
*** Trixboxer has joined #openstack-swift08:38
*** jistr has joined #openstack-swift08:42
*** jordanP has joined #openstack-swift08:53
*** km has quit IRC08:57
openstackgerritKazuhiro MIYAHARA proposed openstack/swift: bug fix:response code 201 in SLO conflict case  https://review.openstack.org/15729309:02
openstackgerritKazuhiro MIYAHARA proposed openstack/swift: Fix conflict SLO reponse  https://review.openstack.org/15730509:38
openstackgerritKazuhiro MIYAHARA proposed openstack/swift: Fix conflict SLO reponse  https://review.openstack.org/15730509:45
*** silor has joined #openstack-swift09:46
*** silor1 has quit IRC09:49
*** briancline has quit IRC10:22
*** briancline has joined #openstack-swift10:23
*** csmart has joined #openstack-swift10:23
*** silor has quit IRC10:28
*** ppai has quit IRC10:30
*** acoles_away is now known as acoles10:41
*** ppai has joined #openstack-swift10:44
*** aix has quit IRC11:04
*** aix has joined #openstack-swift11:05
openstackgerritDaniel Wakefield proposed openstack/python-swiftclient: Verify MD5 of uploaded objects.  https://review.openstack.org/12925411:23
*** silor has joined #openstack-swift11:26
openstackgerritDaniel Wakefield proposed openstack/python-swiftclient: Add flag to disable automatic checksum validation.  https://review.openstack.org/15667711:37
*** chlong has joined #openstack-swift11:41
*** madhuri_ has quit IRC11:58
*** dmorita has quit IRC12:05
*** agentle_ has quit IRC12:06
*** SkyRocknRoll has quit IRC12:16
*** foexle has joined #openstack-swift12:20
*** panbalag has joined #openstack-swift12:24
*** mmcardle has quit IRC12:29
*** SkyRocknRoll has joined #openstack-swift12:33
*** SkyRocknRoll has quit IRC12:40
*** mmcardle has joined #openstack-swift12:48
openstackgerritStuart McLaren proposed openstack/python-swiftclient: Allow reading from object body on download  https://review.openstack.org/15529112:58
*** EmilienM|afk is now known as EmilienM12:58
*** pconstantine has joined #openstack-swift13:03
openstackgerritStuart McLaren proposed openstack/python-swiftclient: Allow reading from object body on download  https://review.openstack.org/15529113:08
*** ppai has quit IRC13:15
*** aix has quit IRC13:29
*** rdaly2 has joined #openstack-swift13:31
*** mahatic has joined #openstack-swift13:33
*** jistr_ has joined #openstack-swift13:37
*** jistr has quit IRC13:39
*** bkopilov has joined #openstack-swift13:40
*** haomaiw__ has quit IRC13:41
*** briancline has quit IRC13:48
*** jistr_ is now known as jistr13:48
*** briancline has joined #openstack-swift13:49
*** mkerrin has quit IRC13:55
*** aix has joined #openstack-swift14:01
eikkenotmyname: any docs on what was discussed about storage policies during the sprint week?14:26
*** EmilienM is now known as EmilienM|afk14:32
*** tdasilva has joined #openstack-swift14:33
*** briancline has quit IRC14:37
*** briancline has joined #openstack-swift14:38
openstackgerritArnaud proposed openstack/swift: Add support of x-remove- headers for container-sync  https://review.openstack.org/15738814:40
openstackgerritArnaud proposed openstack/swift: Add support of x-remove- headers for container-sync  https://review.openstack.org/15738814:45
*** RackerShagz has joined #openstack-swift14:46
*** SkyRocknRoll has joined #openstack-swift14:47
*** foexle has quit IRC14:53
acoleseikke: i think notmyname is away for rest of week. there are a couple of blogs on last week:14:54
acoleshttps://thiagodasilvablog.wordpress.com/2015/02/16/openstack-swift-mid-cycle-report/14:54
acoleshttps://swiftstack.com/blog/2015/02/13/openstack-swift-hackathon/14:55
*** rdaly2 has quit IRC14:55
*** rdaly2 has joined #openstack-swift14:55
eikkeacoles: thanks. read those before ;-)14:55
*** rdaly2 has quit IRC14:56
peluseeikke, interested in something specific?14:56
eikkepeluse: we have a PoC of policy support in our diskfile, and proposed a talk about it for vancouver, so if things are going to change in that field, I'd be fairly interested :-)14:56
eikketoo bad couldn't attend the sprint14:57
acolesclayg: great, thanks! will be interesting to follow the diagnosis of your keystone issue. weird.14:57
peluseeikke, I think you're OK.  The main topics around policies were (a) a bunch of patches around better error handling/logging (b) a proposl for how to change the policy of a container (c) a proposl on how to use policies to implement tier'ing14:59
eikkepeluse: ah, ok. for (b) we're set already, and (c) should work out of the box as well :-)14:59
eikkeI mean, without changes in swift or our diskfile, only in the backend (and maybe diskfile config)14:59
peluseeikke, ahh, OK15:00
peluseand note that the big items won't happen that quickly anyway15:00
peluseb & c that is....15:00
eikkeI was positively surprised by how generic the policies implementation is, which allows us to provide quite some functionality without ugly hacks or workarounds15:01
peluseeikke, thanks, that was by design :) (by everyone that worked on it)15:12
*** delattec has joined #openstack-swift15:14
*** lcurtis has joined #openstack-swift15:18
*** jrichli has joined #openstack-swift15:28
*** SkyRocknRoll has quit IRC15:33
*** EmilienM|afk is now known as EmilienM15:41
*** MasterPiece has joined #openstack-swift15:41
*** abhirc has joined #openstack-swift15:44
*** SkyRocknRoll has joined #openstack-swift15:50
*** SkyRocknRoll has quit IRC15:54
pconstantinehi, guys, long time no see, anyway, is there a particular reason that not even single middleware in Swift is built according to PEP333?15:56
pconstantinePEP333 is a WSGI standard, btw15:56
*** nellysmitt has quit IRC15:58
pconstantinei mean specifically calling close() when finishing with app_iter's that you've got from down-stream16:01
*** annegentle has joined #openstack-swift16:04
*** david-lyle_afk is now known as david-lyle16:04
openstackgerritStuart McLaren proposed openstack/python-swiftclient: Allow reading from object body on download  https://review.openstack.org/15529116:06
*** silor has quit IRC16:09
*** nellysmitt has joined #openstack-swift16:11
glangepconstantine: is this the part of PEP333 that you are talking about?  "If the iterable returned by the application has a close() method, the server or gateway must call that method upon completion of the current request, whether the request was completed normally, or terminated early due to an error."16:28
*** wasmum has left #openstack-swift16:28
pconstantineglange: yep, that part16:28
pconstantinefor example proxy_logging does not do it16:28
pconstantineand, last time I've checked it's included in almost any chain16:29
glangelook in eventlet/wsgi.py in the method "handle_one_response()"16:29
glangeyou have "result = self.application(self.environ, start_response)"16:29
*** delatte has joined #openstack-swift16:30
glangeand lower down  you have16:30
*** wasmum has joined #openstack-swift16:30
glange            if hasattr(result, 'close'):16:30
glange                result.close()16:30
pconstantineglange: that's cool and stuff, but who will call it downstream?16:30
pconstantinelet's consider a simple chain16:30
pconstantinechain = proxy_logging16:31
pconstantinepipeline = proxy-logging proxy-server16:31
pconstantinewho will call app_iter.close() on proxy-server app_iter?16:31
glangeI don't understand what you mean, the app is what returns the iterable and the PEP says the iterable returned by the app must have its close() method called -- that seems to be happening in that method?16:31
pconstantinehint: nobody16:31
pconstantineyes, the close() of proxy-logiing will be called16:32
*** delattec has quit IRC16:32
pconstantinebut close of any other middleware in the pipeline will not be called16:32
pconstantinebecause proxy-logging does not call close() anywhere16:32
*** nellysmitt has quit IRC16:33
pconstantinehttps://github.com/openstack/swift/blob/master/swift/common/middleware/proxy_logging.py#L28716:34
*** nellysmitt has joined #openstack-swift16:35
pconstantinehere, in finally: it should do the same thing that eventlet does16:35
pconstantinei.e.16:35
pconstantineif hasattr(iterable, 'close'):16:35
pconstantine   iterable.close()16:35
*** openstackgerrit has quit IRC16:36
glangein the "Latinator" example from the PEP, where is close() called?16:36
*** openstackgerrit has joined #openstack-swift16:36
*** SkyRocknRoll has joined #openstack-swift16:36
pconstantineglange: I don't know, if it's not called, it should be called16:37
*** zhill has joined #openstack-swift16:37
pconstantineyou can check it with the debugger that none of the close() on anything downstream from proxy-logging is called ever16:37
pconstantineand it should be16:38
glangeok, stick around -- west coast people will start waking up and getting on irc soon, let's see what they say16:39
*** annegentle has quit IRC16:39
pconstantineI have checked out other proxy level middleware and it seems like only proxy_logging is actively pulling data from downstream iterators16:40
pconstantinetherefore it will be probably a small change, only in proxy-logging16:40
glangeyeah, maybe there is a problem16:40
*** annegentle has joined #openstack-swift16:40
glangemaybe it's in the iter_response() method of logging middleware16:42
*** rdaly2 has joined #openstack-swift16:42
glangeit gets an iterator and iterates through it, yielding chunks as it goes, but it doesn't call close() on the iterator it gets?16:43
glangepconstantine: what if you slapped a if hasattr(iterable, 'close'): iterable.close()  in the finally in that method?16:44
pconstantinethis is what I'm proposing :)16:45
glangeyou might be right! :)16:45
glangeand when you are right, you are right16:45
*** nellysmitt has quit IRC16:45
*** dmsimard_away is now known as dmsimard16:47
pconstantineglange: yep, it never closes the iterator it gets, therefore other middlewares are memory-leaking and people like me get a lot less hair on their behind after debugging why is it happening :)16:47
pconstantineoh, here we go, an article about that:16:48
pconstantinehttp://blog.dscpl.com.au/2012/10/obligations-for-calling-close-on.html16:48
glangepconstantine: I bet that is the only middleware that does that with the iterable, and the only reason it does that is to get the total bytes transfered16:50
pconstantineglange: probably true, but it is used twice in proxy pipeline usually ... :)16:50
pconstantinejust to ensure that no other middlewares will ever work properly inisde :)16:51
*** IRTermite has joined #openstack-swift16:51
pconstantineI mean obviously people do write other "non upstream" middlewares that will be grieved a lot by that one16:52
*** annegentle has quit IRC17:01
*** RackerShagz has quit IRC17:07
*** rledisez has quit IRC17:10
*** silor has joined #openstack-swift17:14
*** silor1 has joined #openstack-swift17:15
*** nshaikh has quit IRC17:17
*** silor has quit IRC17:19
*** nellysmitt has joined #openstack-swift17:21
glangeI made that change and it doesn't break any of the unit, functional, or probe tests17:22
glangeif it turns out to be a change we need to make, do you think we could get Graham Dumpleton, himself, to make it?17:22
glangebecause that would be awesome17:22
*** Trixboxer has quit IRC17:25
*** jistr has quit IRC17:28
*** zaitcev has joined #openstack-swift17:30
*** ChanServ sets mode: +v zaitcev17:30
*** csmart has quit IRC17:33
*** csmart has joined #openstack-swift17:33
openstackgerritAlistair Coles proposed openstack/swift-specs: Updates to encryption spec  https://review.openstack.org/15431817:34
*** SkyRocknRoll has quit IRC17:41
*** anayag has joined #openstack-swift17:42
*** silor1 has quit IRC17:44
anayagHi, I downloaded the latest swift code and deployed it in a cluster. It worked fine. Then I did some changes in these files [swift/common/wsgi.py swift/proxy/server.py swift/proxy/controllers/base.py swift/proxy/controllers/obj.py] after deploying those changes I get the same error mentioned in this link.17:45
anayaghttps://bugs.launchpad.net/keystone/+bug/139226417:45
openstackLaunchpad bug 1392264 in keystonemiddleware "Keystonemiddleware crashes when memcache encryption is enabled with Swift" [Low,Fix released] - Assigned to Rodrigo Duarte (rodrigodsousa)17:45
anayagcould anybody help me to resolve it?17:46
*** jordanP has quit IRC17:47
openstackgerritAlistair Coles proposed openstack/swift: Update guest VM OS recommendation in SAIO doc  https://review.openstack.org/15653917:47
openstackgerritDonagh McCabe proposed openstack/swift: Add multiple reseller prefixes and composite tokens  https://review.openstack.org/13708618:06
*** anayag has quit IRC18:07
*** aix has quit IRC18:07
*** CoffeeMarker has joined #openstack-swift18:14
acolescschwede: the swiftclient functional tests job is passing since the tox -e func change :)18:15
*** CrackerJackMack has quit IRC18:20
*** CrackerJackMack has joined #openstack-swift18:22
*** mmcardle has quit IRC18:27
*** EmilienM is now known as EmilienM|afk18:40
*** zhill has quit IRC18:40
*** acoles is now known as acoles_away18:48
*** khivin has quit IRC18:57
*** zhill has joined #openstack-swift19:03
*** dencaval has joined #openstack-swift19:04
*** bkopilov has quit IRC19:07
*** bkopilov has joined #openstack-swift19:11
*** delatte has quit IRC19:15
*** joeljwright has left #openstack-swift19:20
*** NM has joined #openstack-swift19:22
*** bkopilov has quit IRC19:25
*** nellysmitt has quit IRC19:26
*** tdasilva has quit IRC19:28
*** abhirc has quit IRC19:31
pconstantineglange: dunno, but I hope it gets into trunk faster than usually ;)19:37
*** tdasilva has joined #openstack-swift19:39
glangepconstantine: you want me to submit a patch and see what people say?19:48
glangeor do you want to do it?19:48
pconstantinego ahead, if you've already created it, I think although that writing test for it could be non-trivial19:49
glangeoh yeah, I forgot about that -- I'll see what I can do19:49
pconstantineglange: but if we will rely on the fact that finally is always, always called, then probably just testing that iterable.close() was called is enough19:50
*** erlon has quit IRC19:51
claygglange: !19:52
*** nellysmitt has joined #openstack-swift19:54
*** ofcourseistilllo has joined #openstack-swift20:00
glangeclayg: !20:02
glangeclayg: did you read through the above?  what do you think of what pconstantine is saying?20:02
pconstantinehmm, it looks like xprofile middleware also does not close the downstream iterators20:08
pconstantineI think that's all, all other "standard" middlewares are ok20:09
glangecool, thanks for looking20:10
claygglange: pconstantine: fwiw, I think the right place to close the app's iterable is when we catch GeneraterExit20:15
pconstantineclayg: you need to close it in both cases, and finally is called anyway after GeneratorExit20:15
claygah... yes, you're probably right20:16
pconstantineI think Graham Dumpleton blog post nails all peculiarities of calling close() quite well...20:17
*** bill_az has quit IRC20:18
glangeI wish Graham Dumpleton would fix this so we could get his name in the AUTHORS file, that is a good name20:19
*** abhirc has joined #openstack-swift20:25
*** vinsh has joined #openstack-swift20:25
*** mahatic has quit IRC20:30
claygi did read gd's article, and looked up the follow up slides where he talked about a way to do it better with context managers; maybe we could use a ProxiedIterable class -> https://gist.github.com/clayg/641503fa10a90c36845820:38
claygsomething in app.common.wsgi20:38
claygneat bug20:40
claygdoes anyone besides me think there's limited value in exposing the reseller prefixes -> https://review.openstack.org/#/c/137086/20:43
claygI can definately think of use-cases where you wouldn't want a specific reseller prefix exposed - like if you have some internal accounts or something, or there's a prefix that is for accounts you're I don't know.... *reselling*20:45
claygit *seems* like your catalog auth response would return whatever x-storage-url(s) you need - and if you want to go trying to put data somewhere else you're either authorized or not - no apriory knowledge is needed20:46
claygin fact, if you had a list of all the valid reseller prefixes - you might just keep trying all of them until you find one you can stuff data into20:46
claygwhich may or may not have been what was intended?20:46
claygidk, I guess any auth middleware can decide on it's own if it wants to expose that or not, but I'm worried if both tempauth and keystone to it some client will pick up on it and start expecting this to just be a thing that all swift clusters publish20:47
glangeyeah, it's kind of weird20:48
claygoh apparently it's "a priori" stupid latin - i'm such a horrible speller with english, i'm dommed when I start trying to sound smart20:48
claygheh... dommed20:48
* clayg walks away20:49
*** vinsh has quit IRC20:50
*** vinsh has joined #openstack-swift20:50
clayggerrit is fucking slow for me today - when i was at home I thought it was just my dsl, but I think someone smart is running our office network20:51
torgomaticclayg: utils.CloseableChain, perhaps?20:52
claygtorgomatic: if we get the name right I think the code is practially irrelevant20:53
*** gyee has joined #openstack-swift20:53
torgomaticclayg: what?20:53
claygs/whateverthefiwastyping/practically irrelevant/ - it was a sideways jab at "I don't care what it's called" :)20:54
klrmnclayg: do you want to have that talk before or after i push the next patch to the current review? =)20:59
claygpush away!21:00
*** nellysmitt has quit IRC21:01
torgomaticclayg: oh, I wasn't trying to suggest a name; we already have one of the thing you were talking about, and it's called utils.CloseableChain21:01
torgomaticline 256121:02
claygpahahhahaha!21:02
torgomatic:)21:02
claygahhhh man - and WSGIContext does all the rigt things automagically21:04
clayg... and proxy logging doesn't use it :'(21:05
clayghrmm.... I don't know it's not obvious to me how proxy_logging could use CloseableChain directly... the problem i suppose is that calling close on the returned iter_response doesn't call close on the iterable21:08
*** abhirc has quit IRC21:13
*** abhirc has joined #openstack-swift21:17
mattoliverauMorning21:19
jrichlimorning21:21
zaitcevclayg: are you tired of that lost fd by any chance? I do not understand Kota's follow-up 157290.21:31
*** morganfainberg is now known as needscoffee21:32
claygzaitcev: how do you mean?  he was looking at a test case i wrote that showed an unsynced object could be deleted.21:34
claygzaitcev: I'm reviewing it now21:34
claygacctually i had a few updates to the test I was going to stick in, and run it through some functional testing21:34
zaitcevI don't understand why it's bad to delete if delete_handoff is nonzero at ssync21:38
*** NM has quit IRC21:39
claygzaitcev: so delete_handoff is true when what... all jobs return success?  but on a poke job, you can successfully validate that not all objects are in sync - right?  So you can't delete the partition, you can only delete your candidate objs21:39
zaitcevwell, okay. I thought the idea here was that all the variables were correct no matter the sync method (by way of rsync returning empty delete candidates always). But now apparently we cannot decide to delete or not based on that information and have to refer to the replication type. Something is fishy.21:44
*** zhill has quit IRC21:44
claygoic, yeah I think a unittest for the rsync behavior is warranted21:49
*** lcurtis has quit IRC21:56
*** MasterPiece has quit IRC21:56
claygso with rsync all success always means it's safe to delete everything, with ssync, all successes mean you can delete any objects that are in sync on all nodes21:56
clayghrm.... I think there may be a bug when then delete_handoff option is set to < replica count... maybe... no i guess it's the same thing... unless you don't have any local primaries... myabe it's fine21:57
*** IRTermite has quit IRC22:02
*** openstackstatus has joined #openstack-swift22:15
*** ChanServ sets mode: +v openstackstatus22:15
openstackgerritLeah Klearman proposed openstack/swift: refactor kill_nonprimary_server  https://review.openstack.org/15721922:20
*** imkarrer has joined #openstack-swift22:28
imkarrerGood afternoon everyone!  I have an interesting problem.  I have encountered a situation where 'swift stat' lists containers which do not exist.  Has anyone encountered this before?  The containers show up in 'swift stat' but they cannot be deleted because they do not exist.22:31
claygimkarrer: run you container-updaters22:32
imkarrerclayg:  Thanks for the quick reply.  I will check that22:33
imkarrerclayg: shouldn't the account updater be running at a set intervals if the container-server is running?  I figure this problem should be self healing.22:43
claygthe account's don't update anything - that's the top of the chain - the container's update the accounts - via the container updater mostly - and yes, they will heal any descrepencies, unless the containers themselves are out of sync - maybe there's a container server out there with db's on disk that didn't get a new ring?22:45
*** zhill has joined #openstack-swift22:45
imkarrerclayg: I misspoke I meant to say container updater.  Thanks for the ideas on where to look.22:46
torgomaticand FWIW, the container updater and the container server are two different daemons. starting one does not imply starting the other.22:47
clayglook at torgomatic all questioning assumptions like a good sysadmin22:48
*** vinsh has quit IRC22:48
*** zhill has quit IRC22:50
imkarrertorgomatic: good point, I did make a foolish assumption.  I do remember now that they are started separately by swift-init.  Again, many thanks guys!22:50
clayghrmmm... you know it's interesting, the container-updater doesn't seem to look at the container ring - so if you removed a nodes devices from the ring (instead of weight 0 and let them drain) - it may send bogus updates forever?  I haven't functionally verified any of this - swift has surprised me before working when I didn't think it could :\22:51
imkarrerclayg: I created a container with the same name, and then I was able to delete it.  This is not a solution to my problem, but I thought I would mention the behavior in case is sheds any light on the problem.22:52
claygwell... wait a while see if it shows back up :P22:54
imkarrerclayg: It will be interesting to see, I will let ya know what I find out.22:55
*** nellysmitt has joined #openstack-swift23:02
*** jrichli has quit IRC23:03
*** wer_ has quit IRC23:04
*** abhirc has quit IRC23:04
*** CoffeeMarker has quit IRC23:05
*** wer_ has joined #openstack-swift23:05
*** nellysmitt has quit IRC23:07
*** Guest936 has joined #openstack-swift23:13
*** Guest936 is now known as annegentle23:13
*** lcurtis has joined #openstack-swift23:25
*** vinsh has joined #openstack-swift23:32
*** vinsh has quit IRC23:32
*** madhuri_ has joined #openstack-swift23:36
*** IRTermite has joined #openstack-swift23:44
*** zhill has joined #openstack-swift23:46
*** zhill has quit IRC23:51
*** abhirc has joined #openstack-swift23:56
*** vinsh has joined #openstack-swift23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!