Posting from another thread for better organization: On Tue, Jun 7, 2022 at 10:06 AM Gray, Jonathan <[email protected]> wrote:
> The data kindof exists. Servers have Physlocations which have addresses > of some kind. Their purpose is presently ambiguous as to if that should be > used for physical address or mailing address. Clearing that ambiguity and > adding lat/long are nice to haves, but that’s really a TO enhancement > rather than a TP one. Additionally those physlocation lat/longs wouldn’t > presently used in a meaningful way since all routing decisions are based on > the cachegroup. There are reasons that a cachegroup location might be > skewed away from the physlocation or serve as an area aggregate. Today you > can suboptimally equate physlocation and cachegroup for routing/capacity > purposes if desired, but that gets pretty far into micromanagement and > capacity issues. Analytics I’ve done in the past that were useful were to > create convex hull polygons of the physlocations associated to a cachegroup > and check that the areas were reasonable for the tiers as well as to ensure > the cachegroup lat/long was contained within it or nearby to where it made > sense. That’s shown in the past where we’ve had physlocations set wrong on > hosts due to ambiguous physlocation names. Although that didn’t affect > routing just RMA work. > > Better visualization around parentage in general would be a definite win. > Given how we’ve gone from a 1 or 2 tier CDN model with secondary parents > and MSO to an N-tier model with additional dimensions of permutations > around topologies as well as capabilities/requirements, as an SRE it’s much > more difficult to know how traffic ideally should be flowing for diagnostic > purposes. That view doesn’t have to be geographic in nature though. A > graph/tree would suffice. From a perspective of self-service though, all > the topic around parentage is generally too complex for a non-ATC engineer > and too powerful. Better visualization around parentage I think benefits > both user groups. > > Jonathan G > > > From: Dave Neuman <[email protected]> > Date: Tuesday, June 7, 2022 at 9:30 AM > To: [email protected] <[email protected]> > Subject: [EXTERNAL] Re: 2022-06-07 TC Working Group Agenda and Meeting > Notes > >> - Zach proposes/iss working on a geographic Topology builder using > Cache Group latitude/longitude to map them out > > I would suggest incorporating the physical locations of the hosts as well. > Maybe as a drill down? Cache groups can be as big as a whole country, > having the actual locations of the caches could be much more helpful. > > Just my $.02 > > --Dave > -Zach On Mon, Jun 6, 2022 at 9:15 AM Wilson, Amy <[email protected]> wrote: > To add some additional color, a new delivery service self-service feature > really means is 2 things: > > * simplified view for non-super/advanced users > * eliminate the need to queue [server] updates / CDN snapshot to > propagate changes - https://github.com/apache/trafficcontrol/issues/6183 > > ~Amy > > From: Wilson, Amy <[email protected]> > Date: Wednesday, June 1, 2022 at 4:04 PM > To: [email protected] <[email protected]> > Subject: Call for Traffic Portal Enhancements / New Features > Good afternoon, > > I hope this email finds everyone doing well. > > Looking to gather enhancements or new features for Traffic Portal. > Specifically, around User Management, Tenancy, and Delivery Services > management. > > Please provide your detailed ideas/requirements. > > Thanks, > ~Amy >
