ocket8888 commented on code in PR #7291:
URL: https://github.com/apache/trafficcontrol/pull/7291#discussion_r1088357174
##########
traffic_ops/traffic_ops_golang/monitoring/monitoring.go:
##########
@@ -188,7 +188,7 @@ SELECT
status.name as status,
cachegroup.name as cachegroup,
me.tcp_port as port,
- profile.name as profile,
+ (SELECT STRING_AGG(sp.profile_name, '+' ORDER by sp.priority ASC) FROM
server_profile AS sp where sp.server=me.id group by sp.server) as profile,
Review Comment:
I don't know that just making TM understand profile layering would result in
any more duplication than copying different arrangements of profiles into their
own pseudo profiles. It seems like the two best options are
1. Calculate the needed Parameters for each cache server in TO and store
them on a per-cache basis without making TM look up the name of the Profile to
find the Parameters. This follows the pattern of making the configuration
simple for TM to understand and not requiring it to build out relations through
extrapolation. However, it probably makes monitoring configurations much bigger.
2. Tell TM what Profiles each server has and what Parameters belong to the
relevant Profiles. This is in keeping with how things work today, just makes it
a little more work to figure out a cache server's Parameters. I think the extra
time this would take is probably negligible for any reasonable use-case. It
would also cut down on duplication.
Personally I think option 2 makes the most sense, but in either case it'll
require TM changes. At any rate, this "+" stuff won't work because if I have
the profiles "a", "b", "c", "a+b", and "b+c", it will be literally impossible
to tell what the entry "a+b+c" means in the monitoring payload. More to the
point, keys must also be unique, so any time you have a profile with a name
that can be constructed through "+" concatenation of any number of other
profile names, you wind up with a silently broken configuration.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
