I have a feeling with the introduction of flexible topologies (in addition to or in place of our currently static topologies) - https://github.com/apache/trafficcontrol/pull/4537 - we might need to rethink how content invalidations (revalidations) work anyhow. Besides that, I'm +1 on an ORT rewrite if not for anything more than the ~2700 lines of perl - https://github.com/apache/trafficcontrol/blob/master/traffic_ops/ort/traffic_ops_ort.pl - are almost unmaintainable/inextensible.
Jeremy On Thu, Apr 9, 2020 at 5:16 PM Robert O Butts <[email protected]> wrote: > >If you remove reval then everything goes back to tiered updates again. > > Good point. I think we can make this smart enough to apply what it can > (everything but reval?) without waiting for parents. Definitely worth > putting on the to-do list. > > > On Thu, Apr 9, 2020 at 5:06 PM Derek Gelinas <[email protected]> wrote: > > > I’m +1 on all of these. Unsure about package control, though. I suspect > > that there are still some people using that one out in the world. > > > > I’ve never once heard of interactive mode being used, I like report mode > > but I’m fine as long as there’s an alternative. Agree about reval mode. > It > > was made to solve a very specific scaling issue. That said, it also > opened > > up caches to update configs free of having to wait for parents, so there > > could be some value to be had, there. If you remove reval then > everything > > goes back to tiered updates again. > > > > Derek > > > > > On Apr 9, 2020, at 6:57 PM, Robert O Butts <[email protected]> wrote: > > > > > > I've made a Blueprint proposing to rewrite ORT: > > > https://github.com/apache/trafficcontrol/pull/4628 > > > > > > If you have opinions on ORT, please read and provide feedback. > > > > > > In a nutshell, it's proposing to rewrite ORT in Go, in the "UNIX > > > Philosophy" of small, "do one thing" apps. > > > > > > Importantly, the proposal **removes** the following ORT features: > > > > > > chkconfig - CentOS 7+ and SystemD don't use chkconfig, and moreover our > > > default Profile runlevel is wrong and broken. But my knowledge of > > > CentOS,SystemD,chkconfig,runlevels isn't perfect, if I'm mistaken about > > > this and you're using ORT to set chkconfig, please let us know ASAP. > > > > > > ntpd - ORT today has code to set ntpd config and restart the ntpd > > service. > > > I have no idea why it was ever in charge of this, but this clearly > seems > > to > > > be the system's job, not ORT or TC's. > > > > > > interactive mode - I asked around, and couldn't find anyone using this. > > > Does anyone use it? And feel it's essential to keep in ORT? And also > feel > > > that the way this proposal breaks up the app so that it's easy to > request > > > and compare files before applying them isn't sufficient? > > > > > > reval mode - This was put in because ORT was slow. ORT in master now > > takes > > > 10-20s on our large CDN. Moreover, "reval" mode is no longer > > significantly > > > faster than just applying everything. Does anyone feel otherwise? > > > > > > report mode - The functionality here is valuable. But intention here is > > to > > > replace "ORT report mode" with a pipelined set of app calls or a script > > to > > > do the same thing. I.e. because it's "UNIX-Style" you can just > > "ort-to-get > > > | ort-make-configs | ort-diff". > > > > > > package installation - This is the biggest feature the proposal > removes, > > > and probably the most controversial. The thought is: this isn't > something > > > ORT or Traffic Control should be doing. The same thing that manages the > > > physical machine and/or operating system -- whether that's Ansible, > > Puppet, > > > Chef, or a human System Administrator -- should be installing the OS > > > packages for ATS and its plugins, just like it manages all the other > > > packages on your system. ORT and TC should deploy configuration, not > > > install things. > > > > > > So yeah, feedback welcome. Feel free to post it on the list here or the > > > blueprint PR on github. > > > > > > Thanks, > > > > >
