rob05c opened a new issue #5001: URL: https://github.com/apache/trafficcontrol/issues/5001
https://github.com/apache/trafficcontrol/commit/f2a6b5ba360f181450bc85a1c7a5d58832361037#diff-19d5dde3706497c19da9a59a2ccb15c5R165 ``` type Stats struct { srvhttp.CommonAPIData - Caches map[tc.CacheName]map[string][]ResultStatVal `json:"caches"` + Caches map[tc.CacheName]map[string]map[string][]ResultStatVal `json:"caches"` } ``` This struct is used in the Monitor API, `/publish/CacheStats`, which is used by clients, including Traffic Ops `/deliveryservices/{{id}}/capacity`, and possibly Traffic Router. ``` ERROR: api.go:209: 2020-09-01T17:08:30.9960088Z: 172.18.0.1:54310 getting delivery service capacity: getting CacheStats for delivery service 'my-ds' monitor 'my-monitor.my-cdn.example.net:80': decoding CacheStats from monitor 'my-monitor.my-cdn.example.net:80': json: cannot unmarshal array into Go struct field Stats.caches of type map[string][]cache.ResultStatVal ``` This makes it impossible to upgrade. Whether you upgrade TM or other things first, you break the others. But as a project, ATC supports upgrading in any order. I see several solutions: 1. We could start versioning the Monitor API 2. we could make a new endpoint, and change things that need the new endpoint (TO. TR? Other clients) to call the new, and fall back to the old 3. We could fix all clients to try decoding both. But then we'd have to release that, before making another major release with Multi-Interface I don't have a strong opinion. Though I would vote for 2. 3 is pretty limiting and expensive, in terms of our release schedule. 1 is pretty expensive long-term for development. The Monitor API changes so infrequently, we've never felt the need before. To me at least, 2 seems like the easiest solution. ## I'm submitting a ... - bug report ## Traffic Control components affected ... - Traffic Monitor ## Current behavior: Monitor API has changed, breaking existing clients (TO, possibly TR or other clients). ## Expected / new behavior: Monitor API from previous version still exists, so it's possible to upgrade the Monitor before other components. Other components also need to fall back to the existing endpoint, so they can be upgraded before the Monitor. ## Minimal reproduction of the problem with instructions: ## Anything else: <!-- e.g. stacktraces, related issues, suggestions how to fix --> <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> ---------------------------------------------------------------- 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]
