>`yum install -y $(ort-pkg --upgrades)` I like that idea. Not convinced that's exactly the best way to do it. E.g. maybe outputting a file after a config run would be better? Or something.
But I'm definitely +1 on putting some thought it. My biggest concern, is that it still requires package info be in TO. Which is part of the goal, to get away from that. And specifically, it means having your package data in 2 places, TO and your server manager (Ansible/Puppet/etc). It would be ideal to avoid that. I'm afraid the only way might be something like a database of ATS features/plugins to versions; the complexity of that feels like it's getting out of hand. On Fri, Apr 10, 2020 at 3:38 PM Chris Lemmons <[email protected]> wrote: > I am +1 on most of this, though I have specific comments on > implementation details I'll add in a PR review where I can tag the > conversation to specific lines. > > But I do think that cache-specific packages might still make sense to > be controlled by a package manager. ORT is responsible for producing > config files for very specific versions of cache software and plugins; > it makes sense to me that it also be able to manage the versions of > that software and plugins. Likewise, cache-software upgrades have to > happen in concert with other config upgrades. Since they need to be > synchronous, it makes sense to have a single tool managing them. If > we're going to suggest that other system packaging tools handle cache > upgrades, we should at least think carefully about how we're going to > let systems know when it's safe to perform those upgrades. > > In the context of the Unix philosophy, I would expect to run a command > like `yum install -y $(ort-pkg --upgrades)` or `ort-pkg --upgrades | > xargs yum install -y` or maybe even something like `ort-pkg --upgrades > --yum-script | sh`. But ORT is the tool in the best position to tell > me what cache-related packages I need to make sure are installed. If a > given server is assigned a delivery service that requires a special > plugin, it would be really nice if ORT could ensure that the plugin > was present and of an adequate version. Otherwise, you have two > separate systems trying to keep the same information in sync. > > Another advantage of this approach is that ORT doesn't need elevated > privileges to install packages. And it's easy to swap in alternate OS > options: `emerge $(ort-pkg --upgrades)` or `ort-pkg --upgrades > --portage-script | sh` for example. > > On Thu, Apr 9, 2020 at 5:46 PM Jeremy Mitchell <[email protected]> > wrote: > > > > 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, > > > > > > > > > > > >
