Re: [EXTERNAL] New committer: Eric Holguin

[Chatterjee, Srijeet]

Yay! Congrats Eric!

On 4/24/23, 10:42 AM, "Jeremy Mitchell" mailto:mitchell...@apache.org>> wrote:


The Project Management Committee (PMC) for Apache Traffic Control has
invited Eric Holguin to become a committer, and we are pleased to announce
that he has accepted!


He has been contributing to ATC since 2019 and has primarily been focused
on testing. He has opened over 70 issues (bugs or improvements) and has
also had over 80 pull requests merged. He is also responsible for adding
codecov to the ATC repository to highlight code coverage metrics for each
ATC component.


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.


Thanks,


Jeremy Mitchell

Re: [EXTERNAL] Re: [VOTE] Release Apache Traffic Control 6.1.0-RC2

[Chatterjee, Srijeet]

+1

On 2/1/22, 9:14 AM, "Rawlin Peters"  wrote:

+1

On Tue, Feb 1, 2022 at 9:10 AM Jeremy Mitchell  
wrote:
>
> +1
>
> On Mon, Jan 31, 2022 at 2:51 PM Zach Hoffman  wrote:
>
> > I've prepared a release for 6.1.0-RC2. Changes since RELEASE-6.0.2:
> >
> >
> > 
https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/compare/RELEASE-6.0.2...RELEASE-6.1.0-RC2__;!!CQl3mcHX2A!R0XdVsfAfoM4YVpxxhH49Vrpwv9N0bQEgoEC-4WNbvidWADVxb5hQhmlhXXfweTcFcN7Am2v$
> >
> > 
https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/blob/RELEASE-6.1.0-RC2/CHANGELOG.md__;!!CQl3mcHX2A!R0XdVsfAfoM4YVpxxhH49Vrpwv9N0bQEgoEC-4WNbvidWADVxb5hQhmlhXXfweTcFZRCOeY1$
> >
> > The artifacts are available for download at:
> >
> > 
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/trafficcontrol/6.1.0/RC2/__;!!CQl3mcHX2A!R0XdVsfAfoM4YVpxxhH49Vrpwv9N0bQEgoEC-4WNbvidWADVxb5hQhmlhXXfweTcFfMRJ1uE$
> >
> > BLAKE2 checksum:
> > 
35b73bea81f6550aeecb8e5a0e8776089b557fea135ffdd1c6bc022d3625e34941c834d55114cf7de594578ba4bbe1103d17ae9d3efc3b92ed52279d2c5b14e7
> > apache-trafficcontrol-6.1.0.tar.gz
> >
> > SHA512 checksum:
> > 
be4cb2d99462cd92bb771705853381b8c6fd466d97ebbf273cc401e26629a56019838ba4a9993504780f5994f5005ae5f04d27587664ea3fe5113f816d6e1424
> > apache-trafficcontrol-6.1.0.tar.gz
> >
> > This corresponds to git refs:
> >
> > Hash: f8041b3b5d616003b32d7c0dc160f5f9621e5366
> > Tag: RELEASE-6.1.0-RC2
> >
> > Which can be verified with the following command:
> >
> > $ git tag -v RELEASE-6.1.0-RC2
> >
> > All code signing keys are available here:
> >
> > 
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/release/trafficcontrol/KEYS__;!!CQl3mcHX2A!R0XdVsfAfoM4YVpxxhH49Vrpwv9N0bQEgoEC-4WNbvidWADVxb5hQhmlhXXfweTcFak_CSAJ$
> >
> > Make sure you refresh from a key server to get all relevant signatures.
> >
> > The vote is open until 22:00 UTC on Thursday, February 3 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: [EXTERNAL] Re: [VOTE] Release Apache Traffic Control 6.0.2-RC2

[Chatterjee, Srijeet]

+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 
 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 
> > > > 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: [EXTERNAL] Re: [VOTE] Release Apache Traffic Control 6.0.1-RC0

[Chatterjee, Srijeet]

+1

On 11/8/21, 7:35 AM, "Steve Hamrick"  wrote:

+1

