Wednesday, 2014-12-03

*** dmsimard is now known as dmsimard_away00:10
*** acoles has quit IRC00:13
*** jwang_ has joined #openstack-swift00:14
*** acoles_away has joined #openstack-swift00:15
*** acoles_away is now known as acoles00:15
*** ChanServ sets mode: +v acoles00:15
*** dmorita has joined #openstack-swift00:25
*** tellesnobrega has quit IRC00:37
*** shri1 has joined #openstack-swift00:38
*** shri1 has quit IRC00:38
*** shri has quit IRC00:40
*** tellesnobrega has joined #openstack-swift00:44
*** tellesnobrega_ has quit IRC00:46
*** Masahiro has joined #openstack-swift00:46
*** Masahiro has quit IRC00:50
*** addnull has joined #openstack-swift01:00
*** Masahiro has joined #openstack-swift01:08
*** addnull has quit IRC01:31
*** nellysmitt has joined #openstack-swift01:32
*** nellysmitt has quit IRC01:36
openstackgerritKota Tsuyuzaki proposed openstack/swift: Efficient Replication for Distributed Regions  https://review.openstack.org/9982401:44
*** kota_ has joined #openstack-swift01:46
*** rmcall has quit IRC01:53
*** nosnos has joined #openstack-swift01:56
*** tellesnobrega_ has joined #openstack-swift02:04
*** addnull has joined #openstack-swift02:14
*** haomaiwang has joined #openstack-swift02:14
*** zackmdavis has left #openstack-swift02:14
*** Masahiro has quit IRC02:18
*** Masahiro has joined #openstack-swift02:21
*** jwang_ has quit IRC02:34
*** Masahiro has quit IRC02:52
*** Masahiro has joined #openstack-swift02:53
*** addnull has quit IRC02:55
*** Masahiro has quit IRC02:59
*** bill_az has quit IRC03:09
*** Masahiro has joined #openstack-swift03:22
*** madhuri has joined #openstack-swift03:28
madhuriHi, I am facing an issue while object PUT. I pressed control + C from the terminal which closes the connection between client and proxy. Proxy returned 49903:30
madhuriBut connection between proxy and object was still connected. And object service returned 408 after client_timeout of 60 seconds.03:31
madhuriI think the connection between the proxy and object must also get closed in above.03:31
madhuriI am using Icehouse stable release03:31
*** nellysmitt has joined #openstack-swift03:32
*** nellysmitt has quit IRC03:37
*** nosnos has quit IRC03:39
mattoliveraumadhuri: that's expected, when you put, the proxy opens a connection to the storage nodes and streams the data to them. When you cancelled the client connection (499), the storage server connections are still open but now stop receiving data, that is until they time out (408).03:47
madhuriBut we can explicitly close the connection.03:56
madhuriIn proxy/controller/obj.py in exception cases03:57
mattoliverauI don't think a control + c does a friendly close03:57
*** addnull has joined #openstack-swift03:59
madhuriYes. I agree03:59
madhuriBut my concern is we can close it like this04:00
madhuriconn.close()04:00
madhurihttp://paste.openstack.org/show/143905/04:01
madhurimattoliverau: Can you suggest would it be acceptable to do this change04:01
madhuri?04:01
mattoliveraumadhuri: where are you putting this code? When you return the HTTPClientDisconnect, the client will get its response so close the wsgi connection.04:04
madhurihttp://paste.openstack.org/show/143911/04:05
madhuriPlease find the diff above04:06
madhurimattoliverau: Can I ping you after half an hour> Got to go.04:09
mattoliveraumadhuri: of course, I'll be around :)04:10
madhuriThanks mattoliverau :)04:10
*** nosnos has joined #openstack-swift04:19
*** abhirc_ has joined #openstack-swift04:24
*** abhirc has quit IRC04:27
*** addnull has quit IRC04:28
*** bill_az has joined #openstack-swift04:34
madhurimattoliverau: Hi05:03
mattoliveraumadhuri: welcome back :)05:04
madhuriThank you05:04
madhuriHave a look on the patch05:05
*** kopparam has joined #openstack-swift05:06
mattoliveraumadhuri: I've looked at the patch, but let me refamilarise myself if the code in question :)05:07
madhuriok05:09
*** ppai has joined #openstack-swift05:10
*** alexiz has quit IRC05:15
*** sungju has quit IRC05:17
*** kopparam has quit IRC05:20
*** kopparam has joined #openstack-swift05:21
*** addnull has joined #openstack-swift05:24
mattoliveraumadhuri: is the 408 and the 499 occuring at the same time? Or does the 408 happen 60 seconds after the other? Just making checking to see if the exception catching of the client disconnect is cleaning up (closing the connection) in which case nothing has to be done.. I might have to test it myself. But one thing you;ll have a problem with is that the conn object doesn't exist.05:27
madhuri408 from object service is raised after 60 seconds after proxy returned 49905:28
*** dvorkbjel has quit IRC05:28
*** tellesnobrega_ has quit IRC05:28
madhuriI have checked closing connection explicitly and it worked.05:28
madhuriBut not in one case.05:29
*** zaitcev has quit IRC05:30
madhuriThat is once object service has started reading the chunks, even after closing the connection explicitly(the 3rd conn.close in the patch). The object returned 408 after 60 second.05:30
*** dvorkbjel has joined #openstack-swift05:31
madhuriThat is when the object server failed to read the next chunk in 60 seconds.05:31
*** SkyRocknRoll has joined #openstack-swift05:31
*** SkyRocknRoll has joined #openstack-swift05:31
madhuriHow is object service able to read from a closed connection? Does conn.close() not closing the socket?05:32
*** nellysmitt has joined #openstack-swift05:33
*** abhirc_ has quit IRC05:34
mattoliverauWell looking at the icehouse code.. unless I'm missing something, which I could be, there isn't a conn object, there is a list of connections called conns05:35
madhuriYes, you are right.05:36
madhuriBut each conn object is iterated from conns list to send file to each storage server05:36
*** nellysmitt has quit IRC05:38
mattoliverauwhich is being run in the background via a greenlet pool, the and peices of data are being placed in the conn objects queue to be pushed. So your dealing with x conn objects at once.05:39
mattoliverausorry a contextpool05:39
madhuriYes mattoliverau :)05:39
mattoliveraumadhuri: so you'd need to loop through all the conn objects in conns and call close, if you wanted to be sure to close them all.05:40
madhuriYes. But the one for which exception has raised05:42
mattoliveraumadhuri: the exception is being raised on the client connection isn't it? not on the conns05:43
madhuriYes05:44
madhuriYou are right.05:44
madhuriAnd for the client connections, if any exception raised so we need to close the object service connection also.05:44
mattoliverauWhen the ContectPool leaves the 'with' scope each coroutine is killed.. I wonder why this isn't closing the connections.05:45
mattoliverau*contextpool05:45
mattoliveraumadhuri: and the object server connections are inside the conns object.05:46
mattoliverausorry conns list (I'm still a little jetlagged :P)05:46
madhuriYes05:46
mattoliverauFirstly, I'm wondering why the connection aren't automatically closed when the pool object (contextpool) object isn't garbage collected, seeing as there is an __exit__ method defined which should kill all the coroutines (conns) running inside it.05:49
mattoliverau*is garbage collected05:50
mattoliverauwow, I fail at making sentenses today05:50
*** rmcall has joined #openstack-swift05:52
*** rmcall has quit IRC05:52
*** Masahiro has quit IRC05:52
madhuriYes. I am also wondering. The connections were alive :(05:52
*** Masahiro has joined #openstack-swift05:53
*** rmcall has joined #openstack-swift05:54
*** rmcall_ has joined #openstack-swift05:59
*** kopparam has quit IRC06:00
*** rmcall has quit IRC06:02
madhurimattoliverau: Let me know if you get the answer. I am looking into it.06:03
mattoliveraumadhuri: I wonder if this will work. In _send_file (the function being run in contextpool) if we get it to close the connection on cleanup, something like:06:03
mattoliverauwith contextlib.closing(conn):06:04
*** rmcall_ has quit IRC06:04
mattoliverau   <do the rest>06:04
mattoliverauSo when it is killed (garbage collected) the connection is also closed at garbage collection.06:04
*** rmcall has joined #openstack-swift06:04
mattoliverauI don't know if that would work, but might be cleaner06:04
mattoliverauAs it means it will clean itself up06:05
mattoliverau* with contextlib.closing(conn) as conn:06:05
*** kota_ has quit IRC06:07
*** kopparam has joined #openstack-swift06:08
*** addnull has quit IRC06:08
*** Masahiro has quit IRC06:09
*** Masahiro has joined #openstack-swift06:10
*** kopparam has quit IRC06:11
*** kopparam has joined #openstack-swift06:11
*** k4n0 has joined #openstack-swift06:20
madhuriYes. Even after closing the connection explicitly, the connection object is not destroyed because of cyclic reference from _send_file for an example06:23
madhuriwith contextlib.closing(conn) as conn should work06:24
*** wer has quit IRC06:28
*** wer has joined #openstack-swift06:28
mattoliveraumadhuri:  http://paste.openstack.org/show/143922/06:33
mattoliverauin quick testing that works.. though I did that in master rather then icehouse.06:33
mattoliverauwell looks like it works.. I didn't really test too hard.06:34
madhuriThanks mattoliverau. I am also testing it06:35
openstackgerritDaisuke Morita proposed openstack/swift: Output logs of policy index  https://review.openstack.org/13699506:35
*** gyee_ has quit IRC06:36
mattoliveraumadhuri: cools, well happy hacking :) I'm calling it a day.06:37
mattoliveraunight swift land.06:38
madhuriThanks mattoliverau :)06:38
*** nosnos has quit IRC06:38
*** nosnos has joined #openstack-swift06:40
*** wer has quit IRC06:41
*** wer has joined #openstack-swift06:43
*** sandywalsh_ has joined #openstack-swift06:46
*** addnull has joined #openstack-swift06:47
*** sandywalsh has quit IRC06:47
*** SkyRocknRoll has quit IRC06:52
*** SkyRocknRoll has joined #openstack-swift06:53
*** nshaikh has joined #openstack-swift06:56
*** kopparam has quit IRC06:56
*** kopparam has joined #openstack-swift06:57
*** rmcall_ has joined #openstack-swift07:05
*** rmcall has quit IRC07:08
*** rmcall_ is now known as rmcall07:08
*** rmcall has quit IRC07:19
*** bill_az has quit IRC07:20
*** Masahiro has quit IRC07:27
*** Masahiro has joined #openstack-swift07:31
*** nellysmitt has joined #openstack-swift07:34
*** nellysmitt has quit IRC07:39
*** openstackgerrit has quit IRC07:50
*** openstackgerrit has joined #openstack-swift07:50
*** Masahiro has quit IRC07:59
*** Masahiro has joined #openstack-swift08:02
*** rledisez has joined #openstack-swift08:09
*** geaaru has joined #openstack-swift08:45
*** ahonda has joined #openstack-swift08:48
*** jordanP has joined #openstack-swift08:53
*** sgowda has joined #openstack-swift09:03
*** nellysmitt has joined #openstack-swift09:23
*** kopparam has quit IRC09:35
*** jordanP has quit IRC09:39
*** addnull has quit IRC09:44
*** jordanP has joined #openstack-swift09:53
*** jordanP has quit IRC09:59
*** tellesnobrega_ has joined #openstack-swift10:18
*** Masahiro has quit IRC10:29
*** kopparam has joined #openstack-swift10:30
*** jistr has joined #openstack-swift10:37
*** jistr is now known as jistr|trng10:38
*** erlon has quit IRC10:43
*** erlon has joined #openstack-swift10:48
*** addnull has joined #openstack-swift10:55
*** haomaiwang has quit IRC10:57
*** addnull has quit IRC10:59
*** tellesnobrega_ has quit IRC11:02
openstackgerritMerged openstack/swift: Removing unused method: _remaining_items  https://review.openstack.org/13855911:14
*** aix has joined #openstack-swift11:22
*** k4n0 has quit IRC11:23
*** sgowda has quit IRC11:28
*** Masahiro has joined #openstack-swift11:30
*** nshaikh has quit IRC11:31
*** mahatic has joined #openstack-swift11:34
*** Masahiro has quit IRC11:34
*** CaioBrentano has joined #openstack-swift12:03
*** kopparam has quit IRC12:06
*** kopparam has joined #openstack-swift12:09
*** addnull has joined #openstack-swift12:23
openstackgerritDaisuke Morita proposed openstack/swift: Show each policy's information on audited results in recon  https://review.openstack.org/13869712:25
*** kopparam has quit IRC12:27
*** addnull has quit IRC12:28
*** jistr|trng has quit IRC12:28
*** dmorita has quit IRC12:31
*** lpabon has joined #openstack-swift12:33
*** dmsimard_away is now known as dmsimard12:34
*** jistr has joined #openstack-swift12:34
*** jistr is now known as jistr|trng12:35
*** aix has quit IRC12:38
CaioBrentanohi guys13:06
CaioBrentanodoes anyone can help me with some issue with swiftclient cli >13:06
CaioBrentano?13:06
CaioBrentanoI have a non-admin user that have write permission on a specific container… When I try to create an object in this container, the swift client is returning "Account not found"13:07
*** Masahiro has joined #openstack-swift13:08
CaioBrentanoThis happens on v2.3.1… On v2.2.0, swficlient returns a error about trying to create container, but creates the object successfully13:11
*** exploreshaifali has joined #openstack-swift13:12
*** kopparam has joined #openstack-swift13:12
*** Masahiro has quit IRC13:13
*** ppai has quit IRC13:13
*** ppai has joined #openstack-swift13:15
*** nellysmitt has quit IRC13:17
*** aix has joined #openstack-swift13:19
*** kopparam has quit IRC13:33
*** kopparam has joined #openstack-swift13:36
*** oomichi has quit IRC13:40
*** X019 has joined #openstack-swift13:42
*** rdaly2 has joined #openstack-swift13:46
*** nellysmitt has joined #openstack-swift13:49
acolesCaioBrentano: sounds like a known bug https://bugs.launchpad.net/python-swiftclient/+bug/137165013:54
acolesCaioBrentano: I have a fix up for review https://review.openstack.org/#/c/125759/13:54
*** ppai has quit IRC13:56
CaioBrentanothanks acoles!13:56
CaioBrentanoI'll check your review13:57
acolesCaioBrentano: btw the error re trying to create a container can be ignored - swift cli attempts to create the container before putting the object which will fail if the user does not have permission to create a container, but the cli should then proceed to attempt the object PUT13:57
acolesCaioBrentano: ^^ on 2.2.0 that is13:57
*** exploreshaifali has quit IRC13:57
*** rdaly2 has quit IRC13:58
CaioBrentanoacoles: exactly… on 2.2.013:58
CaioBrentanoacoles: anyway, the return status is error on "$?"… so my buid process breaks13:59
*** tdasilva has joined #openstack-swift13:59
CaioBrentanoacoles: that's why I can't simply ignore this on v2.2.013:59
acolesCaioBrentano: yeah, i think my patch fixes that too, it really should not cause a 1 exit status unless the object PUT fails :(14:00
CaioBrentanoacoles: great!14:02
*** jordanP has joined #openstack-swift14:04
*** tdasilva has quit IRC14:15
*** annegent_ has joined #openstack-swift14:19
*** X019 has quit IRC14:20
*** kopparam has quit IRC14:27
*** nosnos has quit IRC14:28
*** tdasilva has joined #openstack-swift14:30
*** bill_az has joined #openstack-swift14:32
*** kopparam has joined #openstack-swift14:44
*** annegent_ has quit IRC14:54
*** silor has joined #openstack-swift14:54
*** Masahiro has joined #openstack-swift14:57
*** CaioBrentano has quit IRC15:00
*** Masahiro has quit IRC15:02
*** tdasilva has quit IRC15:04
*** tellesnobrega_ has joined #openstack-swift15:12
*** tdasilva has joined #openstack-swift15:17
*** madhuri has quit IRC15:23
*** kopparam has quit IRC15:34
*** kopparam has joined #openstack-swift15:39
*** kopparam has quit IRC15:51
*** rmcall has joined #openstack-swift15:53
*** CaioBrentano has joined #openstack-swift16:00
*** SkyRocknRoll has quit IRC16:03
openstackgerritDonagh McCabe proposed openstack/swift-specs: Minor updates to composite token spec  https://review.openstack.org/13877116:03
notmynamegood morning16:04
*** zaitcev has joined #openstack-swift16:05
*** ChanServ sets mode: +v zaitcev16:05
notmynamereminder that we do not have a team meeting today16:13
zaitcevok16:13
tdasilvanotmyname: ok, thanks for the heads up16:14
notmynamewe need to talk about the next release, though16:16
notmynamereleasing 2.2.1 with the various bug fixes we've merged since 2.2.016:17
notmynameI added a 2.2.1 section to https://wiki.openstack.org/wiki/Swift/PriorityReviews16:17
notmynameand generally targeting the week of the 15th for a release16:18
notmynamethat's actually about all the detail I have right now. I think it should be a pretty minor event. good stuff has landed. let's make it available. no big coordination effort needed for this one16:19
openstackgerritDonagh McCabe proposed openstack/swift: Add multiple reseller prefixes and composite tokens  https://review.openstack.org/13708616:19
notmynameif someone thinks any of that is a terrible idea, let me know :-)16:19
* notmyname hopes mattoliverau saw my note in channel yesterday about no meeting16:20
acolesnotmyname: ack16:26
notmynameI've got to drive to a meeting soon. I'll be online later today16:27
*** tellesnobrega_ has quit IRC16:28
*** rdaly2 has joined #openstack-swift16:28
*** Nadeem has joined #openstack-swift16:28
*** echevemaster has joined #openstack-swift16:29
*** Nadeem has quit IRC16:29
tdasilvanotmyname: ok, planning to go through the priority reviews today and see where i can help16:30
*** annegent_ has joined #openstack-swift16:43
*** Masahiro has joined #openstack-swift16:46
*** Masahiro has quit IRC16:50
*** annegent_ has quit IRC16:55
bsdkurtI'm running a small cluster and one object-server is acting up. I'm frequently getting  ChunkWriteTimeout (60s) on the proxy and http 408's after 60 seconds on the one storage node.17:00
bsdkurtDoes anyone have pointers for me to figure out what's going wrong?17:00
bsdkurtoh, I'm running 2.2.017:00
*** jistr|trng has quit IRC17:11
*** gyee_ has joined #openstack-swift17:12
*** annegent_ has joined #openstack-swift17:15
*** zackmdavis has joined #openstack-swift17:25
*** atan8 has joined #openstack-swift17:26
*** rledisez has quit IRC17:28
*** rmcall has quit IRC17:39
claygacoles: yeah I think now that capture output merged i was supposed to rebase something...17:44
*** rmcall has joined #openstack-swift17:44
acolesclayg: say more ?17:45
*** nshaikh has joined #openstack-swift17:46
*** aix has quit IRC17:48
claygyou had linked earlier the os-storage-url branch, which I think was maybe back on the review ticket with capture output merged17:50
claygi know i had some other outstanding swift client change (something about auth retries?) that needed to be rebased17:50
acolesclayg: ah, right, with you now :) yeah that was dependent on capture output. idk if i need to rebase or if its good still17:52
gyee_question for Swift team, once the account is marked as deleted and before the reaper takes it, can it be reversed?17:53
acolesclayg: btw i asked dan to look at applying capture output uniformly across the client tests (if its not already)17:53
*** annegent_ has quit IRC17:56
claygacoles: that's cool17:58
claygacoles: how'd you manage to cram enough bits into your Timewrap that you're not gunna loose info?17:58
*** gvernik has joined #openstack-swift17:59
claygit looked like you were doing a bit mask of the least significant bits - but i feel like that would fall apart if you had some updates that were 100's of hours apart17:59
acolesclayg: at the moment i'm only packing 2.5 timestamps in there: the original data time, the content-type time, and two digits for reconciler bumping the time18:00
acolesclayg: mask two rightmost digits, then shift content-type time into upper 14 digits18:01
claygacoles: so two posts based on the same content-type at 0x1ff and 0x0ff look like the same timestamp to the container?  now row_id bump?18:02
*** jwang_ has joined #openstack-swift18:02
*** simonj has joined #openstack-swift18:02
bsdkurtThere were no clues as to why that object server was behaving badly for me; nothing in syslog. rebooting the server seems to have cleared the problem. very strange.18:04
*** tkay has joined #openstack-swift18:05
*** tkay has left #openstack-swift18:05
claygbsdkurt: can you see if the timeouts were hitting the same disk?  were you running with threads per disk option or port per disk setup?18:05
*** rmcall has quit IRC18:06
claygdo you have smartmontools installed on the node, can you run a quick -i on all the devices?18:06
bsdkurtclayg: it was different disks. I'm running with 8 threads per disk18:06
bsdkurtah good idea, will do18:06
*** silor has quit IRC18:07
claygbsdkurt: how many disks/workers with those 8 threads per disk?18:07
*** rmcall has joined #openstack-swift18:07
bsdkurtclayg: 16 workers (node has 16 cpus), 5 disks18:08
claygk, so 8 threads * 5 disks * 16 workers is 640 threads - seems fine18:09
*** rmcall_ has joined #openstack-swift18:11
*** rmcall has quit IRC18:12
*** rmcall_ is now known as rmcall18:12
claygtorgomatic: bsdkurt got some chunkwritetimeouts with threads per disk ^ ???18:12
*** nellysmitt has quit IRC18:13
claygtorgomatic: i'm trying to imagine something that could get screwed up besides just the obvious (fsyncs blocking like a boss)18:13
*** jordanP has quit IRC18:13
claygtorgomatic: I guess if we don't have a timeout on those you could get some hung fysncs eating up your disk threads, and then nothing gets done?18:14
claygtorgomatic: or maybe memory presure somehow casing a write to block trying to get space free'd in the page cache to accept the buffer?18:14
bsdkurtclayg: bbl, lunch is here. thanks for looking into it. I'll be back in 30min.18:15
clayglater18:15
*** atan8 has quit IRC18:20
*** silor has joined #openstack-swift18:23
*** exploreshaifali has joined #openstack-swift18:26
*** aix has joined #openstack-swift18:33
*** simonj has quit IRC18:34
bsdkurtclayg: hmm, the problem happened again. this time on a different storage server. same hardware setup: 5 disks, 16 workers, 8 threads per disk18:34
*** Masahiro has joined #openstack-swift18:35
*** cutforth has joined #openstack-swift18:36
bsdkurtbtw, the http 408 makes its way out to the caller. if two of the three copies succeed, shouldn't it return success out?18:38
*** nellysmitt has joined #openstack-swift18:39
*** Masahiro has quit IRC18:40
*** annegent_ has joined #openstack-swift18:40
*** annegent_ has quit IRC18:48
bsdkurtthe object-server was cruising along and then the problem tripped and about 9 out of 10 PUTs fail with 408 for several minutes.18:56
*** annegent_ has joined #openstack-swift18:57
bsdkurtif I stop adding data to the cluster for a while and start up again. seems like all is well for a few minutes then it trips again on the same server although it looks like my success rate is higher about 50/5018:58
*** acoles is now known as acoles_away18:58
peluseclayg, I have a proto of what we talked about last wrt the reconstructor kinda working.  There are of course a few options before continuing, would you have any time today to chat?18:58
*** geaaru has quit IRC18:59
claygheh19:01
claygi just got off the skype with acoles :P19:01
bsdkurtcpu use looks ok (~80%) idle, memory doesn't look too bad: 5.5gig in cached mem, no swaping, but the rest in use 16 gig total19:01
claygpeluse: i was about to head into the office, you wanna do it after lunch PST?19:01
pelusesure, ping me when ready.  will see if I can get my skype working by then :)(19:02
claygpeluse: nice19:04
claygbsdkurt: can you turn the object server log level to debug and maybe even eventlet_debug = true?19:04
claygbsdkurt: also check your messages/syslog for network or disk related stuff - "con" "write" "blk" "err" "fail" "drop" anything like that...19:05
claygbsdkurt: it's weird that it moved servers, makes it much less likly to be disk related in mind... but maybe if your requests per disk is overwhelming the threads * worker per disk things could get starved and manifest as timeouts - are you sending lots of requests or lots of bytes?19:06
claygpeluse: k, i'll ping ya - later19:07
bsdkurtyea. the smartmon short test was good on the first server.. the syslog does have something in it... just a sec19:07
bsdkurtlooks like kernel is complaining about memory allocation failures19:09
*** cutforth has quit IRC19:10
bsdkurtstack traces look like networking buffers are an issue19:10
bsdkurtall the kernel allocation errors are in the network stack. I have 10gig nics in these servers.19:13
*** cloudnull has left #openstack-swift19:15
*** gvernik has quit IRC19:15
bsdkurtahh yea, the first server also has these. I miss them when I looked (log rotation)19:15
bsdkurtI'm running ubuntu 14.04.1.19:16
bsdkurtgoogle tells me that increasing vm.min_free_kbytes may fix this. I'll give it go and see19:27
bsdkurtclayg: thanks for the help. sorry I missed those kernel messages when I first looked. It seems that after the messages appear, the server is hosed until a reboot and the messages don't reoccur.19:34
*** mahatic has quit IRC19:38
*** imkarrer has quit IRC19:50
*** aix has quit IRC19:51
openstackgerritCaleb Tennis proposed openstack/swift: Catch OSError in replicator if directory is gone.  https://review.openstack.org/13883719:51
*** aix has joined #openstack-swift20:05
*** nellysmitt has quit IRC20:07
*** nshaikh has left #openstack-swift20:09
*** annegent_ has quit IRC20:09
*** annegent_ has joined #openstack-swift20:13
*** Masahiro has joined #openstack-swift20:23
*** nellysmitt has joined #openstack-swift20:26
*** nellysmitt has quit IRC20:28
*** Masahiro has quit IRC20:28
*** annegent_ has quit IRC20:32
*** CaioBrentano has quit IRC20:40
*** CaioBrentano has joined #openstack-swift20:43
*** CaioBrentano has quit IRC20:57
*** silor has quit IRC20:59
*** silor1 has joined #openstack-swift20:59
mattoliverauMorning all21:01
mattoliveraunotmyname  thanks for the meeting reminder but lucky I tend to read channel scroll back so I heard about no meeting yest ;) the swift meeting agenda also had the date for next week which was a give away!21:01
*** silor1 has quit IRC21:15
*** exploreshaifali has quit IRC21:23
*** lpabon has quit IRC21:24
*** dmsimard is now known as dmsimard_away21:32
claygpoor mattoliverau :\21:39
openstackgerritOpenStack Proposal Bot proposed openstack/python-swiftclient: Updated from global requirements  https://review.openstack.org/8925021:41
openstackgerritOpenStack Proposal Bot proposed openstack/swift: Updated from global requirements  https://review.openstack.org/8873621:42
peluseclayg, say "when"21:45
clayg15 mins i'll say when21:45
pelusethat works... I assume you got the movie quote right?  https://www.youtube.com/watch?v=3G2_KZ7_hxc21:48
mattoliverauclayg: yeah it's hard being me :P Everyone take pity!21:52
claygpeluse: when i 'spose22:01
claygpeluse: hrmm... i don't have headphones handy...22:02
peluseOK, tried skype - what's a better way?22:02
*** tellesnobrega_ has joined #openstack-swift22:05
mattoliveraupeluse: you guys could try google hangouts, seeing as you don't have to worry about a client.22:11
*** Masahiro has joined #openstack-swift22:12
notmynameback online. hello world22:15
*** Masahiro has quit IRC22:17
mattoliveraunotmyname: yo22:17
notmynameyo22:18
*** nellysmitt has joined #openstack-swift22:28
openstackgerritpaul luse proposed openstack/swift: Reconstructor helpers for handoff revert case (and other misc)  https://review.openstack.org/13187222:30
*** nellysmitt has quit IRC22:33
*** jwang_ has quit IRC22:40
*** jwang_ has joined #openstack-swift23:02
*** sungju has joined #openstack-swift23:30
*** tdasilva has quit IRC23:38
*** dmsimard_away is now known as dmsimard23:51
*** jwang__ has joined #openstack-swift23:55
*** jwang_ has quit IRC23:59

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