>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, > >