On 11/8/21 06:53, Zach Hoffman wrote:
> +1
>
> On Fri, Nov 5, 2021 at 12:47 PM Taylor Frey  wrote:
>> +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://urldefense.com/v3/__https://github.com/apache/trafficcontrol/compare/RELEASE-6.0.0...RELEASE-6.0.1-RC0__;!!CQl3mcHX2A!ScMcHOdOgP57Z6pnLSuOzXye8KhqaKsjfnGIUshobjre0OXYDUYzWy-9uVHvCirOFgxajegd$
>
>>> 
https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/blob/RELEASE-6.0.1-RC0/CHANGELOG.md__;!!CQl3mcHX2A!ScMcHOdOgP57Z6pnLSuOzXye8KhqaKsjfnGIUshobjre0OXYDUYzWy-9uVHvCirOFkk_FiV5$
> The artifacts are available for download at:
>
>
>>> 
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/trafficcontrol/6.0.1/RC0/__;!!CQl3mcHX2A!ScMcHOdOgP57Z6pnLSuOzXye8KhqaKsjfnGIUshobjre0OXYDUYzWy-9uVHvCirOFhg3B4zF$
> 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://urldefense.com/v3/__https://dist.apache.org/repos/dist/release/trafficcontrol/KEYS__;!!CQl3mcHX2A!ScMcHOdOgP57Z6pnLSuOzXye8KhqaKsjfnGIUshobjre0OXYDUYzWy-9uVHvCirOFhYlLvi2$
>
> 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: [EXTERNAL] Proposal: stable vs unstable TO API versions

[Chatterjee, Srijeet]

Just catching up on this thread. I'm +1 on the stable vs unstable versioning 
thing (having gone through writing a new API version for the role and perms 
recently, and encountering the pains of it). I'm also +1 for Brennan's idea of 
adding a config option to disable using unstable routes, or prefixing the 
routes with "unstable" to make it very clear to the users that it is a risk 
that they are taking.

-- Srijeet

On 8/27/21, 3:19 PM, "Rawlin Peters"  wrote:

Hey folks,

I'd like to propose that we start moving towards a TO API development
model where we consider the latest major version of the API
"unstable," while the 2nd latest major version is considered "stable."
What that means is that we would be free to make breaking changes to
the "unstable" version, while the "stable" version would maintain
backwards-compatibility. Eventually, once we feel that the latest
version of the TO API has stabilized, we will declare it "stable" and
deprecate the old stable version.

I see multiple benefits to this:
1. reduce the number of major API versions developers need to support,
making it easier to add new features
2. developers can make incremental changes (breaking and non-breaking)
to the unstable API version in every release without having to
introduce new major or minor versions, making the resulting API much
better overall once it is stabilized
3. reduce the number of unnecessary client upgrades, where the API
version changed but none of the routes the client uses were actually
changed
4. clients that don't need the latest API features don't have to upgrade
5. helps us release more frequently, because we aren't slowed down by
adding unnecessary code for a new TO API major/minor version with
every release
6. gives us more flexibility in what features need to be completed
before we cut a release (because they'd be targeting the unstable API
anyways, we can cut a release without causing a bunch of re-work for
new features that missed the API version bus)

Alas, all good things come at a price. For clients that need to use
the unstable version of the TO API (like Traffic Portal), their
upgrades may need to be closely coordinated with the Traffic Ops
upgrade. For TP, this is nothing new, because it is generally always
upgraded at the same time as TO. However, for other components that
may want to use the unstable API (e.g. `t3c`), this means certain
upgrades (not all, mind you, only those where a route the component
uses is actually broken) would have to be closely coordinated with
Traffic Ops. That said, for `t3c` at least, moving forward with Cache
Config Snapshots 
(https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/pull/4708__;!!CQl3mcHX2A!XtyCtE8_H3-0xxF6ztzkBFp8UYdKj0OYf9VwAp__fMt6i0GXr0ZbY04nf2eCa9jXOxcRDfxY$
 )
would greatly alleviate that concern, since the snapshot route would
be kept backwards-compatible.

Please let me know what you think of this proposal. If we can come to
a consensus on this, we may be able to declare TO API 3.0 "stable" and
4.0 "unstable," meaning we can avoid a potential 5.0 API version in
whatever release comes after ATC 6.0.

- Rawlin

Removal of "Long Description 1" and "Long Description 2"

[Chatterjee, Srijeet]

Hi all,
I’m proposing a change to the DeliveryService structure and database table, to 
remove the “Long Description 1” and “Long Description 2” fields. These fields 
are seldom used, and can be replaced by the already existing “Long Description” 
field. In my migration, I’m planning to copy over all the data in the existing 
LD1 and LD2 fields, and append it to the LD field, and drop the LD! And LD2 
fields from the table. Pls let me know if you have concerns with this change, 
or if you have a better way of doing this.

