2022-10-04 TC Working Group Agenda and Meeting Notes
If you have anything you want to discuss at next week's meeting respond to this email and it's on the agenda.
Re: 2022-09-27 TC Working Group Agenda and Meeting Notes
Attendance: - Zach Hoffman - Srijeet Chatterjee - Joshua Zenn - Eric Holguin - Taylor Frey Notes: - Nothing presented to discuss this week. On Wed, Sep 21, 2022 at 10:18 AM ocket wrote: > If you have anything you want to discuss at next week's meeting > respond to this email and it's on the agenda. >
Re: 2022-07-26 TC Working Group Agenda and Meeting Notes
Continue to discuss High Impact labeled issues On Tue, Jul 19, 2022 at 10:22 AM ocket wrote: > If you have anything you want to discuss at next week's meeting > respond to this email and it's on the agenda. >
2022-02-22 TC Working Group Agenda and Meeting Notes
If you have anything you want to discuss at next week's meeting, respond to this email and it's on the agenda.
Re: 2022-02-15 TC Working Group Agenda and Meeting Notes
1. Attendance: Srijeet Chatterjee Eric Holguin Steve Hamrick Taylor Frey Justin Howard 2. Official Release: - TC 7.0.0 - Officially remove TO 2.x / Riak - Ansible currently uses 2, needs to finalize upgrade to 3 w/ testing - TO API 4.x will remain unstable for this release given the 'in development' progress of a few items On Tue, Feb 8, 2022 at 10:18 AM ocket wrote: > If you have anything you want to discuss at next week's meeting, > respond to this email and it's on the agenda. >
Re: 2022-01-04 TC Working Group Agenda and Meeting Notes
Automatic log rotation as a default setting in Log4J for TR On Tue, Jan 4, 2022 at 9:18 AM Jeremy Mitchell wrote: > as a new quarter is upon us, is it time to consider getting 6.1 ready? > > On Tue, Dec 14, 2021 at 10:23 AM ocket wrote: > > > If you have anything you want to discuss at next week's meeting, > > respond to this email and it's on the agenda. > > >
Re: [VOTE] Release Apache Traffic Control 5.1.5-RC0
+1 All builds with .pkg. Verified checksum. On Tue, Dec 21, 2021 at 11:17 AM Stephen Hamrick wrote: > +1 > > On Tue, Dec 21, 2021, 10:53 Zach Hoffman wrote: > > > +1 > > Tested Traffic Router with the backports, it works as expected. > > > > -Zach > > > > On Tue, Dec 21, 2021 at 10:49 AM Rawlin Peters > wrote: > > > > > > +1 > > > > > > On Tue, Dec 21, 2021 at 9:14 AM Jeremy Mitchell > > > wrote: > > > > > > > > +1 > > > > > > > > On Mon, Dec 20, 2021 at 2:47 PM ocket > > wrote: > > > > > > > > > And actually the 23rd is a Thursday. > > > > > > > >
Re: [EXTERNAL] Re: [VOTE] Release Apache Traffic Control 6.0.2-RC2
+1 All builds with .pkg. Verified checksums. On Tue, Dec 21, 2021 at 11:18 AM Chatterjee, Srijeet wrote: > +1 > > --Srijeet > > On 12/21/21, 10:54 AM, "Zach Hoffman" wrote: > > +1 > > On Tue, Dec 21, 2021 at 10:51 AM Rawlin Peters > wrote: > > > > +1 > > > > On Tue, Dec 21, 2021 at 9:15 AM Eric Friedrich > wrote: > > > > > > +1 > > > Verified signatures, hashes and that I can build via pkg > > > > > > On Tue, Dec 21, 2021 at 11:14 AM Jeremy Mitchell < > mitchell...@gmail.com> wrote: > > > > > > > > +1 > > > > > > > > On Mon, Dec 20, 2021 at 2:48 PM ocket > wrote: > > > > > > > > > Note that the 23rd is a Thursday > > > > > > > > > > On Mon, Dec 20, 2021 at 11:33 AM Zach Hoffman < > zrhoff...@apache.org> > > > > > wrote: > > > > > > > > > > > > I've prepared a release for 6.0.2-RC2. Changes since > RELEASE-6.0.1: > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/compare/RELEASE-6.0.1...RELEASE-6.0.2-RC2__;!!CQl3mcHX2A!TJLP9rfe8CyyaMd4Iy8iBN7bhnqTGBo87mY2YMW7ijpG3HAUc3Al0jTtFAEDQ5sVIZ35ziq2$ > > > > > > > > > > > > https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/blob/RELEASE-6.0.2-RC2/CHANGELOG.md__;!!CQl3mcHX2A!TJLP9rfe8CyyaMd4Iy8iBN7bhnqTGBo87mY2YMW7ijpG3HAUc3Al0jTtFAEDQ5sVISApxEeu$ > > > > > > > > > > > > The artifacts are available for download at: > > > > > > > > > > > > > https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/trafficcontrol/6.0.2/RC2/__;!!CQl3mcHX2A!TJLP9rfe8CyyaMd4Iy8iBN7bhnqTGBo87mY2YMW7ijpG3HAUc3Al0jTtFAEDQ5sVIbUlwchv$ > > > > > > > > > > > > BLAKE2 checksum: > > > > > > > > > > > > 80cbac152f2dd37f5f874bafc5ce1d9c554ad78ce64e31fbb341db489ca22b4e5fe01e9dd35faaf9a2809f6636c6bac668963a142a71043535a0efd479ef > > > > > > apache-trafficcontrol-6.0.2.tar.gz > > > > > > > > > > > > SHA512 checksum: > > > > > > > > > > > > de0abe5670f0a8a80ab12c73688f9a111794190d208d3190b6961934c0499ddb398f7fc45cd99d330c9f807e80c8a22cec385dbd60dd6498cc7b44831794452a > > > > > > apache-trafficcontrol-6.0.2.tar.gz > > > > > > > > > > > > This corresponds to git refs: > > > > > > > > > > > > Hash: d33bf4189911f8631d0583b28c9e70151ca82535 > > > > > > Tag: RELEASE-6.0.2-RC2 > > > > > > > > > > > > Which can be verified with the following command: > > > > > > > > > > > > $ git tag -v RELEASE-6.0.2-RC2 > > > > > > > > > > > > All code signing keys are available here: > > > > > > > > > > > > > https://urldefense.com/v3/__https://dist.apache.org/repos/dist/release/trafficcontrol/KEYS__;!!CQl3mcHX2A!TJLP9rfe8CyyaMd4Iy8iBN7bhnqTGBo87mY2YMW7ijpG3HAUc3Al0jTtFAEDQ5sVIYEP4h6B$ > > > > > > > > > > > > Make sure you refresh from a key server to get all relevant > signatures. > > > > > > > > > > > > The vote is open until 19:00 UTC on Wednesday, December 23 > and passes > > > > > > if a majority of at least 3 +1 PMC votes are cast. > > > > > > [ ] +1 approve > > > > > > [ ] +0 no opinion > > > > > > [ ] -1 disapprove (and reason why) > > > > > > > > > > > > -Zach > > > > > > >
Re: [VOTE] Release Apache Traffic Control 6.0.1-RC0
+1
On Fri, Nov 5, 2021 at 11:45 AM Rawlin Peters wrote:
> +1
>
> On Fri, Nov 5, 2021 at 11:43 AM Jeremy Mitchell
> wrote:
> >
> > +1
> >
> > On Fri, Nov 5, 2021 at 11:31 AM Zach Hoffman
> wrote:
> >
> > > I've prepared a release for 6.0.1-RC0. Changes since RELEASE-6.0.0:
> > >
> > >
> > >
> https://github.com/apache/trafficcontrol/compare/RELEASE-6.0.0...RELEASE-6.0.1-RC0
> > >
> > >
> https://github.com/apache/trafficcontrol/blob/RELEASE-6.0.1-RC0/CHANGELOG.md
> > >
> > > The artifacts are available for download at:
> > >
> > >
> https://dist.apache.org/repos/dist/dev/trafficcontrol/6.0.1/RC0/
> > >
> > > BLAKE2 checksum:
> > >
> c1cf6ee38b4071fc2b403dc3dcbad7dc6a9a93cb98d6f35accd1fd64f4c6db3657b0f5db9766708c7f71659ef0f796eedcd6ac7eafac2f1aa56b477ff7a76aa5
> > > apache-trafficcontrol-6.0.1.tar.gz
> > >
> > > SHA512 checksum:
> > >
> d51c2e34aaafc77ecb5af21c464a118a660846f9f8ea5d64b014142e61af165bda4319251294cf1e8121d0a27175567753aa6410d5f10c81a84381af343f9d0d
> > > apache-trafficcontrol-6.0.1.tar.gz
> > >
> > > This corresponds to git refs:
> > >
> > > Hash: 1ed2964d16618aeebef142b01a538336a44d07dd
> > > Tag: RELEASE-6.0.1-RC0
> > >
> > > Which can be verified with the following command:
> > >
> > > $ git tag -v RELEASE-6.0.1-RC0
> > >
> > > All code signing keys are available here:
> > >
> > > https://dist.apache.org/repos/dist/release/trafficcontrol/KEYS
> > >
> > > Make sure you refresh from a key server to get all relevant signatures.
> > >
> > > Please test and cast your votes as early as possible. The vote is open
> > > until 22:00 UTC on Monday, November 8.
> > > [ ] +1 approve
> > > [ ] +0 no opinion
> > > [ ] -1 disapprove (and reason why)
> > >
> > > -Zach
> > >
> > > --
> > >
> > > Changelog for 6.0.1-RC0:
> > >
> > > Added
> > > #2770 Added validation for httpBypassFqdn as hostname in
> Traffic
> > > Ops
> > >
> > > Fixed
> > > #6125 - Fix /cdns/{name}/federations?id=# to search for CDN.
> > > #6283 - The Traffic Ops Postinstall script will work in CentOS
> 7,
> > > even if Python 3 is installed
> > > #5373 - Traffic Monitor logs not consistent
> > > #6197 - TO /deliveryservices/:id/routing makes requests to all
> TRs
> > > instead of by CDN.
> > > Traffic Ops: Sanitize username before executing LDAP query
> > >
> > > Changed
> > > #5927 Updated CDN-in-a-Box to not run a Riak container by
> default
> > > but instead only run it if the optional flag is provided.
> > > Changed the DNSSEC refresh Traffic Ops API to only create a new
> > > change log entry if any keys were actually refreshed or an error
> occurred
> > > (in order to reduce changelog noise)
> > >
> > >
>
Re: [VOTE] Release Apache Traffic Control 5.1.4-RC0
+1 On Fri, Nov 5, 2021 at 12:14 PM Steve Hamrick wrote: > +1 > > On 11/5/21 11:42, ocket wrote: > > Just reminded by our 6.x RM that the gnupg.net link I sent doesn't work > > anymore, from now on the signing keys can be found in > > https://dist.apache.org/repos/dist/release/trafficcontrol/KEYS > > > > On Fri, Nov 5, 2021 at 11:32 AM Zach Hoffman > wrote: > > > >> +1 > >> > >> On Fri, Nov 5, 2021 at 11:31 AM Rawlin Peters > wrote: > >>> +1 > >>> > >>> - Rawlin > >>> > >>> On Fri, Nov 5, 2021 at 11:13 AM ocket > wrote: > Hello All, > > I've prepared a release for v5.1.4-RC0 > > The vote is open for at least 72 hours and passes if a majority of at > least 3 +1 PMC votes are cast. > > [ ] +1 Approve the release > > [ ] -1 Do not release this package because ... > > Changes since 5.1.3 > >> > https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.3...RELEASE-5.1.4-RC0 > This corresponds to git:Hash: > 5a68d18cd0c07df8ba36c30084cb13d47e771d46Tag: RELEASE-5.1.4-RC0 > > Which can be verified with the following: git tag -v RELEASE-5.1.4-RC0 > > My code signing key is available > here: > >> > https://keys.gnupg.net/pks/lookup?search=0xF5D560A373B76FA302A95DBFCDFE430685982C95=on=index > Make sure you refresh from a key server to get all relevant > signatures. > > The source .tgz file, pgp signature (.asc signed with my key from > above), and sha512 checksums are provided here: > https://dist.apache.org/repos/dist/dev/trafficcontrol/5.1.4/RC0 > > > Thanks! > ocket ocket8...@gmail.com >
Re: [PROPOSAL] ATC Release Schedule
I mentioned this on the WG call this morning, but I thought I'd add my thoughts in response to this mailing list item since there may have been some confusion with my explanation. First, I think delivering on a time-based schedule is grand. I think cutting a release once a month might be an aggressive goal, but once we get in a rhythm I believe it will become easier. Choosing a version number is an arbitrary decision. But since we appear to be following Semantic Versioning (https://semver.org/) for our numbering scheme then I believe it's best to follow those practices for choosing the next version number. Thusly, the version number will "choose itself" based on the SemVer tenants. Given the schedule, this *might* result in something like: 11/1/21: 6.0.1 - PATCH - Only bug fixes, performance changes, tooling 12/1/21: 6.1.0 - MINOR - New feature (Refetch), optionally contains PATCH items 1/1/22: 6.1.1 - PATCH - Only bug fixes, performance changes, tooling 2/1/22: 6.1.2 - PATCH - Only bug fixes, performance changes, tooling 3/1/22: 6.2.0 - MINOR - New feature (Roles/Permissions), optionally contains PATCH items 4/1/22: 7.0.0 - MAJOR - "Breaking" backwards compatibility promise. Removal of an API version or endpoint, forced changes to clients reliant on an API (like switching from Cookies to Token/Auth on all API versions) 5/1/22: 7.0.1 - PATCH - Only bug fixes, performance changes, tooling ... There are a plethora of choices in versioning. One alternative we may all be familiar with is sometimes called CalVer. Ubuntu's scheduled releases follow this scheme so their versioning represents it as a date 21.04 or 21.10. We could do something similar. The MAJOR version could still be similar to SemVer, but without the restrictions allowing us to increment once a MAJOR change has happened (Removal of PERL, for past example). The versioning scheme and schedule could then resemble: 11/1/21: 6.21.11 - November, 2021 12/1/21: 6.21.12 - December, 2021 1/1/22: 6.22.01 - January, 2022 2/1/22: 6.22.02 - February, 2022 3/1/22: 6.22.03 - March, 2022 4/1/22: 7.0.0 - MAJOR - Arbitrary 5/1/22: 7.22.05 - May, 2022 ... Windows, MacOS pick MAJOR versions in seemingly arbitrary fashion. I recall Linux choosing their MAJOR versions based on numbers of commits to the repository. I'm certainly welcome to whatever scheme we want to implement moving forward, but if we are going to deviate from SemVer's practices then I think it should be explicit. T On Tue, Oct 26, 2021 at 11:58 AM Zach Hoffman wrote: > Seeing 2 differences: > • Aiming for a minor release every quarter instead of what we aspired > to previously, new major release every quarter > • Aiming for a patch release every month at the start of the month > > Makes sense to me, +1. > > > -Zach > > On Tue, Oct 26, 2021 at 11:44 AM Jeremy Mitchell > wrote: > > > > Resending to make sure it's clear this is simply a proposal. Please > provide > > feedback. > > > > In the past, ATC has targeted quarterly official releases but we've > failed > > on many occasions due to "holding the bus" for certain features or slow > > release voting. In the 10/26/2021 TC working group, we discussed that we > > should stick to this schedule regardless of feature readiness. (remember > if > > you want a certain feature that was merged post-release, you can always > > pull from the master branch as we are all in agreement that master must > > ALWAYS be releasable). > > > > Here is the schedule that was proposed: > > > >- Quarterly minor releases (unless a Major is warranted and will be > >determined on case-by-case basis) > >- Monthly patch releases > > > > Example: > > > > 11/1/21: 6.0.1 > > 12/1/21: 6.0.2 > > 1/1/22: 6.1.0 > > 2/1/22: 6.1.1 > > 3/1/22: 6.1.2 > > 4/1/22: 6.2.0 > > 5/1/22: 6.2.1 > > 6/1/22: 6.2.2 > > 7/1/22: 6.3.0 > > 8/1/22: 6.3.1 > > 9/1/22: 6.3.2 > > 10/1/22: 7.0.0 <-- Apparently something "big" or non backwards compatible > > got merged (i.e. API version removal) > > 11/1/22: 7.0.1 > > 12/1/22: 7.0.2 > > > > Please provide feedback on this approach. > > > > Thanks, > > > > Jeremy >
Re: [VOTE] Release Apache Traffic Control 5.1.3-RC0
+1
On Thu, Oct 7, 2021 at 3:28 PM Steve Malenfant wrote:
> +1
>
> On Tue, Oct 5, 2021 at 9:29 PM Jeremy Mitchell
> wrote:
>
> > +1
> >
> > On Tue, Oct 5, 2021 at 7:00 PM Eric Friedrich wrote:
> >
> > > +1
> > >
> > > On Tue, Oct 5, 2021 at 7:29 PM Zach Hoffman
> > wrote:
> > >
> > > > +1
> > > >
> > > > On Tue, Oct 5, 2021 at 5:28 PM Dave Neuman
> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Tue, Oct 5, 2021 at 16:40 ocket
> wrote:
> > > > >
> > > > > > Hello All,
> > > > > >
> > > > > > I've prepared a release for v{{version}}-RC{{RC Number}}
> > > > > >
> > > > > > The vote is open for at least 72 hours and passes if a majority
> of
> > at
> > > > > least
> > > > > > 3 +1 PMC votes are cast.
> > > > > >
> > > > > > [ ] +1 Approve the release
> > > > > >
> > > > > > [ ] -1 Do not release this package because ...
> > > > > >
> > > > > > Changes since 5.1.2
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/trafficcontrol/compare/v5.1.2...RELEASE-5.1.3-RC0
> > > > > >
> > > > > > This corresponds to git:
> > > > > > Hash: a52ae6cda73ef477aec691b0d27701326d20e025
> > > > > > Tag: RELEASE-5.1.3-RC0
> > > > > >
> > > > > > Which can be verified with the following: git tag -v
> > > RELEASE-5.1.3-RC0
> > > > > >
> > > > > > My code signing key is available here:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://keys.gnupg.net/pks/lookup?search=0xF5D560A373B76FA302A95DBFCDFE430685982C95=on=index
> > > > > >
> > > > > > Make sure you refresh from a key server to get all relevant
> > > signatures.
> > > > > >
> > > > > > The source .tgz file, pgp signature (.asc signed with my key from
> > > > > > above), and sha512 checksums are provided here:
> > > > > >
> > > > > > https://dist.apache.org/repos/dist/dev/trafficcontrol/5.1.3/RC0
> > > > > >
> > > > > >
> > > > > > Thanks!
> > > > > > ocket ocket8...@apache.org
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: new committer: Steve Hamrick
That's fantastic! Congratulations! On Tue, Sep 7, 2021 at 11:23 AM Rawlin Peters wrote: > Congrats, Steve! > > - Rawlin > > On Tue, Sep 7, 2021 at 11:19 AM ocket wrote: > > > > The Project Management Committee (PMC) for Apache Traffic Control > > has invited Steve Hamrick to become a committer and we are pleased > > to announce that he has accepted. > > > > Being a committer enables easier contribution to the > > project since there is no need to go via the patch > > submission process. This should enable better productivity. >
Re: [EXTERNAL] Re: Deprecate APIv2 and v3
I, too, +1 deprecation notices for both 2.x and 3.x for Traffic Ops API in ATC 6.+ On Tue, Aug 3, 2021 at 1:18 PM ocket wrote: > I think we can probably just do one for both, assuming the vote for v3 sees > no "-1"s. > > On Tue, Aug 3, 2021 at 12:08 PM Jeremy Mitchell > wrote: > > > +1 for deprecation notices added to 2.x and 3.x in TC 6.x. <-- 2 github > > issues for that? > > > > On Tue, Aug 3, 2021 at 11:17 AM Rawlin Peters wrote: > > > > > +1 > > > > > > - Rawlin > > > > > > On Tue, Aug 3, 2021 at 11:01 AM Zach Hoffman > > wrote: > > > > > > > > > I'd like to call for a final vote on > > > > > whether or not to deprecate APIv3, so that if we do we can get it > > into > > > the > > > > > docs and changelog by the 16th when the release is currently set to > > be > > > > cut. > > > > > > > > +1 > > > > > > > > On Tue, Aug 3, 2021 at 10:59 AM ocket > > wrote: > > > > > > > > > Removal is definitely not on the table until at least ATCv7 > > > > > > > > > > On Tue, Aug 3, 2021 at 10:56 AM Gray, Jonathan > > > > > wrote: > > > > > > > > > > > Be aware that the ansible deployment code is dependent on v2 for > > the > > > > > > moment until it’s updated again. Deprecation is fine, but if > it’s > > > > > removed > > > > > > we’ll be in the same boat we were in when 1.x got removed. > > > > > > > > > > > > Jonathan G > > > > > > > > > > > > From: ocket > > > > > > Date: Tuesday, August 3, 2021 at 10:53 AM > > > > > > To: dev@trafficcontrol.apache.org > > > > > > > Subject: Re: [EXTERNAL] Re: Deprecate APIv2 and v3 > > > > > > Alright, it seems like nobody is opposed to deprecating APIv2 > > (please > > > > > > correct me if that's wrong), so assuming that's the case to be > > > perfectly > > > > > > clear on what everyone wants to do, I'd like to call for a final > > > vote on > > > > > > whether or not to deprecate APIv3, so that if we do we can get it > > > into > > > > > the > > > > > > docs and changelog by the 16th when the release is currently set > to > > > be > > > > > cut. > > > > > > > > > > > > I'm +1 on my own proposal, unsurprisingly. > > > > > > > > > > > > On Wed, Jul 28, 2021 at 11:28 AM ocket > > > > wrote: > > > > > > > > > > > > > I don't disagree with any of that. > > > > > > > > > > > > > > On Wed, Jul 28, 2021 at 9:01 AM Gray, Jonathan > > > > > > > wrote: > > > > > > > > > > > > > >> > so that APIv3 doesn't become the next entrenched version to > be > > > > > > >> hard-coded into a plethora of obscure scripts so that it takes > > > over a > > > > > > year > > > > > > >> to switch. > > > > > > >> > > > > > > >> Those scripts are just as important as the ATC project itself > > > when it > > > > > > >> comes to production operations. API version churn is > expensive > > > and > > > > > > it’s a > > > > > > >> symbiotic relationship. OSS projects that maintain backward > > > > > > compatibility > > > > > > >> are easier to work with and attain greater adoption. It’s > just > > > > > another > > > > > > >> facet of encouraging adoption just like good PR processes and > > > tests. > > > > > > >> > > > > > > >> Jonathan G > > > > > > >> > > > > > > >> From: ocket > > > > > > >> Date: Tuesday, July 27, 2021 at 5:55 PM > > > > > > >> To: dev@trafficcontrol.apache.org < > > dev@trafficcontrol.apache.org> > > > > > > >> Subject: Re: [EXTERNAL] Re: Deprecate APIv2 and v3 > > > > > > >> I have a link to the mailing list discussion: > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://lists.apache.org/thread.html/b857afc7b52e72b2e60ebb3eb594b6fa5dd0ed3c9af5a17b58ee4a99*40*3Cdev.trafficcontrol.apache.org*3E__;JSUl!!CQl3mcHX2A!Q_lvH7GunLsRSIigt4CHJwosp0fih_-ArK7UVI4Z2cr5_J00BL2ZxgbYrYcu9fPda49a$ > > > > > > < > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https:/lists.apache.org/thread.html/b857afc7b52e72b2e60ebb3eb594b6fa5dd0ed3c9af5a17b58ee4a99*40*3Cdev.trafficcontrol.apache.org*3E__;JSUl!!CQl3mcHX2A!Q_lvH7GunLsRSIigt4CHJwosp0fih_-ArK7UVI4Z2cr5_J00BL2ZxgbYrYcu9fPda49a$ > > > > > > > > > > > > > >> < > > > > > > >> > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https:/lists.apache.org/thread.html/b857afc7b52e72b2e60ebb3eb594b6fa5dd0ed3c9af5a17b58ee4a99*40*3Cdev.trafficcontrol.apache.org*3E__;JSUl!!CQl3mcHX2A!Q_lvH7GunLsRSIigt4CHJwosp0fih_-ArK7UVI4Z2cr5_J00BL2ZxgbYrYcu9fPda49a$ > > > > > > >> > > > > > > > >> > > > > > > >> People can still use APIv3 (and v2) until ATCv7. if we don't > > > deprecate > > > > > > >> APIv3, then we're going to be in the same boat next time > around > > > when > > > > > > APIv5 > > > > > > >> happens - which I know some people aren't thrilled about but I > > > think > > > > > > we're > > > > > > >> going to need it almost immediately after ATCv6 drops - where > we > > > have > > > > > > two > > > > > > >> supported legacy API versions carrying around cruft and tech > > debt. > > > > > IMO, > > > > > > we > > > > > > >> need to rip this band-aid off sooner
Re: [EXTERNAL] Converting Traffic Router to Kotlin would be easy
I too +1 My experience porting a Java project to Kotlin was specific to Android in the past (re: years ago). I recall my general impression of Kotlin to have some extraneous and unnecessary syntactic sugar (What's up with the for/loop keywords?), but it was an overall solid language. I appreciate the terseness and brevity of things like variable declarations w/ implicit data types and `data classes`, which addresses a long standing complaint about Java's overly verbose syntax. Language aside, the automated porting back then wasn't exactly perfect, but a few things have changed since then; 1) the language specification has solidified over the years, 2) tooling has matured, and 3) is manageable to manually intervene if necessary. > As a side note, because of Oracle's aggressive legal practices, and because they really do want you to think that they own Java (see: Google LLC v. Oracle America, Inc.), using Java in Apache Traffic Control is not really in the spirit of free software. Kotlin is an Apache 2.0-licensed project, so switching to Kotlin would be a true FOSS win for the ATC community. I think the true benefit is moving away from the Java API, which is under such contention, without changing underlying implementation (such as a transition to another, non-JVM, language might incur). On Tue, Jun 22, 2021 at 11:42 AM Chatterjee, Srijeet wrote: > +1 > Sounds like a fun project! > > --Srijeet > > On 6/21/21, 8:43 PM, "Zach Hoffman" wrote: > > Hi Traffic Control! > > As you all may know, the current implementation of Traffic Router runs > on > Java 8. While coding directly in Java is still done, there are some > reasons > to be critical of Java. > > Java often has very verbose syntax when trying to accomplish simple > things. > This has made the Traffic Router codebase grow larger over time, > leading to > maintainability issues. Also, Java suffers from lack of compile-time > safety > in some ways that more modern languages do not. For these reasons, and > because Java is a very old language, some developers who may otherwise > be > interested in contributing to Apache Traffic Control may be > disinterested > contributing to Traffic Router in particular, simply because they want > to > work with more modern languages that do not have the issues that Java > does. > > Kotlin, a JVM language devised by Jetbrains with the goal of tackling > these > problems, has exploded in popularity in recent years, and Kotlin is > becoming a standard way to use the JVM, with Google choosing it as the > preferred language to for developing Android apps. More importantly, > as the > Intellij IDEA Kotlin plugin lets you convert Java sources to Kotlin > (either > at the file level or an entire project, or anywhere in between), > Kotlin has > become a low-effort way to decrease tech debt across large Java > projects. > > Back to Traffic Router: In order to gauge how we would benefit from > converting Traffic Router to Kotlin (it really is a matter of > *converting*, > not rewriting), I converted all of the tests in the Traffic Router > "Core" > module to Kotlin. You can see the result here (as you can see from > GitHub > Actions, the TR tests all pass): < > > https://urldefense.com/v3/__https://github.com/zrhoffman/trafficcontrol/commits/tr-kotlin__;!!CQl3mcHX2A!UCz457i9stX5A-AP8jvvWo21Rqa43JRsC1jQt_fo5nb07raZxByUR9gAGVPZTI4tGhalAel2$ > > > > Some observations: > - Without any putting any effort into optimizing the existing code, > lines > of code shrunk from 10572 in Java to 10217 in Kotlin. See: < > > https://urldefense.com/v3/__https://github.com/zrhoffman/trafficcontrol/commit/5add06bccc__;!!CQl3mcHX2A!UCz457i9stX5A-AP8jvvWo21Rqa43JRsC1jQt_fo5nb07raZxByUR9gAGVPZTI4tGqGQTevX$ > > > - Because it now includes the Kotlin standard library, the Traffic > Router > RPM size increases from 48MB to 58MB. > - The converted sources benefit from Kotlin's null safety and type > safety > (avoiding wildcard types). See < > > https://urldefense.com/v3/__https://github.com/zrhoffman/trafficcontrol/commit/0c2eec39d9__;!!CQl3mcHX2A!UCz457i9stX5A-AP8jvvWo21Rqa43JRsC1jQt_fo5nb07raZxByUR9gAGVPZTI4tGjjMNj-F$ > > (Kotlin > error resolution) and < > > https://urldefense.com/v3/__https://github.com/zrhoffman/trafficcontrol/commit/d8a0fd3bca__;!!CQl3mcHX2A!UCz457i9stX5A-AP8jvvWo21Rqa43JRsC1jQt_fo5nb07raZxByUR9gAGVPZTI4tGoysImMb$ > > (Kotlin > warning resolution) for the changes involved. > > As a side note, because of Oracle's aggressive legal practices, and > because > they really do want you to think that they own Java (see: Google LLC v. > Oracle America, Inc.), using Java in Apache Traffic Control is not > really > in the spirit of free software. Kotlin is an Apache 2.0-licensed > project, > so switching to Kotlin would be a true FOSS win for the ATC community. > > So,
Re: Locale-dependent sorting in Traffic Ops API responses
Seems like we may have already come to a consensus, but I wanted to throw my 2 cents in real quick. TLDR; One concept per test. No to enforcing a locale. Fix the test to validate the content and remove any test verification that has to do with the order returned. In general, I try to abide by Uncle Bob's "One concept per test". While specifically detailed in his Unit Test section, I believe it's applicable for all tests. In this case we may have accidentally conflated two concepts when porting to Go by both testing the functionality of the GET *and* the ordering, when they should really be two distinct tests. One test should validate the functionality, likely by matching the content returned w/o care of order. A separate and second test, if we care, is to verify the sorting matches some predefined order (which I would probably say we do not want to verify at all). Whether we ultimately verify the sort order, or not, it should be in a separate test anyways. I suppose the last point/question I would have is which layer is the sorting authority? Is the sorting defined by the DB / PostgreSQL, Go, or the client like Traffic Portal tables/grids (Granted this is in the API tests)? T On Mon, Jun 21, 2021 at 9:04 PM ocket wrote: > That works for me. Models the intent and the test isn't actually any > weaker, just in a different place. > > On Mon, Jun 21, 2021 at 4:10 PM Rawlin Peters wrote: > > > I think the intent was just to provide some kind of default ordering > > if no `orderby` query parameter was passed in the request. This was > > what TO-Perl did originally, but it was lost in the transition to Go > > at first. It was added later to get back to parity with the original > > TO-Perl version, since there were lots of APIs used by Traffic Portal > > that relied on the default ordering for usability. When the default > > ordering was lost, a lot of lists became unsorted, making them harder > > to select options from. > > > > Maybe we should remove the TO API tests that test the resulting sort > > when using (or not using) the `orderby` param, and instead make them > > unit tests that check that the expected `ORDER BY ...` clause is added > > to the resulting DB query. Then the tests are no longer > > locale-dependent, but we're still testing the expected behavior. > > > > - Rawlin > > > > On Mon, Jun 21, 2021 at 3:51 PM Zach Hoffman > wrote: > > > > > > How would removing or modifying the test change our response to a user > > > saying "Sorting doesn't look right"? > > > > > > -Zach > > > > > > On Mon, Jun 21, 2021 at 3:48 PM ocket > wrote: > > > > > > > But if we test our sorting according to a certain locale, our > response > > to > > > > "sorting doesn't look right" is going to be "what's your locale?" > > instead > > > > of "what's wrong?". If the behavior as tested only works in one > locale, > > > > that's the only locale it supports. This is why I think tests are a > > > > statement of intent about the behavior under test. I'm fine with a > > weaker > > > > test if it better represents what we actually want. > > > > > > > > On Mon, Jun 21, 2021 at 1:46 PM Zach Hoffman > > wrote: > > > > > > > > > > I don't feel good about telling the community/world "this > software > > only > > > > > runs on machines configured for United States-flavor English". > > > > > > > > > > We shouldn't need to tell the community/world "this software only > > runs on > > > > > machines configured for United States-flavor English," we can just > > > > document > > > > > that a specific locale is required for running the API tests. > > > > > > > > > > -Zach > > > > > > > > > > On Mon, Jun 21, 2021 at 1:40 PM ocket > > wrote: > > > > > > > > > > > > I think the likelihood of that test passing when underlying > > > > > functionality > > > > > > *IS BROKEN* can be made acceptably low... > > > > > > > > > > > > clarification > > > > > > > > > > > > On Mon, Jun 21, 2021 at 1:35 PM ocket > > > > wrote: > > > > > > > > > > > > > Currently, as some of you may have noticed, the integration > > tests for > > > > > > > Traffic Ops and its Go API client are failing on master. This > is > > > > > > > (partially) because of a test that checks that the response to > a > > GET > > > > > > > request to /deliveryservices at version 4.0 is sorted by XMLID > > if no > > > > > > > orderby query string parameter is provided. The way it does > this > > is > > > > by > > > > > > > making the request, then sorting the returned XMLIDs, then > > comparing > > > > > the > > > > > > > actual response to the sorted list. > > > > > > > > > > > > > > Here's the problem: the ordering is done in an SQL "ORDER BY" > > clause, > > > > > > > which - besides being a different runtime - runs on ostensibly > an > > > > > > entirely > > > > > > > separate system from the client/TO integration tests. If those > > two > > > > > > systems > > > > > > > aren't using the same locale, they won't sort the same set of > > strings > > > > > in > >
Re: Blueprint - Content Invalidation - Refetch
Hello all, First, thank you all for the time in reviewing and providing feedback for the submitted blueprint for "refetch invalidation". I've since incorporated said feedback and would like to get a final round of review. The blueprint can be found here: https://github.com/apache/trafficcontrol/pull/5910 Barring any major discrepancies, I intend to have this merged Tuesday, June 22. Best, Taylor On Thu, Jun 3, 2021 at 8:38 PM Taylor Frey wrote: > Hello all, > > I've drafted a blueprint to add a feature for Content Invalidation termed > "refetch". > > Apache Traffic Control has the capability for a user to issue a content > invalidation job into the queue. Cache servers can then request the list of > invalidation jobs and handle them based on some information preset, however > this is currently treated as a REFRESH. By this, I mean the cache server > will treat the regex associated files as though the TTL has expired and > attempt to refresh the content (otherwise known as STALE). > > However, there are occasions where we don't want to treat it as a STALE > resource that needs to be REFRESHed, but rather we assume we don't have the > resource at all. In this case we want the cache to treat it as a MISS and > we want to REFETCH the resource from the origin server. More information > can be found in the blueprint. Please let me know if you have any questions. > > The blueprint can be found at: > https://github.com/apache/trafficcontrol/pull/5910 > > Thank you for the feedback! > > Taylor >
Blueprint - Content Invalidation - Refetch
Hello all, I've drafted a blueprint to add a feature for Content Invalidation termed "refetch". Apache Traffic Control has the capability for a user to issue a content invalidation job into the queue. Cache servers can then request the list of invalidation jobs and handle them based on some information preset, however this is currently treated as a REFRESH. By this, I mean the cache server will treat the regex associated files as though the TTL has expired and attempt to refresh the content (otherwise known as STALE). However, there are occasions where we don't want to treat it as a STALE resource that needs to be REFRESHed, but rather we assume we don't have the resource at all. In this case we want the cache to treat it as a MISS and we want to REFETCH the resource from the origin server. More information can be found in the blueprint. Please let me know if you have any questions. The blueprint can be found at: https://github.com/apache/trafficcontrol/pull/5910 Thank you for the feedback! Taylor
