This is probably a stupid question, but is there any reason we can't hit the DB from ORT, thus saving us the expense of writing any new scripting? My understanding is that the biggest hit on traffic ops isn't the DB so much as the perl processing for thousands of hosts at once. I assume that the DB requests themselves would fairly cacheable, no?
To be honest I'm still not convinced that it would be that hard to modify it to use json data instead sql queries. What I AM nervous about is someone rewriting all that code. It's pretty damn particular and there have been a few times where much more minor things have been rewritten that missed the point of certain results entirely and as such broke things. Derek > On Jul 30, 2019, at 6:22 PM, Robert Butts <[email protected]> wrote: > >> I'm confused why this is separate from ORT. > > Because ORT does a lot more than just fetching config files. Rewriting all > of ORT in Go would be considerably more work. Contrawise, if we were to put > the config generation in the ORT script itself, we would have to write it > all from scratch in Perl (the old config gen used the database directly, > it'd still have to be rewritten) or Python. This was just the easiest path > forward. > >> I feel like this logic should just be replacing the config fetching logic > of ORT > > That's exactly what it does: the PR changes ORT to call this app instead of > calling Traffic Ops over HTTP: > https://github.com/apache/trafficcontrol/pull/3762/files#diff-fe8a3eac71ee592a7170f2bdc7e65624R1485 > >> Is that the eventual plan? Or does our vision of the future include this > *and* ORT? > > I reserve the right to develop a strong opinion about that in the future. > > > On Tue, Jul 30, 2019 at 3:17 PM ocket8888 <[email protected]> wrote: > >>> "I'm just looking for consensus that this is the right approach." >> >> Umm... sort of. I think moving cache configuration to the cache itself >> is a great idea, >> >> but I'm confused why this is separate from ORT. Like if this is going to >> be generating the >> >> configs and it's already right there on the server, I feel like this >> logic should just be >> >> replacing the config fetching logic of ORT (and personally I think a >> neat place to try it >> >> out would be in ORT.py). >> >> >> Is that the eventual plan? Or does our vision of the future include this >> *and* ORT? >> >> >> On 7/30/19 2:15 PM, Robert Butts wrote: >>> Hi all! I've been working on moving the ATS config generation from >> Traffic >>> Ops to a standalone app alongside ORT, that queries the standard TO API >> to >>> generate its data. I just wanted to put it here, and get some feedback, >> to >>> make sure the community agrees this is the right direction. >>> >>> There's a (very) brief spec here: (I might put more detail into it later, >>> let me know if that's important to anyone) >>> >> https://cwiki.apache.org/confluence/display/TC/Cache-Side+Config+Generation >>> >>> And the Draft PR is here: >>> https://github.com/apache/trafficcontrol/pull/3762 >>> >>> This has a number of advantages: >>> 1. TO is a monolith, this moves a significant amount of logic out of it, >>> into a smaller per-cache app/library that's easier to test, validate, >>> rewrite, deploy, canary, rollback, etc. >>> 2. Deploying cache config changes is much smaller and safer. Instead of >>> having to deploy (and potentially roll back) TO, you can canary deploy on >>> one cache at a time. >>> 3. This makes TC more cache-agnostic. It moves cache config generation >>> logic out of TO, and into an independent app/library. The app (atstccfg) >> is >>> actually very similar to Grove's config generator (grovetccfg). This >> makes >>> it easier and more obvious how to write config generators for other >> proxies. >>> 4. By using the API and putting the generator functions in a library, >> this >>> really gives a lot more flexibility to put the config gen anywhere you >> want >>> without too much work. You could easily put it in an HTTP service, or >> even >>> put it back in TO via a Plugin. That's not something that's really >> possible >>> with the existing system, generating directly from the database. >>> >>> Right now, I'm just looking for consensus that this is the right >> approach. >>> Does the community agree this is the right direction? Are there concerns? >>> Would anyone like more details about anything in particular? >>> >>> Thanks, >>> >>
