rob05c edited a comment on issue #4534: Fix ORT atstccfg to allow using new features in the latest Traffic Ops URL: https://github.com/apache/trafficcontrol/pull/4534#issuecomment-603486576 >This seems more like a backwards-compatibility issue than a coupling issue. I think it's both. >if a client is coupled to two versions of the same API, doesn't that make it even more tightly coupled to that API? I guess everyone's definition is different, but that's not what I mean when I say "tightly-coupled." One of the benefits of an API is that you're "coupled" to the interface rather than the app itself. It seems inevitable that you have to communicate with some interface. >better backwards compatibility with TO at the cost of tighter coupling and increased complexity of components. The point of TC components supporting a version back isn't backward compatibility per-se, but rather the ability to deploy and roll back in any order, which gives us safety around deployment. It allows deployments of production components to be isolated around a single component of the system, rather than the full system all-or-nothing. Getting 100,000 lines of code to work as a single, perfect, cohesive unit is way more difficult and error-prone, than getting ten 10,000-line apps to each independently work. >If we need to fully roll back TO after we've already upgraded most of the other components in the chain, wouldn't we be risking more serious data loss if we rolled back TO at that point rather than hotfixing it and rolling forwards? It depends on the situation. It's possible. It's also possible that a hotfix will be more dangerous, or take longer, or disrupt other systems, where a quick rollback of say ORT, or TM, would be faster and safer, and fix a broken production system in minutes instead of hours or days. Or suppose it's a bug in TR, which requests TM, which requests TO. What if there's a bug in TM? Now you have to roll back TR, then TM, then TO. And maybe it's possible to hotpach TM. But maybe it's not, maybe it's a large, complex feature or code refactor and the only quick solution is to roll back. Now TR, TM, and TO all have to be rolled back, in order, and re-deployed, in order. Where if TM and TR support the prior version, TM can safely and quickly be rolled back. That's why our components need to be decoupled. Not from the TO API, but from each-other, and from specific binaries. You're right, there are scenarios where it doesn't matter. But there are also a great many failure scenarios where it does, and it means the difference in minutes versus hours of outage time. Letting TC users upgrade in any order can also be safer. In theory, TC shouldn't have bugs. But in the past, it often has, and upgrading certain components first can be safer and less likely to bring the CDN down. >this seems like something that should be well-communicated with the entire project for everyone to get on board with We did, but I guess that was before you came on to the project. We didn't used to do extensive documentation for these things, we just kind of agreed and then did it. We can certainly bring it up again. I don't agree with removing the decoupling, but I do agree that these things shouldn't be set in stone. If you feel strongly that we should, you can always bring it up on the list and we can discuss it as a community again.
---------------------------------------------------------------- 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: us...@infra.apache.org With regards, Apache Git Services
