+1 on this PR. Long overdue in my opinion. On Wed, Oct 3, 2018 at 14:50 Rawlin Peters <[email protected]> wrote:
> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