Thanks,
Srijeet

Re: [EXTERNAL] Converting Traffic Router to Kotlin would be easy

[Chatterjee, Srijeet]

+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, converting the rest of Traffic Router would be relatively fast and
easy, would result in *no* functionality gained or lost, would leave TR
usage totally unchanged, would make development more enjoyable for current
TR devs, and would maybe catch the interest of additional devs who
otherwise may not be interested in Traffic Router.

How does this sound?

-Zach

Re: [EXTERNAL] Re: [VOTE] Release Apache Traffic Control 5.1.2-RC3

[Chatterjee, Srijeet]

+1
Components build, basic TO test seems to work fine.

On 5/12/21, 10:22 AM, "Zach Hoffman"  wrote:

+1

On Wed, May 12, 2021 at 9:51 AM Eric Friedrich  wrote:

> +1
> Checked signature and hashes. Builds with pkg
>
>
> On Wed, May 12, 2021 at 11:05 AM Dave Neuman  wrote:
>
> > +1
> > Validated signature, hash, and ran pkg -v to build all RPMs.
> >
> > On Tue, May 11, 2021 at 6:34 PM Rawlin Peters  wrote:
> >
> > > +1
> > >
> > > On Fri, May 7, 2021 at 10:08 AM ocket  
> wrote:
> > > >
> > > > Hello All,
> > > >
> > > > I've prepared a release for v5.1.2-RC3
> > > >
> > > > 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.1:
> > > >
> > >
> >
> 
https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.1...RELEASE-5.1.2-RC3__;!!CQl3mcHX2A!XCCWYVbYgt0PzqUZOdy-ZpRLxReSojkTWnpcxSx6TmDtc1BtC4agFi3PFzd6wIcmatbrWJkw$
> > > >
> > > > This corresponds to git:
> > > > Hash: 8892beff94f6bf699ee95bc1a66afa09775796f0
> > > > Tag: RELEASE-5.1.2-RC3
> > > >
> > > > Which can be verified with the following: git tag -v
> RELEASE-5.1.2-RC3
> > > >
> > > > My code signing key is available here:
> > > >
> > >
> >
> 
https://urldefense.com/v3/__https://keys.gnupg.net/pks/lookup?search=0xF5D560A373B76FA302A95DBFCDFE430685982C95=on=index__;!!CQl3mcHX2A!XCCWYVbYgt0PzqUZOdy-ZpRLxReSojkTWnpcxSx6TmDtc1BtC4agFi3PFzd6wIcmajt5er7d$
> > > >
> > > > 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://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/trafficcontrol/5.1.2/RC3__;!!CQl3mcHX2A!XCCWYVbYgt0PzqUZOdy-ZpRLxReSojkTWnpcxSx6TmDtc1BtC4agFi3PFzd6wIcmahVxXedF$
> > > >
> > > > Thanks!
> > > > ocket ocket8...@apache.org
> > >
> >
>

CDN Locks Blueprint

[Chatterjee, Srijeet]

Hi all,
I’ve opened a PR to propose a new feature for Traffic Control: CDN Locks. This 
will enable users to have some exclusivity while snapping/ queueing a CDN (and 
its servers), to ensure that no unintended changes make their way into the 
snapshots and dirty them. Please take a look at it and let me know your 
thoughts. Here is the PR link: 
https://github.com/apache/trafficcontrol/pull/5834

Thanks,
Srijeet

Re: [EXTERNAL] Re: Deprecate TO API endpoint vault/bucket/:bucket/key/:key/values

[Chatterjee, Srijeet]

+1

On 4/12/21, 7:58 AM, "Frey, Taylor"  wrote:

Agreed.

From: Jeremy Mitchell 
Date: Saturday, April 10, 2021 at 9:41 AM
To: dev@trafficcontrol.apache.org 
Subject: [EXTERNAL] Re: Deprecate TO API endpoint 
vault/bucket/:bucket/key/:key/values
+1

On Fri, Apr 9, 2021 at 5:13 PM ocket   wrote:

