Displaying #traffic-server/2016-01-06.log:

Wed Jan 6 02:53:46 2016  es:Joined the channel
Wed Jan 6 03:17:58 2016  es1:Joined the channel
Wed Jan 6 03:21:31 2016  es:Joined the channel
Wed Jan 6 04:53:04 2016  psp:Joined the channel
Wed Jan 6 06:16:17 2016  biilmann:Joined the channel
Wed Jan 6 06:59:41 2016  gancho_:Joined the channel
Wed Jan 6 12:10:42 2016  JSeymour:Joined the channel
Wed Jan 6 13:04:19 2016  niq:Joined the channel
Wed Jan 6 14:19:22 2016  shinrich1:Joined the channel
Wed Jan 6 14:23:45 2016  es:Joined the channel
Wed Jan 6 14:35:33 2016  davet_:Joined the channel
Wed Jan 6 15:45:28 2016  esproul:Joined the channel
Wed Jan 6 16:00:38 2016  jumby:Joined the channel
Wed Jan 6 16:16:04 2016  reveller1:Joined the channel
Wed Jan 6 16:17:51 2016  reveller2:Joined the channel
Wed Jan 6 16:19:28 2016  biilmann:Joined the channel
Wed Jan 6 16:35:40 2016  blattj:Joined the channel
Wed Jan 6 17:14:25 2016  niq:Joined the channel
Wed Jan 6 17:34:45 2016  biilmann:Joined the channel
Wed Jan 6 17:49:44 2016  reveller:Re: my ATS 3 node cluster PoC. I added a route to 224.0.0.0/4 and tested multicast using socat to 224.0.1.37:8888 and I was able to communicate between the 3 nodes.
Wed Jan 6 17:50:45 2016  zwoop:reveller there are some notes on the Wiki about getting clustering to run. I think one odd requirement is that they all have to have the same "name" in records.config
Wed Jan 6 17:50:55 2016  reveller:Discovery is working across the cluster, but each sees the other nodes as 'down'. Occasionally, there will be a flood where a node will see another as up/down/up/down repeatedly for a few seconds, then it stays down.
Wed Jan 6 17:51:33 2016  reveller:zwoop: all have CONFIG proxy.config.proxy_name STRING mwp2proxy
Wed Jan 6 17:53:59 2016  reveller:designing a new architecture where ATS Cluster is the solution for all SSL, reverse proxy and caching
Wed Jan 6 17:58:10 2016  zwoop:great, you know, you'll be the only one using it, so you will have to fix all the bugs!
Wed Jan 6 18:01:28 2016  reveller:No one else is using clustering in a prod environment? That could make it a tough sell. The 'writer of paychecks' has never been keen on me being able to focus on one product to support. I wouldn't mind!
Wed Jan 6 18:05:58 2016  gancho_:Joined the channel
Wed Jan 6 18:08:59 2016  dcarlin:reveller: I want to use clustering
Wed Jan 6 18:09:06 2016  dcarlin:I can't get buy in for same reason
Wed Jan 6 18:10:31 2016  dcarlin:Instead, the yahoo devs are hacking together a solution to use parent cache in a cluster mode. Similar to CARP protocol
Wed Jan 6 18:11:17 2016  dcarlin:I like the idea of clustering since its a separate protocol, no weirdness like plugins being run twice or at the wrong time.. or remapping between parent/child issues.
Wed Jan 6 18:15:55 2016  psp:Joined the channel
Wed Jan 6 18:20:46 2016  reveller:dcarlin: the clustering was a big part of my new arch. I liked the idea of cluster managed config and the distributed cache ( and not having to manage objects per cache node).
Wed Jan 6 18:24:27 2016  blattj:Joined the channel
Wed Jan 6 18:26:38 2016  dcarlin:so the plan is to modify parent cache so that it uses a consistent hash algorithm among a group of peers in in a cluster
Wed Jan 6 18:27:16 2016  dcarlin:the tricky part has been knowing what to do when a url hashes to the same host that the user agent connected to, in which case the request isn't forwarded to a "parent" (peer) in the same cluster
Wed Jan 6 18:27:25 2016  mlibbey:I don't get how that is different than the current parent consistent hash selection.
Wed Jan 6 18:27:47 2016  dcarlin:thats the difference
Wed Jan 6 18:27:58 2016  dcarlin:you end up with a loop when you select yourself
Wed Jan 6 18:30:31 2016  mlibbey:oh -- you don't end up having parents, you just have children, and effectively just list all the children as part of the config (including itself)
Wed Jan 6 18:31:01 2016  dcarlin:yes
Wed Jan 6 18:31:36 2016  dcarlin:there is a difference of opinion on how to identify that you've hit yourself
Wed Jan 6 18:32:22 2016  dcarlin:so in the first test, we had a different parent.config on every host in the cluster. Same list of hosts, but there was a token next to hostname of the server in parent.config so that if that was selected it behaved differently
Wed Jan 6 18:33:01 2016  dcarlin:but then some people didn't like that the identification of who 'itself' was in parent.config vs. records.config versus some automatic determination of 'itself'
Wed Jan 6 18:33:27 2016  dcarlin:and then, hypothetical situations like how to select itself automatically when multiple instances of ATS on same host - etc, etc :)
Wed Jan 6 18:33:51 2016  dcarlin:that I think is resolvable. The hard part has been when should plugins run
Wed Jan 6 18:34:43 2016  dcarlin:on the child request? on the parent request? what happens when you select yourself. In a true parent heirarchy, you can solve that by having different configs on the tiers. But in the cluster case, all hosts have same config
Wed Jan 6 18:36:24 2016  dcarlin:and then I had all sorts of issues with remaps :) host headers changing between parent/child selections. parent selection GET requests have FQDN in the request line which supersedes host header - its a whole mess
Wed Jan 6 18:36:52 2016  dcarlin:hence, I like that clustering protocol that taobao used is kind of OOB - its not http so no plugin or remap issues
Wed Jan 6 19:08:17 2016  PSUdaemon:dcarlin: why not just not put yourself in parent.config?
Wed Jan 6 19:08:33 2016  PSUdaemon:or are you saying that is the case that you go to origin?
Wed Jan 6 19:22:15 2016  jpeach:reveller: a good way to get traction on clustering is to make an easy way for devs to set it up
Wed Jan 6 19:22:53 2016  jpeach:if you could do the heavy lifting to automatically set up a test cluster in vagrant or something then I think devs would be more helpful
Wed Jan 6 19:26:39 2016  jrushford:Joined the channel
Wed Jan 6 19:40:05 2016  blattj:Joined the channel
Wed Jan 6 19:45:19 2016  dcarlin:PSUdaemon: I think the main issue is that if you don't include yourself in parent.config, then urls are going to hash to different places. what about when the rest of the cluster thinks a URL hashes to host25 but host25 (since it didn't include itself in parent config) thinks it hashes to host43
Wed Jan 6 19:46:35 2016  dcarlin:someone (bcall / amc) noticed too that the order of the hosts matters in parent.config too. It should probably sort them prior to computing hash ring. You can have same list of hosts in different order and end up with different results
Wed Jan 6 19:48:11 2016  PSUdaemon:yeah, that's either wrong, or a bug
Wed Jan 6 19:48:21 2016  amc:Yes. I didn't investigate thoroughly but in testing my parent cache changes if I didn't have the exact same list of parents I would get cycles.
Wed Jan 6 19:50:54 2016  amc:mlibbey - I think it can be made to work in that sort of way, I'm trying to get a design together for it.
Wed Jan 6 21:45:35 2016  biilmann:Joined the channel
Wed Jan 6 21:49:57 2016  zwoop:jpeach we have to figure out the license on doc/static/override.css
Wed Jan 6 22:09:25 2016  kichan:Joined the channel
Wed Jan 6 22:13:12 2016  dcarlin:Joined the channel
Wed Jan 6 22:14:57 2016  jpeach:Joined the channel
Wed Jan 6 22:16:14 2016  amc:Joined the channel
Wed Jan 6 22:53:25 2016  jrushford:Joined the channel

Comments