I'm generally +1 on NOT keying off the server type (i.e. EDGE vs MID) for ATS configs wherever we can get away with it. WRT parent.config, I'd think as a server I'd really only need to know whether or not I had parents, what kind of parents they are (origin vs proxy), and any extra attributes associated with that relationship (round_robin, go_direct, parent_retry). I shouldn't really care whether or not I'm an EDGE, a MID, or a FOO.
I'm trying to look at this from the perspective of having per-DS parent hierarchies in the future, and I think this should play nicely with that idea. - Rawlin On Wed, Oct 3, 2018 at 12:25 PM Gelinas, Derek <[email protected]> wrote: > > As it stands now, parent.config could sort of handle that. If a host has no > parents or has an origin, it will set it up like a mid. If not, it's going > to get the edge cache treatment and parents will be listed for each DS based > on the parent cachegroups assigned. > > That said, remap.config still functions on "I'm an edge, I'm a mid." So > there's still work to be done to get us there 100%. > > FYI I just tested this against prod database and across the board it did > exactly as expected. In a standard two-tier environment the parent.configs > were identical to the normal method, and in a single-tier environment the > parent.config went from incorrect and unable to handle MSO to correct. This > was tested on all edge types, mids, and single tier mids across all our CDNs. > The only differences were in header timestamps unless otherwise expected. > > Derek > > On 10/3/18, 2:14 PM, "Robert Butts" <[email protected]> wrote: > > Just out of curiosity, how difficult would it be to similarly support an > arbitrary number of tiers, by similarly checking if the parent _isn't_ an > origin and doing the reverse? (I'm aware of the hackish and perilous ways > TC can go edge-to-edge, I'm wondering about formalized and safe support.) > > On Wed, Oct 3, 2018 at 11:54 AM Steve Malenfant <[email protected]> > wrote: > > > I haven't tried but I'm +1 for this. > > > > On Wed, Oct 3, 2018 at 12:59 PM Gelinas, Derek > <[email protected]> > > wrote: > > > > > https://github.com/apache/trafficcontrol/pull/2904 > > > > > > On 10/3/18, 12:25 PM, "Dewayne Richardson" <[email protected]> wrote: > > > > > > Stating the obvious for posterity, but what is the PR link? > > > > > > > > > -Dew > > > > > > On Wed, Oct 3, 2018 at 8:47 AM Gelinas, Derek < > > > [email protected]> > > > wrote: > > > > > > > All, > > > > > > > > I’ve put a PR together to add support for single-layer CDNs. > > > Currently, > > > > edge and mid cache roles are basically hardwired into the code, > so > > > that > > > > when a parent.config file is generated, the rules for edges and > > mids > > > are > > > > always the same. This is fine if you are only using edges and > > mids, > > > but > > > > not so much if you’ve got edges only. MSO is completely > > unsupported > > > in a > > > > config like this, and the parent.config looks like an edge > config, > > > with > > > > each remap listed without parents. This is incorrect. > > > > > > > > What my PR does is actually very simple. Rather than look at > the > > > cache > > > > type at the various stages of the parent config generation, we > look > > > at the > > > > parent cachegroup types. If both parent cachegroups are either > ORG > > > type or > > > > unassigned, then $is_top_level is set to 1 (default is 0) and > the > > > variable > > > > is passed to the various subroutines that parent_dot_config > uses to > > > > generate data. These subroutines have been exclusive to > > > parent_dot_config > > > > since the scope change a while back, so this change does not > affect > > > any > > > > other subs. From there, all decisions about generating > > > configuration data > > > > are based on whether or not the cache is a top level cache. > > > > > > > > With this addition we will be able to properly generate parent > > > configs for > > > > edge-only CDNs, as well as support multisite. A PR is in place > > > marked as > > > > do not merge to allow review. I intend to add some > documentation > > > changes > > > > and do some heavy testing before I will pursue merging. > > > > > > > > Derek > > > > > > > > > > > > > > > > > > > > > > > > >