> +1000
>
> On Fri, Apr 9, 2021 at 4:35 PM Rawlin Peters  wrote:
>
> > Hey Traffic Controllers,
> >
> > I'd like to propose that we deprecate the following route:
> >
> > GET api//vault/bucket/:bucket/key/:key/values
> >
> > This route is just a passthrough to the Riak API, allowing an admin to
> > get anything stored in Riak by bucket and key. We already have
> > specific routes to get everything stored in Riak, so I'm not sure what
> > value this route provides. Riak is being replaced with PostgreSQL, and
> > this route doesn't make sense for a PostgreSQL Traffic Vault backend
> > either. Additionally, my team hasn't used this route in at least the
> > last 30 days (and probably much longer than that).
> >
> > I'd like to remove this from the 4.x API which is currently in
> > development, so I'll give this a few business days to respond w/ any
> > votes (silence is consent).
> >
> > - Rawlin
> >
>

Re: [EXTERNAL] Re: [VOTE] Release Apache Traffic Control 5.1.1-RC0

[Chatterjee, Srijeet]

+1
Everything builds fine, and local TO/ TP manual tests seem to be working.

--Srijeet

On 3/26/21, 7:48 PM, "Steve Hamrick"  wrote:

+1
Builds successfully, tests pass and CiaB appears to work.

On 3/26/21 3:53 PM, Jeremy Mitchell wrote:
> full teardown/rebuild of cdn-in-a-box builds/runs successfully and did 
some
> light testing through TP.
>
> +1
>
> On Fri, Mar 26, 2021 at 11:22 AM Zach Hoffman  
wrote:
>
>> +1, the components build and work as expected.
>>
>> Traffic Ops API v3 tests can sometimes fail with a message like
>> servers_test.go:342: Expected 200 status code, got 304
>> but that is a bug in the API tests themselves (similar to what
>> 
https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/pull/4851__;!!CQl3mcHX2A!VOK01kPD2pWhY4ej7wk3nIlYTgZntKCN6GZwT39ZKi2yyr9udsMocV892ddX2Reyl1Bhrl1X$
  fixes), and Traffic Ops
>> itself work as intended.
>>
>> -Zach
>>
>> On Mon, Mar 22, 2021 at 1:16 PM ocket   wrote:
>>
>>> Hello All,
>>>
>>> I've prepared a release for v5.1.1-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.0:
>>>
>>>
>> 
https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.0...RELEASE-5.1.1-RC0__;!!CQl3mcHX2A!VOK01kPD2pWhY4ej7wk3nIlYTgZntKCN6GZwT39ZKi2yyr9udsMocV892ddX2Reyl5rLmCYW$
>>> This corresponds to git:
>>> Hash: 94539b43f596d58a71505eb3017d4cdcafe769b6
>>> Tag: RELEASE-5.1.1-RC0
>>>
>>> Which can be verified with the following: git tag -v RELEASE-5.1.1-RC0
>>>
>>> My code signing key is available here:
>>>
>>>
>> 
https://urldefense.com/v3/__https://keys.gnupg.net/pks/lookup?search=0xF5D560A373B76FA302A95DBFCDFE430685982C95=on=index__;!!CQl3mcHX2A!VOK01kPD2pWhY4ej7wk3nIlYTgZntKCN6GZwT39ZKi2yyr9udsMocV892ddX2Reyl7gXvx2c$
>>> 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://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/trafficcontrol/5.1.1/RC0__;!!CQl3mcHX2A!VOK01kPD2pWhY4ej7wk3nIlYTgZntKCN6GZwT39ZKi2yyr9udsMocV892ddX2Reyl3pEt3a7$
>>>
>>> Thanks!
>>> ocket ocket8...@apache.org
>>>

Re: [EXTERNAL] Re: TO Go client best practices

[Chatterjee, Srijeet]

+1
I did try to reduce the duplicate methods (the ones with the `WithHdr` suffix) 
in `servers` and `server_details` when I wrote the API 4.0 stuff.

--Srijeet

On 2/9/21, 9:30 AM, "Zach Hoffman"  wrote:

+1, this would cut down on a bunch of redundancy that we currently have in
the TO client.

-Zach

On Mon, Feb 8, 2021 at 3:15 PM ocket   wrote:

