Monday, 2014-07-07

*** dmorita has joined #openstack-swift00:24
*** DisneyRicky has joined #openstack-swift00:25
*** DisneyRicky has quit IRC00:50
*** DisneyRicky has joined #openstack-swift01:08
*** DisneyRicky has quit IRC01:25
*** charz_ is now known as charz01:36
*** nosnos has joined #openstack-swift01:37
*** miqui_ has quit IRC02:11
*** robsparker has quit IRC02:28
*** bkopilov has quit IRC02:40
*** robsparker has joined #openstack-swift02:41
*** ho has joined #openstack-swift02:50
*** mrsnivvel has joined #openstack-swift03:07
*** aswadr has joined #openstack-swift03:09
*** nosnos has quit IRC03:25
*** Andrew___ has joined #openstack-swift03:39
*** zhiyan_ is now known as zhiyan03:40
Andrew___hello~03:41
Andrew___I think there is something wrong with the name and description of funtion weight_of_one_part in RingBuilder class. Is there someone who think like me?03:45
Andrew___I think that it is not weight of one part but part of one weight. right?03:47
*** bkopilov has joined #openstack-swift03:59
*** nosnos has joined #openstack-swift04:02
*** ppai has joined #openstack-swift04:08
*** zhiyan is now known as zhiyan_04:20
mattoliverauAndrew___: Its attempting to get the wieght of a partition based of the total weights of all the devices.  So I think its named correctly. The part isn't 'part' its a swift partition, an intergral part of the swfit modified consistant hashing ring. See  http://docs.openstack.org/developer/swift/overview_ring.html04:20
*** elambert has joined #openstack-swift04:51
*** ajc_ has joined #openstack-swift04:52
*** Andrew___ has quit IRC05:16
*** psharma has joined #openstack-swift05:26
*** anand_ts has joined #openstack-swift05:33
*** chandan_kumar has joined #openstack-swift05:34
*** Andrew has joined #openstack-swift06:33
openstackgerritMatthew Oliver proposed a change to openstack/swift: Swift configuration parameter audit  https://review.openstack.org/10476007:03
*** haomaiwa_ has joined #openstack-swift07:05
*** chandan_kumar is now known as chandankumar07:23
*** mkerrin has quit IRC07:41
*** mitz_ has quit IRC07:41
*** nacim has joined #openstack-swift07:42
*** mkerrin has joined #openstack-swift07:45
*** jyoti-ranjan has joined #openstack-swift07:49
*** mmcardle has joined #openstack-swift08:14
*** mariusv has quit IRC08:17
*** mariusv has joined #openstack-swift08:19
*** mitz_ has joined #openstack-swift08:23
*** mmcardle has quit IRC08:26
*** zhiyan_ is now known as zhiyan08:30
*** andyandy has joined #openstack-swift08:34
*** Andrew has quit IRC09:07
*** markd has quit IRC09:17
*** DisneyRicky has joined #openstack-swift09:22
*** DisneyRicky has quit IRC09:37
*** andrew has joined #openstack-swift09:51
*** bvandenh has joined #openstack-swift10:02
*** DisneyRicky has joined #openstack-swift10:34
*** haomaiwa_ has quit IRC10:38
*** haomaiwa_ has joined #openstack-swift10:38
anand_tsanyone have idea on how to give Access control list to users using Swift service10:46
anand_tsusers are having admin access when I give admin or Swift operator access, As a normal user I need to give only read only access to the containers. ie. view and download objects, not to upload10:47
anand_tswhich file I need to edit?10:47
*** DisneyRicky has quit IRC10:47
*** haomaiwa_ has quit IRC10:57
*** haomai___ has joined #openstack-swift10:57
*** DisneyRicky has joined #openstack-swift10:58
*** ppai has quit IRC11:00
*** andrew has quit IRC11:10
*** ppai has joined #openstack-swift11:13
*** DisneyRicky has quit IRC11:17
*** ho has quit IRC11:31
*** mmcardle has joined #openstack-swift11:32
*** DisneyRicky has joined #openstack-swift11:45
*** dmorita has quit IRC11:46
*** DisneyRicky has quit IRC12:01
*** Anticimex has quit IRC12:17
*** Anticimex has joined #openstack-swift12:24
*** pandemicsyn has quit IRC12:28
*** zz_wasmum has quit IRC12:28
*** serverascode has quit IRC12:28
*** Alex_Gaynor has quit IRC12:28
*** swills has quit IRC12:29
*** zz_wasmum has joined #openstack-swift12:29
*** nottrobin has quit IRC12:29
*** rpedde has quit IRC12:29
*** dfg_ has joined #openstack-swift12:30
*** rpedde has joined #openstack-swift12:30
*** swills has joined #openstack-swift12:30
*** gholt has quit IRC12:30
*** zacksh has quit IRC12:30
*** zacksh has joined #openstack-swift12:30
*** swills has quit IRC12:30
*** swills has joined #openstack-swift12:30
*** nottrobin_ has joined #openstack-swift12:30
*** joearnold has quit IRC12:30
*** hugokuo has quit IRC12:30
*** cschwede has quit IRC12:30
*** dfg has quit IRC12:31
*** Alex_Gaynor_ has joined #openstack-swift12:31
*** nottrobin_ has quit IRC12:31
*** nottrobin_ has joined #openstack-swift12:31
*** Alex_Gaynor_ has quit IRC12:31
*** Alex_Gaynor_ has joined #openstack-swift12:31
*** pandemicsyn has joined #openstack-swift12:31
*** serverascode has joined #openstack-swift12:31
*** nottrobin_ is now known as nottrobin12:32
*** cschwede has joined #openstack-swift12:32
*** joearnold has joined #openstack-swift12:32
*** ajc_ has quit IRC12:33
*** gholt has joined #openstack-swift12:33
*** ChanServ sets mode: +v gholt12:33
*** hugokuo has joined #openstack-swift12:33
*** mmcardle has quit IRC12:46
*** bkopilov has quit IRC12:53
*** nosnos has quit IRC13:02
*** chandan_kumar has joined #openstack-swift13:10
*** mmcardle has joined #openstack-swift13:12
*** chandankumar has quit IRC13:15
*** ppai has quit IRC13:15
*** chandan_kumar is now known as chandankumar13:15
*** miqui has joined #openstack-swift13:17
*** zhiyan is now known as zhiyan_13:37
*** psharma has quit IRC13:44
*** sandywalsh has joined #openstack-swift13:47
*** tdasilva has joined #openstack-swift13:48
*** anand_ts has quit IRC13:55
*** swat30 has quit IRC14:01
*** thurloat has quit IRC14:01
*** lpabon has joined #openstack-swift14:06
*** swat30 has joined #openstack-swift14:07
*** tellesnobrega has left #openstack-swift14:10
*** thurloat has joined #openstack-swift14:13
*** bkopilov has joined #openstack-swift14:16
*** annegent_ has joined #openstack-swift14:20
*** tsg has joined #openstack-swift14:36
*** mmcardle has quit IRC14:45
*** pberis has joined #openstack-swift14:46
*** chandankumar has quit IRC14:51
*** kevinc_ has joined #openstack-swift14:54
*** elambert has quit IRC14:55
*** physcx has joined #openstack-swift14:56
*** sandywalsh has quit IRC15:01
*** annegent_ has quit IRC15:02
*** annegent_ has joined #openstack-swift15:02
*** sandywalsh has joined #openstack-swift15:03
*** sandywalsh_ has joined #openstack-swift15:05
*** chandan_kumar has joined #openstack-swift15:06
*** sandywalsh has quit IRC15:08
*** kevinc_ has quit IRC15:34
*** kevinc_ has joined #openstack-swift15:39
*** zaitcev has joined #openstack-swift15:40
*** ChanServ sets mode: +v zaitcev15:40
*** aswadr has quit IRC15:42
*** sandywalsh_ has quit IRC15:57
*** sandywalsh has joined #openstack-swift15:59
*** annegent_ has quit IRC16:07
openstackgerritOpenStack Proposal Bot proposed a change to openstack/swift: Merge tag '2.0.0'  https://review.openstack.org/10522216:08
*** kevinc_ has quit IRC16:08
*** mwstorer has joined #openstack-swift16:19
openstackgerritDonagh McCabe proposed a change to openstack/swift-specs: Handling X-Service-Token in keystoneauth middleware  https://review.openstack.org/10522816:27
*** elambert has joined #openstack-swift16:30
notmynameFYI, Swift 2.0 final is out. http://tarballs.openstack.org/swift/swift-2.0.0.tar.gz there will be some press releases and blog posts tomorrow (thanks cschwede!)16:34
notmynameplease don't make a big deal about it today. make a big deal about it tomorrow16:34
claygnotmyname: can i just not make a big deal about it at all?16:35
*** cpen has joined #openstack-swift16:35
physcxis there a 2.0 feature list or change log?16:36
notmynamephyscx: official changelog at https://github.com/openstack/swift/blob/master/CHANGELOG16:39
*** kevinc_ has joined #openstack-swift16:40
physcxclayg: got a minute to talk about Buffer DiskfileWriter writes?16:46
*** shri has joined #openstack-swift16:49
*** ChanServ changes topic to "Swift 2.0 https://launchpad.net/swift/juno/2.0.0 | Swift Review Dashboard: http://bit.ly/1iVBigF"16:52
*** annegent_ has joined #openstack-swift16:53
*** mlipchuk has joined #openstack-swift16:57
*** mlipchuk has left #openstack-swift16:57
*** erlon has joined #openstack-swift16:58
*** jyoti-ranjan has quit IRC17:16
*** Alex_Gaynor_ is now known as Alex_Gaynor17:37
*** Alex_Gaynor has quit IRC17:37
*** Alex_Gaynor has joined #openstack-swift17:37
*** gyee has joined #openstack-swift17:41
*** miqui has quit IRC17:45
*** andyandy has quit IRC17:48
*** miqui has joined #openstack-swift17:49
*** Tyger has joined #openstack-swift17:51
*** kevinc_ has quit IRC17:52
*** infotection has quit IRC18:10
*** infotection has joined #openstack-swift18:16
notmynameidea for someone looking for something to do: in python-swiftclient, replace the dependency on keystoneclient with the rest api calls. that way we can support auth v2+ out of the box and also not get all the transitive dependencies of keystoneclient18:31
*** miqui has quit IRC18:32
*** foexle has joined #openstack-swift18:32
*** CaioBrentano has joined #openstack-swift18:40
*** miqui has joined #openstack-swift18:41
*** occup4nt is now known as occupant18:42
*** gyee has quit IRC18:42
*** thurloat has quit IRC18:45
*** swat30 has quit IRC18:46
claygphyscx: sure18:46
anticwnotmyname: +118:54
*** foexle has quit IRC19:02
*** kevinc_ has joined #openstack-swift19:06
*** chandan_kumar has quit IRC19:06
*** gyee has joined #openstack-swift19:06
notmynameanticw: any chance you could put a dev on it? ;-)19:06
*** annegent_ has quit IRC19:07
*** annegent_ has joined #openstack-swift19:08
*** annegent_ has quit IRC19:13
anticwnotmyname: actually, i do have a list of things and this was already on it ... timing is always tricky19:22
*** kevinc_ has quit IRC19:22
anticwnotmyname: multiple-endpoints is higher on the list19:22
notmynamegreat19:22
notmynamewhat's multiple endpoints? (I mean, I know what it is. I just want to make sure you do ;-) )19:22
anticwzaitcev: btw, this reminds me ... swiftclient 1.13.1 in RDO is broken ... i forget how but i have an image of what i hacked up19:23
anticwnotmyname: v2+ auth responses can specifiy multiple storage URLs ... which last i checked swiftclient doesn't deal with19:23
notmynameanticw: ah, cool19:24
anticwactually, few things deal with this well ...   some things use first, some last ... some just get confused and cry19:24
zaitcevanticw: so... needs 2.0 something?19:24
anticwzaitcev: i recall now .... there code adds content-length headers in some cases19:24
anticwand because it no longer uses python-request or something ... they are added by the lower layers as well19:24
anticwso you get two of these ... swift is fine with thatm nginx gives a 40019:25
anticwYES I KNOW NGINX IS BALLS :-)19:25
zaitcevinteresting19:25
zaitcevWell, I still use Pound, so I didn't notice.19:25
anticwusing --os-storage-url=http://something/with/netcat/listening i captured headers and see this19:26
anticwit's probably upstream swiftclient as well in all fairness, not just rdo19:26
zaitcev    version_string = str(pbr.version.VersionInfo('python-swiftclient'))19:27
zaitcevI hate all this automation19:28
* anticw hates pbr19:28
*** mkerrin1 has joined #openstack-swift19:28
zaitcev>>> swiftclient.version.version_string19:28
zaitcev'2.0.2'19:28
anticwzaitcev: ok, upstream from github has the issue there ... so if you want i'll just put up a patch for you to eyeball19:29
zaitcevokay. We probably want to upgrade to 2.0.2 in RDO, at least in Icehouse19:29
*** mkerrin has quit IRC19:29
zaitcevwait a moment, http://koji.fedoraproject.org/koji/buildinfo?buildID=49962619:29
zaitcevBut it's not pushed to RDO?19:29
anticwzaitcev: oh, one more things .... swift-proxy has a dependancy on swift3 ... it should be optional19:30
anticwswift3 in rdo is old and cruft (ie. breaks)19:30
anticws/cruft/crufty/19:30
zaitcevanticw: I can't help it. It's the same idiotic policy that add dependency on python-keystoneclient. You may file a bug if you want.19:31
anticwzaitcev: but it's NOT a requirement ... and it means replacing just swift3 is painful19:31
anticwin the end i just rm -r the crap underneath rpm19:31
zaitcevanticw: I have an idea: /join #rdo, or /quote jruzicka19:33
zaitcevBet he'll ask you to file a bug, because we're responsible for working on bugs19:33
anticwwill do19:33
*** pberis has quit IRC19:34
*** pberis has joined #openstack-swift19:34
zaitcevBTW, in addition to Swift, they asked me to work on Manila. Actually, "focus on Manila". Because Swift has too few bugs, so I have nothing to do.19:35
creihtlol19:35
notmynamewow19:35
anticwnotmyname: maybe too late, but for 2.0.0 can we take all the middleware mangling magic out?19:35
anticwand require it be explicit?19:35
notmynameanticw: nope. too late. that would have been better to address about 3 weeks ago19:36
*** annegent_ has joined #openstack-swift19:36
anticwcan we have 3.0.0 next month then? :)19:36
notmynameof course. the good things about release numbers is there is always a bigger number :-)19:36
*** annegent_ has quit IRC19:41
*** bvandenh has quit IRC19:41
anticwℵ_019:46
zaitcevor 2.0.0.pl119:49
*** physcx has quit IRC19:52
*** CaioBrentano has quit IRC19:55
*** CaioBrentano has joined #openstack-swift19:57
*** kevinc_ has joined #openstack-swift20:00
*** sandywalsh has quit IRC20:03
*** sandywalsh has joined #openstack-swift20:06
*** tdasilva has quit IRC20:11
*** peluse_ has quit IRC20:19
*** peluse_ has joined #openstack-swift20:19
*** infotection has quit IRC20:25
torgomaticsomeone in here earlier was talking about the chunked-upload buffering patch; who was that?20:26
torgomatic(I saw it on my phone, and that IRC client doesn't keep logs. Sorry.)20:26
*** mwstorer has quit IRC20:30
*** infotection has joined #openstack-swift20:33
*** mwstorer has joined #openstack-swift20:36
*** erlon has quit IRC20:39
*** foexle has joined #openstack-swift20:40
*** infotection has quit IRC20:41
anticwtorgomatic: kr4zy (sp?) was asking about it in the context of apache mod_wsgi20:47
torgomaticanticw: thanks; I'll keep any eye out and see if that user shows up again20:48
*** infotection has joined #openstack-swift20:48
*** miqui has quit IRC20:49
*** kevinc_ has quit IRC20:57
*** kevinc_ has joined #openstack-swift21:08
TaiSHiHello everyone21:10
*** tsg has quit IRC21:11
openstackgerritSamuel Merritt proposed a change to openstack/swift: Zero-copy object-server GET responses with splice()  https://review.openstack.org/10260921:13
notmynameTaiSHi: hello21:17
TaiSHiHey21:18
TaiSHiI'm planning on using a series of webservers that need to host same data (roughly 100k files) which is updated dynamically (user content)21:18
TaiSHiI've heard that swift manages metadata pretty well, which wouldn't screw up when listing folders with a big amount of files21:19
TaiSHiAnd to add to the matter, aside from the 'fixed' webservers, new ones will be fired up on-demand and would need to access the same data21:19
*** foexle has quit IRC21:31
notmynameTaiSHi: sounds similar to what swift can do21:34
notmynameTaiSHi: but the first thign to understand (and I want to make clear) is that swift isn't a shared filesystem21:34
TaiSHinotmyname: yeah, you told me, which is why I've been around21:35
notmyname:-)21:35
openstackgerritSamuel Merritt proposed a change to openstack/swift: Zero-copy object-server PUT requests with splice()  https://review.openstack.org/10470521:35
notmynameTaiSHi: ok, so that being covered, think of swift as a pool of storage. and if you spin up new webservers, they can access the pool as well21:35
notmynameno probems21:35
TaiSHiHmm, regarding the shared fs, I (tried to) use gluster. I don't know much about network filesystems other than ceph used as a block storage21:36
notmynameTaiSHi: have you used systems like AWS S3 or rackspace cloud files?21:37
TaiSHiNone deeply. It has escaped my needs so far21:38
notmynamethat's ok. just looking for a common frame of reference21:39
TaiSHiIt's not mounting the same NFS over multiple nodes perhaps ?21:39
notmynameno, not at all21:39
TaiSHiGreat (me and NFS have had our differences in the past)21:39
notmynamea swift cluster has an API enpoint. that endpoint is one or more "proxy servers", and those proxy servers talk to "storage nodes". the storage nodes have drives and read/write data. (in a high-level, close-enough sort of way)21:40
TaiSHiSo all the traffic would have to go through the proxy, not directly to the nodes, right ?21:41
notmynamecorrect. but there can be an arbitrary number of proxies. no shared state, horizontally scalable21:42
TaiSHiWhat bugs me is that the data will probably be hosted at the web server nodes themselves initially. I could propose a centralized fs (which would be GREAT)21:45
notmynamewell, think of a centralized object storage system (rather than an FS)21:46
notmynameie all the webservers talking to the same object storage pool21:46
notmynameor better yet, the webservers simply serving links for clients to directly access the storage pool (eg that's what wikipedia does for all their images. everything is stored in their swift cluster)21:47
TaiSHiSorry, I have to start incorporating the terms object/block storage21:47
TaiSHiGiven the fact that swift handles metadata really well, I do like the solution but as I said, initially webservers would also be storage nodes21:48
TaiSHiI know it's not ideal, but well, the customer is still unsure about this "cloud migration" (they currently use 1 server that handles ~700mB/s traffic)21:48
notmynamewhat do you mean by "swift handles metadata really well"? what is the metadata you're referring to?21:48
TaiSHiI might be using some internet adopted terms :P, my previous experience with an object storage (gluster) resulted in almost exploding my nodes due to a big amount of files (~100k)21:50
notmyname100k files is not a big number21:50
notmyname(from a swift perspective)21:50
TaiSHiFigured as mercadolibre and wikipedia use it21:53
notmynameok, so you've got a bunch of files created by your users that you need to have available on any of your many webservers, right?21:55
TaiSHiExactly21:55
notmynameso the way you do that with swift is to have your webservers serving your app (with links to the swift cluster) and a separate set of machines for your swift cluster.21:56
notmynamesize each for their specific needs (webservers for the app traffic and swift for the network transfer and storage)21:57
*** mkerrin1 has quit IRC21:57
notmynameyour users can upload and download directly to the swift cluster without needing to go through the webservers21:57
*** mkerrin has joined #openstack-swift21:57
TaiSHiBut they upload their images through the web app, so they'd still need to go through the webservers21:58
TaiSHi(I might be missing something here)21:58
notmynamewell, they wouldn't have to21:58
notmynameeg if you can get your users to send a PUT or POST request to a swift URL, then you can bypass the webservers21:59
notmynamebut that could be something you do later21:59
TaiSHiYeah I could talk to the dev, he's an open guy when it comes to techs21:59
notmynamefor now, maybe the simplest thing is to use your webservers to pass all traffic between the user and swift21:59
notmynameTaiSHi: have you read up on any of the swift architecture docs?22:00
TaiSHiI found some docs but they're for rc2.x and packages aren't as up to date on my distro22:00
notmynameTaiSHi: check out https://swiftstack.com/openstack-swift/architecture/22:01
TaiSHiActually "some docs" are the official openstack22:01
TaiSHiOk, let me do some reading22:01
TaiSHiThanks22:01
notmynameTaiSHi: actually, the parent page there https://swiftstack.com/openstack-swift/ has a lot of links to blog posts and some videos too22:01
TaiSHiOk, I'm going to do some reading22:02
TaiSHiBefore I go, I have a couple questions22:02
notmynameok22:03
TaiSHiI know that ideally I should use separate servers according to the needs, but would it be much of a hassle to use the webservers as nodes for now ?22:03
notmynamedepends on what sort of resource overhead you have on the webservers. ie cpu, ram, disk22:04
TaiSHiThey're digitalocean's VMs, the disk seems to perform fairly well22:06
notmynamehmm...22:07
notmynameso in general, I don't recommend running swift in a virtualized environment. you don't want eg digital ocean to suddenly rehome your VM and either cause a lot of data movement or, worse, place 2 of your VMs on the same host, thus raising your exposure to a single hardware failure22:08
TaiSHiI understand what you mean, sadly it is what I have at my disposal with this customer22:09
TaiSHi(I just recalled / saw the topic that 2.0 went live on ubuntu)22:10
TaiSHiswift looks great but perhaps I'm trying to overkill22:14
notmynameTaiSHi: would it help if you could install it on a VM locally and play with using the APi?22:15
TaiSHinotmyname: I'm actually free to install a lot of VMs on DO directly, I tend to test stuff that way22:15
TaiSHiFor now and given that the first site I'm migrating is rather small, I wont implement swift, but I'll read the architecture documentation and see if it's doable22:16
notmynameTaiSHi: https://github.com/swiftstack/vagrant-swift-all-in-one uses vagrant and virtual box. if you've got those, it's a really fast and simple way to get going22:16
TaiSHiOh, that is simpler lol22:16
openstackgerritSamuel Merritt proposed a change to openstack/swift: Zero-copy object-server PUT requests with splice()  https://review.openstack.org/10470522:16
TaiSHiMy job's computer is crappy, I'll probably do it at home22:16
TaiSHiI need to understand how to use the API and how to provide objects to the webservers22:17
notmynametorgomatic: my aren't you pushing a lot of splice patches today22:17
TaiSHinotmyname: thank you for your patience, seriously22:17
torgomaticnotmyname: now if only I can get one of them right ;)22:17
notmynameTaiSHi: sure. happy to help22:17
TaiSHiI am a completely newb on this, glad you pointed out a couple stuff22:18
notmynametorgomatic: as long as tests pass, right?22:18
torgomaticnotmyname: yeah, that was actually the problem...22:18
torgomaticold kernel on the py2.6 Jenkins boxes; stuff broke22:18
bgmccollumis there a correlation to which container-server updates which account-server when a container is created? like, is it 1:1, 2:2, 3:3 from get-nodes of both, or shuffle x:x, y:y, z:z?22:19
*** CaioBrentano has quit IRC22:19
notmynamebgmccollum: yes*22:19
bgmccollumi assume the * is for failure modes22:20
notmynamebgmccollum: * assuming that you have the same number of account and container replicas, it's basically [(x,y) for x in account_nodes for y in container_nodes]22:20
notmynameerr...s/account/object/22:21
bgmccollumso if i were piecing log messages together, to generate a graph...id have to look at the order from get-nodes22:21
TaiSHinotmyname: when you mentioned arbitrary number of proxy servers, that means that I could make each and one of the nodes a proxy as well and make them access themselves ?22:21
TaiSHi(that sounded fishy)22:21
notmynameie remember that each partition has replica_count nodes listed in the ring. although order doesn't matter, the first object replica goes to the first container replica, etc22:22
notmynameTaiSHi: ya. you can run all the swift services on the same box (proxy, account, container, and object)22:22
mattoliverauMorning all22:22
notmynamebgmccollum: are you building a graph from log messages? cause that would be cool22:23
notmynamebgmccollum: like https://github.com/notmyname/logflow maybe?22:23
TaiSHinotmyname: great that would solve the single-node failure and actually it would improve performance a bit22:23
bgmccollumit would be cool ;) -- no, more of a representation of steps when showing various commands22:23
notmynameTaiSHi: ya, swift is designed to automatically work around hardware failure.22:23
bgmccollumnotmyname: well hot damn22:24
TaiSHinotmyname: great, going to study (exam in a week) and keep reading on swift22:24
notmynamebgmccollum: it's not perfect (I can't yet tie the message to a particular swift process), but it works really well as a logical diagram22:25
bgmccollumnotmyname: its def interesting...22:25
Tygernotmyname: I notice you have that map obj-server to object-server for the referrer - so there's one place that looks at the referrer22:26
notmynamebgmccollum: eg compare http://d.not.mn/log_flow.png to http://d.not.mn/log_flow2.png22:27
notmynamebgmccollum: what I want is almost like the first one. I don't have enough info in the logs to make it jsut right though22:27
notmynameTyger: in that logflow repo? ya. but I don't care if that breaks ;-)22:28
Tygernotmyname: It looks like it actually wouldn't break, and the output wouldn't even change at all.22:28
notmynameTyger: the concern would be if someone else has done something similar. sorry i haven't had a chance to look yet. overall I think the patch is probably just fine :-)22:28
Tygernotmyname: Right. And I'm not in a rush to get it submitted, it's not like it's blocking anything.22:29
notmynamebgmccollum: but I'm imagining a day where I can take a swift log file (a big one) and then map out all the different interactions. I think that would be very cool22:29
bgmccollumnotmyname: yeah, that would be awesome22:30
notmynamebgmccollum: it would be pretty cool for after-the-fact usage analysis.22:30
notmynamebgmccollum: I /think/ if the log file had the pid in it then I could get all the right info.22:31
bgmccollumthe log file does have the PID in it22:31
notmynameand that would be simple* to add22:31
bgmccollumcontainer-server 169722:31
notmynamethe filename22:31
notmyname(* funny story about "simple". when I was at rackspace, he who called a problem simple by default volunteered to write the solution. I have since stopped calling things "simple")22:32
bgmccollumi usually jump to calling things impossible...then it ends up being like 3 lines22:32
*** pberis has quit IRC22:32
notmynamehmm..looks like I need to update that code anyway since the log fields were fixed upstream (account and container used to have two log fields swapped)22:33
*** pberis has joined #openstack-swift22:34
*** CaioBrentano has joined #openstack-swift22:35
notmynameah. just comments. values aren't actually used (yet)22:36
*** CaioBrentano has quit IRC22:36
notmynamebgmccollum: actually, what I think I want is that the PID is added to the log line itself. that way it works with multiple log files or just a single log file22:37
bgmccollumim seeing PIDs as part of the user agent in my logs22:37
Tygernotmyname: You mean the PID of the server processing the request?22:38
notmynameTyger: ya22:38
bgmccollumoh wait...thats the referrer UA / PID22:38
notmynameya, and that's good22:39
notmynameand useful22:39
notmynamebgmccollum: but look at http://d.not.mn/log_flow.png again22:39
notmynamebgmccollum: what I want is that I can know that the proxy is taking to which one of the 3 object servers with pids (and same with object->container)22:39
bgmccollumyeah i see now22:41
*** pberis has quit IRC22:43
bgmccollumyou know there were some puts from a particular proxy to a set of object servers, but you dont have PIDS for those object server22:43
*** pberis has joined #openstack-swift22:45
notmynamebgmccollum: playing around with something22:49
*** tsg has joined #openstack-swift22:49
openstackgerritSamuel Merritt proposed a change to openstack/swift: Use except x as y instead of except x, y  https://review.openstack.org/9661022:50
torgomaticdid we lose the auto-abandon bot at some point?22:54
notmynamebgmccollum: http://d.not.mn/sample_target.png <-- that's what I want22:55
torgomaticI'm pretty sure that patches with negative feedback used to get automatically-abandoned at some point, but that doesn't seem to be happening any more22:55
notmynamebgmccollum: I hand-added a pid to the end of each log line22:55
notmynametorgomatic: after one week, used to22:55
torgomaticnotmyname: well, it's not any more; see https://review.openstack.org/#/c/91729/ for proof22:56
notmynametorgomatic: seems hugokuo doesn't like it anymore anyway. I'll abandon it22:57
torgomaticnotmyname: thanks; I'll go ask in -infra and see what happened22:58
notmynametorgomatic: thanks22:58
*** kevinc_ has quit IRC22:58
openstackgerritSamuel Merritt proposed a change to openstack/swift: Zero-copy object-server PUT requests with splice()  https://review.openstack.org/10470523:10
*** cpen has quit IRC23:23
*** pberis has quit IRC23:23
*** occupant has quit IRC23:23
*** pberis has joined #openstack-swift23:26
TaiSHinotmyname: I feel stalked <323:29
notmynameTaiSHi: ;-)23:29
notmynameTaiSHi: actually, it's kinda nice that you called out digital ocean about supporting swift. I'd love to see that happen :-)23:30
TaiSHiI'm very interested on this and I do enjoy testing/implementing new stuff23:31
*** occupant has joined #openstack-swift23:33
zaitcevhttp://digitalocean.net/ -- Inspiring Action For Ocean Sustainability23:34
notmyname#swift on freenode <- students with an interest in the future of technology23:36
*** ho has joined #openstack-swift23:41
notmynamezaitcev: FWIW, https://www.digitalocean.com is the new hotness in hosting these days23:44
zaitcevnotmyname: I know23:44
notmynamebut they aren't cool yet, IMO, because they don't run swift (like RAX and HP and others)23:45
notmyname;-)23:45
*** elambert has quit IRC23:45
notmynameyet23:45
zaitcevI'm going to stay with Linode for now.23:45
ctennisdoubtful that will happen notmyname23:46
notmynamezaitcev: they aren't cool either, for the same reason ;-)23:47
TaiSHiLinode is a bit more expensive and has load balancers23:47
TaiSHiI'm currently using a homebrew one :P23:47
TaiSHiGood thing is that DO doesn't charge for bw as of yet23:48
TaiSHiI was able to pull out 600MB/s out of a 5$ vm :P23:53
*** markd has joined #openstack-swift23:54
*** tsg has quit IRC23:56
*** tsg has joined #openstack-swift23:57

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