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,
