This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:
Current behavior:
As of #6443, TM will no longer overwrite its monitoring.json snapshot data with corresponding CRConfig snapshot data if the monitoring.json contains IP addresses for the TMs, meaning it now has parity with the CRConfig data. However, it still needs the CRConfig in order to filter out delivery services from monitoring.json which aren't present in the CRConfig. That was fixed in #6443 in that the monitoring.json no longer contains delivery services from other CDNs to which the TM doesn't belong.
New behavior:
Once ATC 6.1 is released with the changes from #6443, we should be able to remove this fallback behavior from TM (and possibly its reliance on the CRConfig altogether) in the next major/minor release. That is because monitoring.json snapshots as of TO 6.1 will contain all the necessary data and will no longer need to rely on the CRConfig snapshot.
This Improvement request (usability, performance, tech debt, etc.) affects these Traffic Control components:
Current behavior:
As of #6443, TM will no longer overwrite its monitoring.json snapshot data with corresponding CRConfig snapshot data if the monitoring.json contains IP addresses for the TMs, meaning it now has parity with the CRConfig data. However, it still needs the CRConfig in order to filter out delivery services from monitoring.json which aren't present in the CRConfig. That was fixed in #6443 in that the monitoring.json no longer contains delivery services from other CDNs to which the TM doesn't belong.
New behavior:
Once ATC 6.1 is released with the changes from #6443, we should be able to remove this fallback behavior from TM (and possibly its reliance on the CRConfig altogether) in the next major/minor release. That is because monitoring.json snapshots as of TO 6.1 will contain all the necessary data and will no longer need to rely on the CRConfig snapshot.