I’m good with the proposed PR. Does this increase the likelihood that someone might get their server parameters wrong (remap_required, reverse_proxy_enabled) etc if we don’t have a server type match up with a profile type?
Should we consider removing the EDGE/MID server type entirely, replacing it with just “cache”? Also, not to get too off topic, but , we’ve got some code not yet open sourced (but willing to/eventually will publish) that will handle basic per-DS parent hierarchies. You can assign individual mids or create custom groups of mids, called device groups, to specific delivery services. Still only 2 tiers, but it lets us break free of the strict cache group tree. We could use this as a starting point when looking at the feature Rawlin mentions below. —Eric > On Oct 3, 2018, at 10:57 PM, Dave Neuman <[email protected]> wrote: > > +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 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>
