rob05c commented on a change in pull request #4790:
URL: https://github.com/apache/trafficcontrol/pull/4790#discussion_r451698114
##########
File path: lib/go-atscfg/atscfg.go
##########
@@ -134,3 +136,64 @@ const ConfigSuffix = ".config"
func GetConfigFile(prefix string, xmlId string) string {
return prefix + xmlId + ConfigSuffix
}
+
+// topologyIncludesServer returns whether the given topology includes the
given server
+func topologyIncludesServer(topology tc.Topology, server tc.Server) bool {
+ _, inTopology := serverTopologyTier(server, topology)
+ return inTopology
+}
+
+// serverTopologyTier returns whether the server is the last tier in the
topology, and whether the server is in the topology at all.
+func serverTopologyTier(server tc.Server, topology tc.Topology) (bool, bool) {
+ serverNode := tc.TopologyNode{}
+ for _, node := range topology.Nodes {
+ if node.Cachegroup == server.Cachegroup {
+ serverNode = node
+ break
+ }
+ }
+ if serverNode.Cachegroup == "" {
+ return false, false
+ }
+
+ return len(serverNode.Parents) == 0, true
Review comment:
So, it's been a few weeks, I'll have to verify, but I'm pretty sure the
rest of the Topology Config expects that.
I believe I wrote it expecting MSO Origins to be the "last tier," and
everything generates correctly. In terms of the remapping config, the last tier
is no different than an intermediary tier, and multiple MSO origins are set as
parents exactly the same way as multiple Mid parents.
That said, that may not work with the First/Middle/Last Header Rewrites. I'm
planning to start implementing those soon, so hopefully I'll verify then.
I seem to recall it being very clean and elegant how MSO Origins were
treated like any other server in the generation, I think it would be nice to
preserve that if possible.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
