*** annegentle has joined #openstack-swift | 00:10 | |
*** dmorita has joined #openstack-swift | 00:24 | |
*** tsg has quit IRC | 00:28 | |
*** tgohad has quit IRC | 00:29 | |
*** tgohad has joined #openstack-swift | 00:30 | |
*** tsg has joined #openstack-swift | 00:30 | |
*** annegentle has quit IRC | 00:31 | |
*** mitz has joined #openstack-swift | 00:37 | |
*** nosnos has joined #openstack-swift | 00:45 | |
*** annegentle has joined #openstack-swift | 00:50 | |
*** annegentle has quit IRC | 00:54 | |
*** nosnos has quit IRC | 00:58 | |
*** nosnos has joined #openstack-swift | 01:01 | |
*** mitz has quit IRC | 01:01 | |
*** annegentle has joined #openstack-swift | 01:02 | |
*** mitz has joined #openstack-swift | 01:03 | |
*** annegentle has quit IRC | 01:09 | |
*** addnull has joined #openstack-swift | 01:13 | |
*** mitz has quit IRC | 01:13 | |
*** mitz has joined #openstack-swift | 01:16 | |
*** nosnos has quit IRC | 01:19 | |
*** nosnos has joined #openstack-swift | 01:22 | |
*** nosnos has quit IRC | 01:24 | |
*** elambert has quit IRC | 01:27 | |
*** evanjfraser has joined #openstack-swift | 01:33 | |
*** Edward-Zhang has joined #openstack-swift | 01:39 | |
*** nosnos has joined #openstack-swift | 01:51 | |
*** haomaiwang has joined #openstack-swift | 01:56 | |
*** nosnos has quit IRC | 01:58 | |
*** nosnos has joined #openstack-swift | 01:58 | |
*** annegentle has joined #openstack-swift | 02:10 | |
*** haomaiw__ has joined #openstack-swift | 02:12 | |
*** haomaiwang has quit IRC | 02:13 | |
*** annegentle has quit IRC | 02:15 | |
*** annegentle has joined #openstack-swift | 02:18 | |
*** tgohad has quit IRC | 02:33 | |
*** tsg has quit IRC | 02:33 | |
*** elambert has joined #openstack-swift | 03:05 | |
*** elambert has quit IRC | 03:06 | |
*** annegentle has quit IRC | 03:14 | |
*** mrsnivvel has joined #openstack-swift | 03:23 | |
*** jasondotstar has quit IRC | 03:26 | |
*** elambert has joined #openstack-swift | 03:30 | |
*** ppai has joined #openstack-swift | 03:40 | |
*** Edward-Zhang has quit IRC | 03:43 | |
*** atan8 has joined #openstack-swift | 03:45 | |
*** tsg has joined #openstack-swift | 03:59 | |
*** tgohad has joined #openstack-swift | 03:59 | |
*** atan8_ has joined #openstack-swift | 04:00 | |
*** atan8 has quit IRC | 04:00 | |
openstackgerrit | paul luse proposed a change to openstack/swift-specs: Updates to EC Design Spec https://review.openstack.org/116486 | 04:02 |
---|---|---|
*** Edward-Zhang has joined #openstack-swift | 04:16 | |
*** atan8_ has quit IRC | 04:25 | |
*** nosnos has quit IRC | 04:32 | |
*** nosnos has joined #openstack-swift | 04:33 | |
*** kopparam has joined #openstack-swift | 04:57 | |
*** tgohad has quit IRC | 05:05 | |
*** tsg has quit IRC | 05:05 | |
*** kopparam has quit IRC | 05:17 | |
*** kopparam has joined #openstack-swift | 05:17 | |
*** kopparam has quit IRC | 05:22 | |
*** kopparam has joined #openstack-swift | 05:27 | |
*** addnull has quit IRC | 05:41 | |
*** addnull has joined #openstack-swift | 05:41 | |
*** addnull has quit IRC | 05:43 | |
*** addnull has joined #openstack-swift | 05:44 | |
*** addnull_ has joined #openstack-swift | 05:46 | |
*** addnull has quit IRC | 05:47 | |
*** addnull_ has quit IRC | 05:47 | |
*** addnull has joined #openstack-swift | 05:48 | |
*** addnull has joined #openstack-swift | 05:50 | |
*** miqui has quit IRC | 06:00 | |
*** nshaikh has joined #openstack-swift | 06:02 | |
*** k4n0 has joined #openstack-swift | 06:05 | |
*** haomaiw__ has quit IRC | 06:08 | |
*** haomaiwa_ has joined #openstack-swift | 06:08 | |
*** haomaiw__ has joined #openstack-swift | 06:17 | |
*** haomaiwa_ has quit IRC | 06:21 | |
*** joeljwright has joined #openstack-swift | 06:57 | |
ByteSore | does someone know how to fix this? swift: ERROR Insufficient Storage 192.168.0.102:6002/accounts? i get it when i run swift list | 06:57 |
*** dvas has joined #openstack-swift | 07:00 | |
*** sungju has quit IRC | 07:06 | |
*** kopparam has quit IRC | 07:07 | |
*** kopparam has joined #openstack-swift | 07:08 | |
*** kopparam has quit IRC | 07:12 | |
*** dvas has quit IRC | 07:19 | |
*** dvas has joined #openstack-swift | 07:19 | |
*** bkopilov has joined #openstack-swift | 07:20 | |
*** dvas_ has joined #openstack-swift | 07:22 | |
*** dvas has quit IRC | 07:24 | |
*** jokke__ is now known as jokke_ | 07:31 | |
*** Midnightmyth has joined #openstack-swift | 07:34 | |
*** bvandenh has joined #openstack-swift | 07:35 | |
*** kopparam has joined #openstack-swift | 07:58 | |
ByteSore | nvm, found it. mount_check = false fixed it | 08:05 |
*** geaaru has joined #openstack-swift | 08:17 | |
*** dvas_ has quit IRC | 08:25 | |
*** dvas_ has joined #openstack-swift | 08:37 | |
*** k4n0 has quit IRC | 08:39 | |
*** kopparam has quit IRC | 08:41 | |
*** nshaikh has quit IRC | 08:43 | |
*** k4n0 has joined #openstack-swift | 08:53 | |
*** mkollaro has joined #openstack-swift | 09:05 | |
*** mkollaro has quit IRC | 09:09 | |
*** mkollaro1 has joined #openstack-swift | 09:09 | |
*** kopparam has joined #openstack-swift | 09:20 | |
*** Edward-Zhang has quit IRC | 09:25 | |
*** kopparam_ has joined #openstack-swift | 09:41 | |
*** dvorkbjel has quit IRC | 09:42 | |
*** kopparam has quit IRC | 09:44 | |
*** koppara__ has joined #openstack-swift | 09:44 | |
*** dvorkbjel has joined #openstack-swift | 09:45 | |
*** koppar___ has joined #openstack-swift | 09:46 | |
*** kopparam_ has quit IRC | 09:47 | |
*** koppara__ has quit IRC | 09:49 | |
*** dvas_ has quit IRC | 09:49 | |
*** dvas_ has joined #openstack-swift | 09:49 | |
*** ppai has quit IRC | 09:50 | |
*** dvas_ has quit IRC | 09:54 | |
*** dvas_ has joined #openstack-swift | 09:54 | |
*** ppai has joined #openstack-swift | 10:06 | |
*** koppar___ has quit IRC | 10:10 | |
*** kopparam has joined #openstack-swift | 10:17 | |
*** addnull has quit IRC | 10:44 | |
*** nshaikh has joined #openstack-swift | 10:46 | |
*** k4n0 has quit IRC | 10:47 | |
*** addnull has joined #openstack-swift | 10:47 | |
*** bkopilov has quit IRC | 10:48 | |
*** bkopilov has joined #openstack-swift | 10:49 | |
*** dmorita has quit IRC | 10:55 | |
*** k4n0 has joined #openstack-swift | 10:59 | |
*** tdasilva has quit IRC | 11:03 | |
*** tdasilva has joined #openstack-swift | 11:05 | |
*** addnull has quit IRC | 11:10 | |
*** dvas_ has quit IRC | 11:20 | |
*** dvas_ has joined #openstack-swift | 11:21 | |
*** mkollaro has joined #openstack-swift | 11:22 | |
*** mkollaro1 has quit IRC | 11:24 | |
*** dvas_ has quit IRC | 11:25 | |
*** ppai has quit IRC | 11:39 | |
*** tdasilva has quit IRC | 11:43 | |
*** ppai has joined #openstack-swift | 11:51 | |
*** mkollaro has quit IRC | 12:14 | |
*** mkollaro1 has joined #openstack-swift | 12:14 | |
*** bvandenh has quit IRC | 12:18 | |
*** bvandenh has joined #openstack-swift | 12:19 | |
*** kopparam has quit IRC | 12:24 | |
*** thomaschaaf has joined #openstack-swift | 12:30 | |
thomaschaaf | hello i just upgraded from 1.13 to 2.0 and read acl seem to have been reset | 12:31 |
thomaschaaf | why could this be? | 12:31 |
*** jasondotstar has joined #openstack-swift | 12:34 | |
thomaschaaf | hmm restarted swift services and now they are back | 12:36 |
thomaschaaf | weird.. | 12:36 |
*** dvas_ has joined #openstack-swift | 12:47 | |
*** kopparam has joined #openstack-swift | 12:55 | |
*** ppai has quit IRC | 12:56 | |
thomaschaaf | do i actively have to enable xprofile? | 12:59 |
*** miqui has joined #openstack-swift | 13:08 | |
*** dvas_ has quit IRC | 13:13 | |
*** dvas_ has joined #openstack-swift | 13:14 | |
*** dvas__ has joined #openstack-swift | 13:17 | |
*** dvas_ has quit IRC | 13:18 | |
*** chandankumar has joined #openstack-swift | 13:20 | |
*** dvas___ has joined #openstack-swift | 13:20 | |
*** dvas__ has quit IRC | 13:21 | |
*** tdasilva has joined #openstack-swift | 13:23 | |
*** mikehn_ is now known as mikehn | 13:24 | |
*** k4n0 has quit IRC | 13:35 | |
*** nosnos has quit IRC | 13:38 | |
*** nosnos has joined #openstack-swift | 13:38 | |
*** nosnos has quit IRC | 13:43 | |
*** chandankumar has quit IRC | 13:46 | |
*** bkopilov has quit IRC | 13:48 | |
openstackgerrit | Xiang Hui proposed a change to openstack/swift: Fix getaddrinfo if dnspython is installed. https://review.openstack.org/116618 | 13:51 |
openstackgerrit | Xiang Hui proposed a change to openstack/swift: Fix getaddrinfo if dnspython is installed. https://review.openstack.org/116618 | 13:54 |
*** kopparam has quit IRC | 13:57 | |
*** kopparam has joined #openstack-swift | 13:58 | |
*** dmsimard_away is now known as dmsimard | 14:03 | |
*** atan8 has joined #openstack-swift | 14:14 | |
*** __lgw4__ has joined #openstack-swift | 14:23 | |
notmyname | good morning world | 14:25 |
notmyname | 2.1.0.rc1 has been tagged. final release planned for next monday (sept 1) | 14:25 |
notmyname | I'm at the openstack ops meetup in san antonio today and tomorrow, so I'll be in-and-out of IRC | 14:25 |
*** IRTermite has joined #openstack-swift | 14:27 | |
notmyname | thomaschaaf: what do you mean by "enable" xprofile? it does need to be added to the pipeline, but that's it IIRC | 14:28 |
notmyname | ByteSore: mount_check is important if you aren't using real devices (eg loopback). mount_check makes sure that the OS says it's mounted, and if not it returns a 507 | 14:28 |
*** jdag_ has joined #openstack-swift | 14:29 | |
*** bgmccollum_ has quit IRC | 14:32 | |
*** pandemicsyn has quit IRC | 14:32 | |
*** jdag has quit IRC | 14:32 | |
*** mtreinish has quit IRC | 14:32 | |
*** jroll has quit IRC | 14:32 | |
*** zacksh has quit IRC | 14:32 | |
*** zacksh has joined #openstack-swift | 14:32 | |
*** mtreinish has joined #openstack-swift | 14:32 | |
*** bgmccollum has joined #openstack-swift | 14:32 | |
*** pandemicsyn has joined #openstack-swift | 14:33 | |
*** jroll has joined #openstack-swift | 14:33 | |
*** jdag_ is now known as jdag | 14:34 | |
*** elambert has quit IRC | 14:36 | |
*** judd7 has joined #openstack-swift | 14:37 | |
*** thomaschaaf has quit IRC | 14:38 | |
*** erlon has joined #openstack-swift | 14:40 | |
*** erlon has quit IRC | 14:40 | |
*** erlon has joined #openstack-swift | 14:40 | |
*** mtreinish_ has joined #openstack-swift | 14:50 | |
*** pandemicsyn has quit IRC | 14:50 | |
*** bgmccollum has quit IRC | 14:50 | |
*** zacksh has quit IRC | 14:50 | |
*** mtreinish has quit IRC | 14:50 | |
*** bgmccollum has joined #openstack-swift | 14:50 | |
*** zacksh has joined #openstack-swift | 14:50 | |
*** pandemicsyn has joined #openstack-swift | 14:50 | |
*** mtreinish_ is now known as mtreinish | 14:51 | |
*** tsg has joined #openstack-swift | 14:55 | |
*** tgohad has joined #openstack-swift | 14:55 | |
*** kopparam has quit IRC | 14:57 | |
*** kopparam has joined #openstack-swift | 14:57 | |
*** mwstorer has joined #openstack-swift | 14:59 | |
*** kopparam has quit IRC | 15:00 | |
*** annegentle has joined #openstack-swift | 15:00 | |
*** dvas___ has quit IRC | 15:12 | |
*** pconstantine has quit IRC | 15:12 | |
*** dvas___ has joined #openstack-swift | 15:27 | |
*** pconstantine has joined #openstack-swift | 15:31 | |
*** atan8 has quit IRC | 15:36 | |
*** dvas___ has quit IRC | 16:04 | |
*** annegentle has quit IRC | 16:04 | |
*** bvandenh has quit IRC | 16:04 | |
*** dvas___ has joined #openstack-swift | 16:04 | |
*** nshaikh has quit IRC | 16:07 | |
*** dvas___ has quit IRC | 16:08 | |
*** mahatic has joined #openstack-swift | 16:12 | |
*** atan8 has joined #openstack-swift | 16:14 | |
*** atan8 has quit IRC | 16:34 | |
*** elambert has joined #openstack-swift | 16:55 | |
*** openstackgerrit has quit IRC | 17:00 | |
*** dvas___ has joined #openstack-swift | 17:05 | |
*** dvas___ has quit IRC | 17:12 | |
*** dvas___ has joined #openstack-swift | 17:12 | |
*** openstackgerrit has joined #openstack-swift | 17:14 | |
*** dvas___ has quit IRC | 17:15 | |
*** dvas___ has joined #openstack-swift | 17:15 | |
*** dvas___ has quit IRC | 17:19 | |
*** geaaru has quit IRC | 17:21 | |
*** esmute has quit IRC | 17:24 | |
*** aix has quit IRC | 17:24 | |
*** peluse has left #openstack-swift | 17:35 | |
*** peluse has joined #openstack-swift | 17:35 | |
*** esmute has joined #openstack-swift | 17:37 | |
*** shri has joined #openstack-swift | 17:40 | |
*** tsg has quit IRC | 17:40 | |
*** tgohad has quit IRC | 17:41 | |
*** gyee has joined #openstack-swift | 17:48 | |
*** tsg has joined #openstack-swift | 17:55 | |
*** tgohad has joined #openstack-swift | 17:55 | |
*** esmute has quit IRC | 18:00 | |
*** esmute has joined #openstack-swift | 18:00 | |
occupant | so I'm running on CentOS 6 and I thought I'd try using a elrepo 3.0 kernel on the storage nodes because I suspected my hardware was being held back by the CentOS kernel. Went from 40% idle to 4-5% idle. | 18:02 |
*** elambert has quit IRC | 18:02 | |
*** elambert has joined #openstack-swift | 18:05 | |
*** pconstantine has quit IRC | 18:18 | |
*** jasondotstar has quit IRC | 18:30 | |
*** jasondotstar has joined #openstack-swift | 18:31 | |
*** gvernik has joined #openstack-swift | 18:32 | |
*** pconstantine has joined #openstack-swift | 18:34 | |
*** elmiko has joined #openstack-swift | 18:35 | |
elmiko | hey folks, i'm looking for the preferred method to get the storageURL for Swift in a project. would i be better served creating a Connection and using get_auth or is there a way to query the service catalog from keystone? | 18:36 |
*** jasondotstar has quit IRC | 18:38 | |
*** gvernik has quit IRC | 18:38 | |
*** elambert has quit IRC | 18:39 | |
*** marcusvrn has joined #openstack-swift | 18:44 | |
*** haomaiwa_ has joined #openstack-swift | 18:46 | |
*** haomaiw__ has quit IRC | 18:47 | |
*** gvernik has joined #openstack-swift | 19:03 | |
*** jasondotstar has joined #openstack-swift | 19:03 | |
*** mahatic has quit IRC | 19:03 | |
*** rick_ has joined #openstack-swift | 19:05 | |
*** gvernik has quit IRC | 19:10 | |
clayg | notmyname: how's SA? | 19:11 |
rick_ | Let's say that we have 3 copies of data on three different disks within the same sotrage server or within cluster. On what basis does Swift decide from which disk it will read the data? Does it know which disk could serve data the fastest (based on disk utilization) or is there some other decision criteria? | 19:13 |
clayg | rick_: mostly it's random | 19:14 |
clayg | rick_: there's things like timing affinity that sorta act like huristics to sort things - but it's not so scientific | 19:15 |
clayg | elmiko: I'm sure you could get a catalog from keystone - but get_auth is generally recommeneded | 19:16 |
elmiko | clayg: thanks, i can get it working either way, i was more curious if there was a "best practice" or some such | 19:16 |
rick_ | maybe also this question for you clayg. Is it already possible, with Swift-on-File as an open-source solution, to save/read objects to Swift backend through legacy NFS protocol? | 19:17 |
clayg | occupant: and less idle is better in your case? you've got some active load going at it? | 19:17 |
clayg | rick_: swift-on-file is other way - talk swift to a file system; not talk file system to swift | 19:18 |
clayg | rick_: i'm not aware of an opensource solution that let's you point legacy applications that talk file system to an nfs share to use object storage | 19:18 |
rick_ | maybe some FUSE solution could allow this? some aditional fs layer on top of object storage? I was loking this -> https://code.google.com/p/s3ql/wiki/other_s3_filesystems | 19:19 |
*** mahatic has joined #openstack-swift | 19:22 | |
rick_ | I am looking Huawei UDS solution from SNIA conference, they are using s3fs, but I do not know possible hacks they made -> http://www.snia.org/sites/default/files2/SDC2013/presentations/ObjectStorage/QuingchaoLuo_Huawei%20SmartDisk_based_Object_Storage.pdf | 19:22 |
rick_ | You can see picture on S3 FS slide | 19:22 |
rick_ | slide number 19 | 19:23 |
rick_ | So I am guessing possible Swiftstack is using something similar -> https://www.swiftstack.com/uploads/factsheets_pdf/swiftstack_filesystem_gateway.pdf | 19:24 |
*** occupant has quit IRC | 19:37 | |
tdasilva | rick_: swiftonfile currently supports only FS with xattr support. You can write a file and get it from swift, but you need to know the full path | 19:37 |
*** occupant has joined #openstack-swift | 19:38 | |
rick_ | So currently there is only comercial sw from Swiftstack - Filesystem Gateway available that could do vice-versa manipulating data? | 19:39 |
clayg | rick_: another swiftstack employee who's also a swift core dev reminded me of https://github.com/redbo/cloudfuse | 19:42 |
clayg | rick_: redbo lurks in here sometimes - he may (or may not) comment on his opinion of how successful that might be on nfs | 19:43 |
clayg | er rather exposing the fuse file system to nfs | 19:43 |
rick_ | clayg, tdasilva: thank you for the comments provided. I will also check on cloudfuse. | 19:46 |
redbo | hmmm... I'm not sure. nfs (as of v4) can export a fuse filesystem if you configure it right. But I don't know if cloudfuse is correct enough for nfs. | 19:48 |
*** mahatic has quit IRC | 19:56 | |
*** fifieldt_ has joined #openstack-swift | 20:03 | |
*** fifieldt has quit IRC | 20:06 | |
rick_ | Maybe this is interesting: https://access.redhat.com/documentation/en-US/Red_Hat_Storage/2.0/html/Administration_Guide/chap-User_Guide-UFO.html | 20:07 |
*** annegentle has joined #openstack-swift | 20:08 | |
tdasilva | rick_: that's basically describing swiftonfile | 20:09 |
tdasilva | the project used to be called gluster-swift and we have now changed the name to swiftonfile. It allows for swift to access objects stored on a filesystem following the same path as the URL | 20:11 |
tdasilva | so if you store a file on /mnt/swiftonfile/acct/cont/obj, then you can GET the object "acct/cont/obj" with swift and vice-versa | 20:12 |
rick_ | It says : "Unified File and Object Storage technology enables enterprises to adopt and deploy cloud storage solutions. It allows users to access and modify data as objects from a REST interface along with the ability to access and modify files from NAS interfaces including NFS and SMB. " | 20:13 |
tdasilva | correct....i think some of the confusion is that earlier you asked if you could write object to swift backend throught nfs, which sounded like you wanted to migrate data from a legacy system to a swift cluster with its own backend....with swiftonfile your NFS mount point is your swift backend storage | 20:15 |
tdasilva | with the new storage policies, you could deploy a swift cluster with policies that use the default storage backend of swift and you could add another swiftonfile policy that access your objects over your fuse mount point | 20:17 |
rick_ | sri: thx for the link provided, please send me also your email. | 20:17 |
*** dvas___ has joined #openstack-swift | 20:18 | |
shri | rick_: Sent it to you directly. | 20:19 |
rick_ | tdasilva: ok, so with swift-on-file , Swift object storage backend can be mounted somehow to be used together with legacy NFS/CIFS appication.... if i understad siwft-on-file is able to translate NFS/CIFS protocol to REST API/Swift API calls? | 20:22 |
rick_ | shri: thx for contact | 20:22 |
notmyname | clayg: SA is hot! | 20:28 |
tdasilva | rick_: swiftonfile allows you to write/read files through the swift rest interface as well as a NAS interface | 20:28 |
notmyname | clayg: but they've got a nice new event center at rackspace to host the ops meetup | 20:29 |
tdasilva | rick_: this doc is a bit more up to date then the previous one: https://access.redhat.com/documentation/en-US/Red_Hat_Storage/2.1/html/Administration_Guide/chap-User_Guide-Object_Store.html | 20:29 |
rick_ | ok. let me check it out | 20:30 |
IRTermite | notmyname: indeed we do! | 20:31 |
tdasilva | rick_: checkout the #swiftonfile channel...i have to get going, but other folks might be able to help | 20:31 |
rick_ | ok, no problem. thx for all the info! | 20:32 |
tdasilva | or feel free to post questions here: https://github.com/swiftonfile/swiftonfile/issues | 20:32 |
tdasilva | no problem...good luck | 20:32 |
*** miqui has quit IRC | 20:33 | |
*** tdasilva has quit IRC | 20:36 | |
clayg | dfg: ok, I think i see the idea that you don't want to limit the node completely - but I thought that sliding time window would still do that - but you may have to convince sam to help me with the math as to why random.random() < weighted_average works out to letting 10% of requests go through and not... some fucking random amount of requests who happen to return a value less than weight_average go through... | 20:50 |
clayg | dfg: either way i'm glad your back and looking at that patch - i've been thinking about that patch a lot and i'm sorta getting a crush on it | 20:53 |
dfg | um... | 20:53 |
dfg | clayg: what do you mean? | 20:54 |
dfg | by the "random.random() < weighted_average works out to letting 10% of requests" ? | 20:54 |
clayg | i was trying to interpret your comment on my comment about the coin flip? | 20:55 |
dfg | like the weighted average gives the individual nodes kinda a score and then the proxy tries to limit based on that. | 20:55 |
dfg | if, based on the history 90% of the requests resulted in a timeout then there will be a 90% chance that the node will be skipped | 20:56 |
clayg | dfg: yeah I think i get that... but I think i was looking for if weighted_average > "some known value at which i say screw this node" with maybe a tunable or something and instead i found a call to random and realized I have no idea what i'm looking at anymore :'( | 20:57 |
clayg | dfg: oh oh oh, ok gimme a second | 20:57 |
dfg | oh- i don't do that. | 20:57 |
dfg | i won't ever complete;y stop sending reqs (how would I know what that number is and how would i know when to try starting again) | 20:59 |
clayg | yeah yeah yeah; cool cool cool - i was just confused. this stuff is hard. you do like a fire-side chat where we can all just gather around and you beat stupid out of us | 21:00 |
clayg | or oh oh *I* know - you could come to a design summit or a hack-a-thon every once in a while | 21:00 |
clayg | :P | 21:01 |
dfg | ya- of course the one i went to you weren't there | 21:01 |
clayg | fair :\ | 21:02 |
dfg | anyway- i'm not saying that error limiting is the best or anything but i'm trying to ease into it. even a dumb limiting like I have should help a lot i think but i wrote it to be pretty lax i think (hope) | 21:02 |
dfg | i mean i just don't want to just like break everything all at once :) | 21:04 |
clayg | dfg: I think what you have is pretty sophisticated and I definately think it would help (maybe *quite* a lot) - i'm really keen on this change; I'd be interested in ideas you have on how to test it out and what we can do to help | 21:04 |
dfg | clayg: well to test it i have some crappy middleware in our local stuff that sits on the obj server and randomly slows crap down based on configs. the tests do fine but then i feel that i'm writing the test for the feature and it doesn't mean much. idk | 21:07 |
dfg | anyway- all that will have to be expanded on when its gets cooked more. but I'll keep y'all in the loop. i got kinda side tracked with a couple things recently | 21:16 |
clayg | I'm chatting across the table with swifterdarrell we also have some crappy "break some random stuff" middleware's lying about - you think we should try and gather requirements and do something more useful or just throw 'em out there (tcod?) and let everyone kinda just sorta hack around the edges on their own stuff? | 21:19 |
dfg | clayg: that would be cool. | 21:22 |
swifterdarrell | dfg: i haven't actually evolved to "middleware" yet--just a hacked-in latency injector... but what I actually *want* is a configurable layer like middleware suitable for fuzz-testing various failure modes (random latencies injected, random connection severing, etc.) | 21:23 |
swifterdarrell | dfg: I think that could be useful for testing various Swift clients or applications... hard to shake that stuff out w/o a real cluster and who wants to have to twist their real cluster into the random weird shit that shows up under load? | 21:24 |
notmyname | swifterdarrell: https://github.com/notmyname/latency_middleware (super old. should* still work) | 21:25 |
notmyname | nto as full featured as you are wanting, though | 21:26 |
*** acoles has quit IRC | 21:30 | |
dfg | swifterdarrell: that sounds cool. i'll clean up my stuff and show you want I have. it would be cool to have something simple / moderately put together that people can use to try this type of stuff out. | 21:30 |
clayg | notmyname: it's a start? but like with david's code we'd need something that would like sleep for >10s before responding and then go back to normal | 21:30 |
notmyname | clayg: ya. for sure. I wrote that a long time ago when I was trying to debug something or other | 21:31 |
swifterdarrell | dfg: ya, any kind of working skeleton would be a great start for me | 21:31 |
clayg | notmyname: to use something like that in a probetest you might want to have the middleware do a reloading config trick (probably *not* the object-server.conf) where the test could control the values | 21:31 |
dfg | clayg: thats basically what mine does. i works for PUTs and GETs and can read in some bytes before crapping out and stuff. | 21:32 |
notmyname | ah, that would be cool | 21:32 |
notmyname | ya, I totally expect whatever dfg has to be much better than mine | 21:32 |
swifterdarrell | dfg: my main problem was that i could inject 16s latency where I knew some code had a 15s timeout, but it wasn't selective enough for initialization stuff to work, followed by later timeouts... I think a probabilistic latency would have been sufficient, perhaps with some ramp-up | 21:32 |
notmyname | why should you use swift? this is why: http://d.not.mn/a-disk-in-the-SAN-is-about-to-fail.gif | 21:34 |
*** dvas___ has quit IRC | 21:35 | |
*** dvas___ has joined #openstack-swift | 21:35 | |
*** dvas___ has quit IRC | 21:40 | |
*** dvas___ has joined #openstack-swift | 21:44 | |
*** dvas____ has joined #openstack-swift | 21:47 | |
*** dvas___ has quit IRC | 21:49 | |
*** annegentle has quit IRC | 21:52 | |
*** annegentle has joined #openstack-swift | 21:52 | |
*** dvas____ has quit IRC | 21:53 | |
*** dvas____ has joined #openstack-swift | 21:54 | |
*** dvas____ has quit IRC | 21:59 | |
*** occup4nt has joined #openstack-swift | 21:59 | |
*** occupant has quit IRC | 22:01 | |
*** serverascode has quit IRC | 22:01 | |
*** hurricanerix has quit IRC | 22:01 | |
*** hurricanerix_ has joined #openstack-swift | 22:01 | |
*** dmsimard is now known as dmsimard_away | 22:02 | |
*** jasondotstar is now known as jasondotstar|afk | 22:02 | |
*** serverascode has joined #openstack-swift | 22:02 | |
*** __lgw4__ has quit IRC | 22:05 | |
*** occup4nt is now known as occupant | 22:06 | |
*** mitz has quit IRC | 22:06 | |
*** HenryG_ has joined #openstack-swift | 22:12 | |
torgomatic | notmyname: there are more words on the internet for you to read now, particularly on https://review.openstack.org/#/c/111562/ | 22:13 |
*** HenryG has quit IRC | 22:15 | |
mattoliverau | Morning all | 22:23 |
*** annegentle has quit IRC | 22:24 | |
rick_ | maybe weird question, but how Swift writes data to disk. In how many steps is data written to disk. I know that account/container db file is updated and than data is written somewhere to the disk. Is this happening simultaneous or is there some waiting mechanisms....etc. I know that there is no journaling involved as it is in the case of Ceph, which wants to be stroingly consistent... | 22:29 |
*** shakamunyi has joined #openstack-swift | 22:31 | |
*** elmiko is now known as _elmiko | 22:38 | |
*** shakamunyi has quit IRC | 22:40 | |
*** joeljwright has quit IRC | 22:42 | |
*** joeljwright has joined #openstack-swift | 22:43 | |
*** joeljwright has quit IRC | 22:43 | |
*** Midnightmyth has quit IRC | 22:50 | |
*** annegentle has joined #openstack-swift | 22:51 | |
*** shakamunyi has joined #openstack-swift | 22:54 | |
*** zul has quit IRC | 22:57 | |
*** mwstorer has quit IRC | 22:58 | |
*** annegentle has quit IRC | 23:06 | |
*** zul has joined #openstack-swift | 23:09 | |
*** erlon has quit IRC | 23:10 | |
*** marcusvrn has quit IRC | 23:31 | |
*** _elmiko is now known as elmiko | 23:31 | |
*** annegentle has joined #openstack-swift | 23:36 | |
*** annegentle has quit IRC | 23:43 | |
*** sungju has joined #openstack-swift | 23:57 | |
*** tgohad has quit IRC | 23:58 | |
*** tsg has quit IRC | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!