> By "best practices" I mean a page in the docs - and probably a section in
> the
> client README.md - of rules to be followed by authors of new client
> methods.
>
> But that's just a place to put the two practices I'd like to propose
> putting
> into place:
>
> - All client request methods use one of the call signatures:
>
> func (to *Session) MethodName(BodyType, IDType, RequestOptions)
> (ResponseType, ReqInf, error)
> func (to *Session) MethodName(BodyType, RequestOptions) (ResponseType,
> ReqInf, error)
> func (to *Session) MethodName(RequestOptions) (ResponseType, ReqInf,
> error)
>
> ... as appropriate, where 'RequestOptions' includes URL query string
> parameters, HTTP headers, and whatever else we decide to add, and
> 'ResponseType' is the full response from the API (i.e. 'response',
> 'summary' where applicable, and 'alerts').
>
> - The type of the 'Response Body' property of those 'ResponseType's should
> always be a type alias for the client's major version of a struct. So
> you could have, for example
>
> type DSV40 struct {...}
> type DSV4 = DSV40
>
> for API v4.0, but if/when API 4.1 comes out and makes (non-breaking)
> changes to a 'DS', you'd have:
>
> type DSV40 struct {...}
> type DSV41 struct {...}
> type DSV4 = DSV41
>
> and the APIv4.x client would use 'DSV4' in its call signature's
> 'ResponseType' so that non-breaking changes could be made to DSes
> across
> minor API versions without breaking the client call signature.
>
> An example of a full 'ResponseType' from the above call signatures,
> using
> that 'DSV4' would look like:
>
> type DSV4Response struct {
> // no package qualifier on 'Alerts' because I assume this would go
> in
> // /lib/go-tc so it's not necessary.
> Alerts
> Response DSV4
> }
>

Re: [EXTERNAL] Re: [VOTE] Release Apache Traffic Control 5.0.0-RC9

[Chatterjee, Srijeet]

+1
Did some basic testing locally, looks good.

On 1/20/21, 12:04 PM, "Steve Hamrick"  wrote:

+1

On 1/20/21 11:42 AM, Rawlin Peters wrote:
> +1
>
> - Rawlin
>
> On Wed, Jan 20, 2021 at 10:55 AM Jeremy Mitchell  
wrote:
>> +1
>>
>> On Fri, Jan 15, 2021 at 1:55 PM Zach Hoffman  
wrote:
>>
>>> +1
>>>
>>> On Fri, Jan 15, 2021 at 11:57 AM ocket   wrote:
>>>
 Hello All,

 I've prepared a release for v5.0.0-RC9

 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 4.1.1:


>>> 
https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/compare/RELEASE-4.1.1...RELEASE-5.0.0-RC9__;!!CQl3mcHX2A!VVeEb4fQOwGSvLFmjOjVA3DyvFY_snTwkIcpMAI8hG91d4DKLwJ_4QDaw-5u5aeYmSptvcFj$
 <

>>> 
https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/compare/RELEASE-4.1.1...RELEASE-5.0.0-RC2__;!!CQl3mcHX2A!VVeEb4fQOwGSvLFmjOjVA3DyvFY_snTwkIcpMAI8hG91d4DKLwJ_4QDaw-5u5aeYmSdK2j6X$
 This corresponds to git:
 Hash: 19c0487f8de71f36219aa0a5d9535ad4d2080229
 Tag: RELEASE-5.0.0-RC9

 Which can be verified with the following: git tag -v RELEASE-5.0.0-RC9

 My code signing key is available here:


>>> 
https://urldefense.com/v3/__https://keys.gnupg.net/pks/lookup?search=0xF5D560A373B76FA302A95DBFCDFE430685982C95=on=index__;!!CQl3mcHX2A!VVeEb4fQOwGSvLFmjOjVA3DyvFY_snTwkIcpMAI8hG91d4DKLwJ_4QDaw-5u5aeYmVDZDcDk$
 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://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/trafficcontrol/5.0.0/RC9__;!!CQl3mcHX2A!VVeEb4fQOwGSvLFmjOjVA3DyvFY_snTwkIcpMAI8hG91d4DKLwJ_4QDaw-5u5aeYmQt4PbQu$
 


 Thanks!
 ocket ocket8...@apache.org

Re: [EXTERNAL] Re: Replace Riak w/ PostgreSQL

[Chatterjee, Srijeet]

+1 on moving away from Riak and using postgres instead. Riak can be a 
pain(atleast for new users) to set up and debug.

--Srijeet

From: John Rushford 
Date: Monday, December 7, 2020 at 8:07 PM
To: dev@trafficcontrol.apache.org 
Subject: Re: [EXTERNAL] Re: Replace Riak w/ PostgreSQL
+1 on using Postgres.  I’ve played around with Postgres and pgcrypto.  Keeping 
certs and sig keys encrypted is easily done in postgres.  I used asymmetric 
public private key encryption with pgcrypto where I stored the public key to 
encrypt  in a database table.  The private key was stored apart from the 
database and used by an api that had secure access to the private key.  This 
worked quite well and is mostly done with Postgres queries

Sent from my iPhone

> On Dec 7, 2020, at 4:00 PM, Gray, Jonathan 
>  wrote:
>
> HashiCorp Vault and/or Consul is the only other primary contender I think 
> we've had proposed, but I'm +1/+1 as well.
>
> Jonathan G
>
> On 12/7/20, 3:58 PM, "Rawlin Peters"  wrote:
>
>Yes, I agree with the plugin interface as well, but that is what I was
>hoping to defer to a follow-up thread, preferably with a rough draft
>of a blueprint in hand. First, I just want to get an official
>consensus on PostgreSQL (in this case as the _main_ plugin
>implementation).
>
>- Rawlin
>
>>On Mon, Dec 7, 2020 at 2:24 PM Robert O Butts  wrote:
>>
>> +1 and +1 to what @neuman said. I'd vote this be framed more like "change
>> TO secret store to a Plugin interface, and ATC will provide a Postgres
>> Plugin."
>>
>> I'd also like to note, I believe our company has a legal requirement to
>> have a separate "secret" database, so the Postgres secret store needs to at
>> least have the ability to be a separate DB URL+auth than the primary TO
>> Postgres DB.
>>
>>
>>> On Mon, Dec 7, 2020 at 2:13 PM Dave Neuman  wrote:
>>>
>>> I am +1 for using Postgres, however we should consider implementing the
>>> "secret store" functionality in such a way that people can choose to
>>> implement whatever backend they want.  I think it can be accomplished using
>>> the TO plugin functionality but I am sure people more familiar with the
>>> code these days would know better.  This would also provide a built in way
>>> to migrate from one to the other without forcing everyone to change.
>>>
>>>
>>>
 On Mon, Dec 7, 2020 at 1:48 PM Rawlin Peters  wrote:
>>>
 Hey folks,

 I hope by now everyone can agree that we need to replace Riak (it's
 been unmaintained for quite some time now). However, we might not all
 agree yet on what it should be replaced with (at least not
 officially). We've discussed it in threads here and there, but I'd
 like to get some official consensus before we really hit the ground
 running.

 I would like to propose that we replace Riak with PostgreSQL.

 Here are some of the reasons that I can think of (and have been
 mentioned by others in the past) for us to use PostgreSQL:
 - we all have much experience running it in production (because we
 already run it for the Traffic Ops database)
 - it would simplify ATC deployments by removing one more component
 from the system
 - it would simplify development as ATC devs are already familiar with
 traditional SQL databases, and we could reuse a lot of the existing
 code
 - it has a healthy community of support and doesn't seem to be losing
 steam anytime soon (it still remains the 2nd most popular OSS
 relational database behind MySQL [1])

 I would like this thread to focus on the merits (or lack thereof) of
 using PostgreSQL as a replacement for Riak. We can discuss the
 low-level implementation details separately in the blueprint I will
 propose as a follow-up to this discussion. Unless someone is
 vehemently -1 on using PostgreSQL to replace Riak, I will take silence
 as assent and move forward with the blueprint process.

 - Rawlin

 [1] 
 https://urldefense.com/v3/__https://db-engines.com/en/ranking_osvsc__;!!CQl3mcHX2A!Xy7f_5hSaPy1VOI6G3s7dnOKEWWmrpYJK1noQ67A3gTlldrSM596Zx4YjjbMHFUITPk4$

>>>
>

Update on how Traffic Router handles 'miss' location

[Chatterjee, Srijeet]

Hi all,
This is with regards to the following Github issue:
https://github.com/apache/trafficcontrol/issues/4912

A Delivery Service(DS) will have an option of which “miss” location to use: the 
default DS miss location or the national center location, configured through 
“maxmind.default.override”. With the pull request for this issue, we plan to 
change how the DS selects which “miss” location to use. The DS will use its own 
“miss” latitude/ longitude location, and not the  default location of the 
country. If the “maxmind.default.override” param is not set, then whatever gets 
returned from maxmind will be used by TR to route the traffic. This will 
prevent us from sending a non-trivial amount of traffic being incorrectly 
routed to one cache group causing potential capacity issues.
Please feel free to reach out to me if there are concerns with this change.

Thanks,
Srijeet