You can now choose a Delivery Service's Routing Name (rather than a hardcoded "tr" or "edge" name). This might require a few pre-upgrade steps detailed here.
When enabled, delivery service requests are created when ALL users attempt to create, update or delete a delivery service. This allows users with higher level permissions to review delivery service changes for completeness and accuracy before deploying the changes. See here.
Using the FQ Pacing Rate parameter in Delivery Services allows operators to limit the rate of individual sessions to the edge cache. This feature requires a Trafficserver RPM containing the fq_pacing experimental plugin AND setting 'fq' as the default Linux qdisc in sysctl.
If the matched group in the CZF is not available, this list of backup edge cache group configured via Traffic Ops API can be used as backup. In the event of all backup edge cache groups not available, GEO location can be optionally used as further backup. APIs detailed here.
Apache Traffic Control 2.2.0 is available here:
It is essential that you verify the integrity of the downloaded files using the PGP or MD5 signatures.
The PGP signatures can be verified using PGP or GPG. First download the KEYS as well as the `ASC` signature file for the relevant distribution. Make sure you get these files from the main distribution directory, rather than from a mirror. Then verify the signatures using:
% pgpk -a KEYS % pgpv apache-trafficcontrol-2.0.0-incubating.tar.gz.ascor
% pgp -ka KEYS % pgp apache-trafficcontrol-2.0.0-incubating.tar.gz.ascor
% gpg --import KEYS % gpg --verify apache-trafficcontrol-2.0.0-incubating.tar.gz.asc apache-trafficcontrol-2.0.0-incubating.tar.gz
Additionally, you should verify the SHA signature on the files. A unix program called `sha` or `shasum` is included in many unix distributions. It is also available as part of GNU Textutils. An MD5 signature (deprecated) consists of 32 hex characters, and a SHA512 signature consists of 128 hex characters. Ensure your generated signature string matches the signature string published in the files above.
Selinux has to be something other than "enforcing" in order for the build to work, otherwise it fails on permissions errors. This can be accomplished by running setenforce 0 as root.
Traffic Stats works best with influxdb version < 1.3.x. As of 1.3.x InfluxDB now returns a 400 response when the client attempts to write points that are outside of the retention policy. When this happens, Traffic Stats seems to hold on to the "old" points and attempts to write them again on the next POST. This causes what is essentially a memory leak in Traffic Stats since it continues to hold onto and tries to write stats that are outside of the retention policy. This may or may not affect a user, depending upon which stats they are trying to write to influxdb. For example, we write the wrap_count to influxdb, this is a stat that does not often change within 24 hours, so we see the memory leak with stats not written on each poll of traffic stats.
In versions < 1.3.x InfluxDB would still not write the point, but it would accept the write request and just drop the points outside of the retention policy on the floor.
Apache Traffic Control 2.1.0 is available here:
Starting in Traffic Control 2.0.0, Postgres replaces MySQL as the Traffic Ops Database. The change in database server now provides a more friendly open source license for Traffic Control users.
To begin using Postgres, see traffic_ops_db/pg-migration/README.md for the MANDATORY migration steps. This upgrade must be performed using a Traffic Control 1.8.x database. If currently using a version of Traffic Control prior to 1.8.0, you must upgrade to 1.8.1 first before upgrading to 2.0.0.
Apache Traffic Control 2.0.0 is available here: