Re: [VOTE] Release Apache Traffic Control 8.0.1-RC1

[Jeremy Mitchell]

+1

On Thu, Mar 28, 2024 at 10:16 AM Jan van Doorn  wrote:

> (Sorry replied to the wrong one just now)
>
> +1
>
> (built the artifacts, and verified CIAB starts cleanly)
>
>
> > On 27 Mar 2024, at 18:17, R S  wrote:
> >
> > Hello All,
> >
> > I've prepared a release for 8.0.1-RC1. There *isn't any* changes since
> > RELEASE-8.0.1-RC0:
> >
> > The purpose of this new candidate is to get enough votes to either cut a
> > release or make a change. Please be kind and vote.
> > Also, *note*: These changes have been verified and are running internally
> > at Comcast.
> >
> > https://github.com/apache/trafficcontrol/compare/v8.0.1-rc0...v8.0.1-rc1
> >
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-8.0.1-RC1/CHANGELOG.md
> >
> > The artifacts are available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/8.0.1/RC1/
> >
> > BLAKE2 checksum:
> >
> 448227ebe681561613ce65db4e20f62ac7f9d043200e2a94915e36facdc9f01f549a97dccaafedfe420b61b896a690850c5965b164ceea1b02d372fcb9250065
> >
> > SHA512 checksum:
> >
> c438f337725caca1b1a1ddb25d1a2ea04b96a9a4d786acd0b24fb3e7455f95e069c9af121ebdcbde2e63168330ba8e2b999a912637de97403acf52e6e06ebdb1
> >
> > This corresponds to git refs:
> >
> > Hash:ad667bb9178d96adfdcdff10b51fe6b3a4ce2e1b
> > Tag: RELEASE-8.0.1-RC1
> >
> > Which can be verified with the following command:
> >
> > $ git tag -v RELEASE-8.0.1-RC1
> >
> > 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.
> >
> > The vote is open until 22:00 UTC on *Monday, April 1st* and passes if a
> > majority of at least 3 +1 PMC votes are cast.
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Thanks!
> > Rima Shah
> >
> > rs...@apache.org
>
>

Re: [VOTE] Release Apache Traffic Control 8.0.1-RC0

[Jeremy Mitchell]

+1

On Thu, Mar 21, 2024 at 11:06 AM R S  wrote:

> Hello All,
>
> I've prepared a release for 8.0.1-RC0. Changes since RELEASE-8.0.0:
>
> https://github.com/apache/trafficcontrol/compare/v8.0.0...v8.0.1-rc0
>
>
> https://github.com/apache/trafficcontrol/blob/RELEASE-8.0.1-RC0/CHANGELOG.md
>
> The artifacts are available for download at:
>
> https://dist.apache.org/repos/dist/dev/trafficcontrol/8.0.1/RC0/
>
> BLAKE2 checksum:
>
> f390f67497c369b364867a82089b97a581835ac4fb7a51f902e0a7a52558e7690deaf6726f7e146be1dbfc14abc2fdb8efa57e5143ca42aec2ecfc8475f6e673
>
> SHA512 checksum:
>
> f8be5d2e2f0bf426d7831f262c95b297c382996d0f0b82516f0b444de75082debbbe26700d1a61f238524cc23724cfd0880ba64126ee74804680cb646fa088e0
>
> This corresponds to git refs:
>
> Hash:ad667bb9178d96adfdcdff10b51fe6b3a4ce2e1b
> Tag: RELEASE-8.0.1-RC0
>
> Which can be verified with the following command:
>
> $ git tag -v RELEASE-8.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.
>
> The vote is open until 22:00 UTC on Monday, March 25 and passes if a
> majority of at least 3 +1 PMC votes are cast.
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Thanks!
> Rima Shah
>
> rs...@apache.org
>

Re: [VOTE] Release Apache Traffic Control 8.0.0-RC6

[Jeremy Mitchell]

+1

On Wed, Jan 24, 2024 at 10:45 AM Eric Holguin 
wrote:

> +1
>
> On 2024/01/24 16:50:50 R S wrote:
> > Hello All,
> >
> > Thank you for all the +1s (5) for RC5. We need one last candidate to
> > include *three* changes.
> >
> > 1. documents now build correctly
> > 2. CIAB build on Mac mini M2 Pro
> > 3. t3c RPM DB check with Rocky Linux 9
> >
> > *Note*: These changes have been running internally and have been stable
> at
> > Comcast.
> >
> > I've prepared a release for 8.0.0-RC6. Changes since RELEASE-8.0.0-RC5:
> >
> > https://github.com/apache/trafficcontrol/compare/v8.0.0-rc5...v8.0.0-rc6
> >
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-8.0.0-RC6/CHANGELOG.md
> >
> > The artifacts are available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/8.0.0/RC6/
> >
> > BLAKE2 checksum:
> >
> >
> 0361e89ea9ba7b26d593d49e10f0cb817851fc98a08380991d3f8116c05687d8f909ed0aabcb25b3383d16c1c244d5045eef395f4d256a98f8f5ff394f6a2dec
> >
> > SHA512 checksum:
> >
> >
> f019d7e6f00e60d7dc6a405f6b96aca494195c337eb1bcba3e5ec06208def19d93a6a15f87c06cb8f461f27a0da9e2a3838e5eea397cc06779f1cd6cd88220c7
> >
> > This corresponds to git refs:
> >
> >   Hash:6cb2bca67c27f926ff4b8f84de7818e7a8191b0d
> >   Tag: RELEASE-8.0.0-RC6
> >
> > Which can be verified with the following command:
> >
> >   $ git tag -v RELEASE-8.0.0-RC6
> >
> > 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.
> >
> > The vote is open until 22:00 UTC on Monday, Jan 29th 2024 and passes
> > if a majority of at least 3 +1 PMC votes are cast.
> >   [ ] +1 approve
> >   [ ] +0 no opinion
> >   [ ] -1 disapprove (and reason why)
> >
> > Thanks and Regards,
> > Rima Shah
> >
>

Re: [VOTE] Release Apache Traffic Control 8.0.0-RC5

[Jeremy Mitchell]

+1

On Wed, Jan 17, 2024 at 11:09 AM Rima Shah  wrote:

> Corrected top link.
>
>  I've prepared a release for 8.0.0-RC5.
>
> Changes since RELEASE-8.0.0-RC4:
> https://github.com/apache/trafficcontrol/compare/v8.0.0-rc4...v8.0.0-rc5
>
>
> https://github.com/apache/trafficcontrol/blob/RELEASE-8.0.0-RC5/CHANGELOG.md
>
> Regards,
> Rima Shah
>
> On 2024/01/17 17:48:56 R S wrote:
> > Hello All,
> >
> > I've prepared a release for 8.0.0-RC5. Changes since RELEASE-8.0.0-RC4:
> > https://github.com/apache/trafficcontrol/compare/v8.0.0-rc4...v8.0.0-rc5
> >  <
> https://github.com/apache/trafficcontrol/blob/RELEASE-8.0.0-RC4/CHANGELOG.md
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-8.0.0-RC5/CHANGELOG.md
> >
> > The artifacts are available for download at:
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/8.0.0/RC5/
> >
> > BLAKE2 checksum:
> >
> >
> a2d12fa11050e20b7ab4c864a058de2781af4a1449e62c5d3cc169fcd6c8bb88dd9f065a2a44d93ed6f64b00802aa0c387f997c7dea0e7331e4b8397022caa68
> >
> > SHA512 checksum:
> >
> >
> cb826938cdf23e053326f5b0de0cea36de8d3825c5803392a1ba1cb8406a753c6d523e2662cc82ac33181a7f295ca7b74c8e72ebe848e64ae4ad3d5a67872667
> >
> > This corresponds to git refs:
> >
> >   Hash:0c515199dbeb3233b32376268e4ee32ad18ebd8b
> >   Tag: RELEASE-8.0.0-RC5
> >
> > Which can be verified with the following command:
> >
> >   $ git tag -v RELEASE-8.0.0-RC5
> >
> > 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.
> >
> > The vote is open until 22:00 UTC on Monday, Jan 22nd 2024 and passes
> > if a majority of at least 3 +1 PMC votes are cast.
> >   [ ] +1 approve
> >   [ ] +0 no opinion
> >   [ ] -1 disapprove (and reason why)
> >
> > Thanks!
> > Rima Shah
> >
>

Comcast ATC Open Source Withdrawal Announcement

[Jeremy Mitchell]

A message from Comcast:

Since inception, Comcast has been the driving force on the Apache Traffic
Server OSS project. As the CDN landscape is evolving, it has become clear
that Comcast must adapt its CDN business as well. This evaluation includes
weighing our investments against the return on those investments. An area
of focus has been our participation in different open source communities,
and at this point in time the ATC project is not balanced enough for
Comcast to continue to contribute. We do care dearly about the project and
feel that it is best if Comcast withdraws, at least temporarily, to allow
other contributors to take a larger role and encouraging additional
participation from new sources. If the project begins to thrive, Comcast is
absolutely willing to rejoin the community.  Please know that this was a
difficult and emotional decision, as Comcast and ATC have been very much
intertwined. This is purely a business decision and is in no way meant to
diminish the incredible accomplishments this community have made and how
much delivery it has empowered.  We would like to thank the community and
will certainly continue to monitor its progress. The official release of
ATC 8.0 will mark Comcast's final contribution.

Re: [VOTE] Release Apache Traffic Control 8.0.0-RC4

[Jeremy Mitchell]

+1 - a form of 8.0.0 has been in comcast production for about a month and
no major problems.

On Tue, Oct 24, 2023 at 1:03 PM R S  wrote:

> Hello All,
>
> I've prepared a release for 8.0.0-RC4. Changes since RELEASE-8.0.0-RC3:
>
> https://github.com/apache/trafficcontrol/compare/v8.0.0-rc3...v8.0.0-rc4
>
>
> https://github.com/apache/trafficcontrol/blob/RELEASE-8.0.0-RC4/CHANGELOG.md
>
> The artifacts are available for download at:
> https://dist.apache.org/repos/dist/dev/trafficcontrol/8.0.0/RC4/
>
> BLAKE2 checksum:
>
>
> 108a70b97981fedb98c7753c96b49d72c4c284ceab6f95b5c5f664a3dcfb30efb33be98e68107e27576d55a69327503989261e56c9ee034890463a2bf091930a
>
> SHA512 checksum:
>
> a8f4c38032db618358dcb823555322a13ad5e507345366cbfaf31f49aeaf0b66e5817a4b58bbac28728ad0474b7333531bf95fbb45de32aec0ea5671f66ea989
>
> This corresponds to git refs:
>
> Hash:23e9248c5ee0fb156b57d60344631ab3216a5811
> Tag: RELEASE-8.0.0-RC4
>
> Which can be verified with the following command:
>
> $ git tag -v RELEASE-8.0.0-RC4
>
> 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.
>
> The vote is open until 22:00 UTC on Friday, October 27 and passes if a
> majority of at least 3 +1 PMC votes are cast.
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Thanks!
> Rima Shah
>
> rs...@apache.org
>

Re: [VOTE] Release Apache Traffic Control 8.0.0-RC3

[Jeremy Mitchell]

so do we need a 8.0.0 RC4 as this appears to be fixed/merged -
https://github.com/apache/trafficcontrol/pull/7614

On Fri, Oct 6, 2023 at 2:25 PM ocket   wrote:

> -1; security concern: permissions removed from user roles (e.g. "portal")
> will be silently re-added to those roles on upgrade, escalating privileges.
> This hasn't been a problem in earlier releases because 7.x was the first
> release to contain actual constraints based on Permissions.
>
> On Tue, Oct 3, 2023 at 10:54 AM R S  wrote:
>
> > Hello All,
> >
> > I've prepared a release for 8.0.0-RC3. Changes since RELEASE-8.0.0-RC2:
> >
> > https://github.com/apache/trafficcontrol/compare/v8.0.0-rc2...v8.0.0-rc3
> >
> >
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-8.0.0-RC3/CHANGELOG.md
> >
> > The artifacts are available for download at:
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/8.0.0/RC3/
> >
> > BLAKE2 checksum:
> >
> >
> >
> e8e8abe66471b6b1839d53b07de41fcfe43185b00562b405b8a5c5f54329f7c6279032e6ad052fa3ccc346561a88f1b4de50cfed7e663aa7205c31923d2be9c5
> >
> > SHA512 checksum:
> >
> >
> 66b03fa49ab8e15bb1a933a9712c81b67c0f13f6412ac8ca6b95a9dc89be33b79707ed6a487aa2ea3af01967195b4012a85b6ae3b3f1f12c2a96f6d2f279e0d6
> >
> > This corresponds to git refs:
> >
> > Hash:cedcd2c033ef8cde189b54c47ff59bbeed1be976
> > Tag: RELEASE-8.0.0-RC3
> >
> > Which can be verified with the following command:
> >
> > $ git tag -v RELEASE-8.0.0-RC3
> >
> > 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.
> >
> > The vote is open until 22:00 UTC on Friday, October 6 and passes if a
> > majority of at least 3 +1 PMC votes are cast.
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Thanks!
> > Rima Shah
> >
> > rs...@apache.org
> >
>

Re: [VOTE] Release Apache Traffic Control 8.0.0-RC2

[Jeremy Mitchell]

-1 looks like privlevel is still being referenced in the v5 api but it was
fixed with this commit:

https://github.com/apache/trafficcontrol/commit/5081509d5f0b42f5c50621deb07521c7db6d863a

On Mon, Sep 25, 2023 at 4:23 PM R S  wrote:

> Hello All,
>
> I've prepared a release for 8.0.0-RC2. Changes since RELEASE-8.0.0-RC1:
>
> https://github.com/apache/trafficcontrol/compare/v8.0.0-rc1...v8.0.0-rc2
>
>
> https://github.com/apache/trafficcontrol/blob/RELEASE-8.0.0-RC2/CHANGELOG.md
>
> The artifacts are available for download at:
> https://dist.apache.org/repos/dist/dev/trafficcontrol/8.0.0/RC2/
>
> BLAKE2 checksum:
>
>
> eb58add53ae87da2edcbef6fd556ea8e1203e82e1b69322572b8ae641e32fc5892529b29dea553ed3d2fbf7feed7ed3689157ac4c8a6e62c1504d4250bb554b1
>
> SHA512 checksum:
>
> 5e11dc0918e5bfc8bd127deaaba96c97d19152cb06b56d2aef3255f43eb11006ab5c12f1e272118b99b32f0c09bb292eb212fc31d7b3b123950c5f74bb4d1cd8
>
> This corresponds to git refs:
>
> Hash:3a5c72f0665c449c1e679ab97271ff0272b8e5cf
> Tag: RELEASE-8.0.0-RC2
>
> Which can be verified with the following command:
>
> $ git tag -v RELEASE-8.0.0-RC2
>
> 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.
>
> The vote is open until 22:00 UTC on Thursday, September 28 and passes
> if a majority of at least 3 +1 PMC votes are cast.
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Thanks!
> Rima Shah
>
> rs...@apache.org
>

New committer: Eric Holguin

[Jeremy Mitchell]

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: New Committer: Rima Shah

[Jeremy Mitchell]

welcome rima!

On Wed, Feb 15, 2023 at 7:45 PM Zach Hoffman  wrote:

> Good job, Rima!
>
> -Zach
>
> On Thu, Feb 16, 2023 at 2:44 AM ocket   wrote:
>
> > The Project Management Committee (PMC) for Apache Traffic Control
> > has invited Rima Shah to become a committer and we are pleased
> > to announce that they have 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: Reg., a query on cache config t3c-apply.

[Jeremy Mitchell]

you should probably ask this in our traffic control slack  channels.
would you like an invite?

jeremy

On Tue, Sep 13, 2022 at 6:03 AM Abhishek Suresh Kumar <
asureshku...@embedur.com> wrote:

> Hey, any update on this thread?
>
> Regards,
> Abhishek S
> From: Abhishek Suresh Kumar
> Sent: 06 September 2022 12:14
> To: dev@trafficcontrol.apache.org
> Subject: Reg., a query on cache config t3c-apply.
>
> Hello,
>
> I’ve installed the traffic server, ops, portal and
> cache-config RPM on a bare-metal Linux (Centos 7) and running them as
> system service. I’ve an edge server linked with a profile. Added a new
> parameter to the profile and performing a t3c-apply on the server. Facing
> the below issue while executing the command.
>
> ERROR: t3c-request.go:68: 2022-09-05T12:03:03.561269Z: writing data:
> getting config data: getting cdn 'kabletowncdn': getting cdn ssl keys:
> getting uncached: getting cdn ssl keys from Traffic Ops '': error
> requesting Traffic Ops: path '
> https://172.24.109.216:443/api/4.0/cdns/name/kabletowncdn/sslkeys' gave
> HTTP error 500 Internal Server Error - error-level alerts: Internal Server
> Error
>
> Attached the log output of t3c-apply command. PFA.
> Any help on these would be appreciable. Thanks.
>
> Regards,
> Abhishek S
>
>
>

Re: [EXTERNAL] TC 8.0.0

[Jeremy Mitchell]

So I, personally, would prefer a 7.1 with an API 4.1 to provide the
backwards compatibility jonathan speaks of...unless there is something that
absolutely requires api 5.x..

On Tue, Aug 23, 2022 at 10:53 AM Gray, Jonathan
 wrote:

> The lack of TO API backward compatibility support is causing me whiplash
> as a consumer of that API and continues to add development and support
> costs with each upgrade.
>
> Jonathan G
>
> From: Jeremy Mitchell 
> Date: Tuesday, August 23, 2022 at 10:10 AM
> To: dev@trafficcontrol.apache.org 
> Subject: [EXTERNAL] TC 8.0.0
> I was just curious what the justification for TC 8.0 was. We are rolling
> majors pretty quick (not sure that's a bad thing) and was just wondering if
> there was a "big" change i was unaware of and apologies for missing the
> working group where this was probably discussed.
>
> I'm guessing i know the reason: TO API 5.x? which does worry me a bit
> because i believe that means API 3.x will be deprecated / on the chopping
> block.
>
> Jeremy
>

TC 8.0.0

[Jeremy Mitchell]

I was just curious what the justification for TC 8.0 was. We are rolling
majors pretty quick (not sure that's a bad thing) and was just wondering if
there was a "big" change i was unaware of and apologies for missing the
working group where this was probably discussed.

I'm guessing i know the reason: TO API 5.x? which does worry me a bit
because i believe that means API 3.x will be deprecated / on the chopping
block.

Jeremy

Re: 2022-08-23 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

> Jeremy doesn't want an 8.0.0

not that i don't want it. just want to understand the reasoning? something
big planned to warrant it? i'll start a thread. sorry i missed the last few
working groups.

On Tue, Aug 23, 2022 at 9:30 AM ocket   wrote:

> 1. Attendance
> - Zach Hoffman
> - Taylor Frey
> - Stephen Hamrick
> - Eric Holguin
> - Srijeet Chatterjee
> - Joshua Zenn
> 2. ML: Vote on 7.0.1-RC
> - Should we drop the minimum 72-hours requirement?
> - It's ultimately up to the Release Manager, so we can just
> remove it from the voting email template.
> 3. Jeremy doesn't want an 8.0.0
> - That should be discussed on the mailing list.
>
> On Tue, Aug 23, 2022 at 9:20 AM Zach Hoffman  wrote:
> >
> > Active mailing list threads:
> > - [VOTE] Release Apache Traffic Control 7.0.1-RC0 <
> > https://lists.apache.org/thread/fy4vrs4zk5y2k99kcznp0z6xcnbjyq9k>
> >
> > On Tue, Aug 16, 2022 at 9:36 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 7.0.1-RC0

[Jeremy Mitchell]

+1

On Wed, Aug 17, 2022 at 1:01 PM Steve Hamrick  wrote:

> Correction, the vote will remain open for at least 72 hours and will close
> *after* *19:00 UTC August 20th*.
>
> Thanks,
> Steve Hamrick shamr...@apache.org
>
>
> On Wed, Aug 17, 2022 at 12:54 PM Steve Hamrick 
> wrote:
>
> > Hello All,
> >
> > I've prepared a release for 7.0.1-RC0. Changes since RELEASE-7.0.0
> >
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-7.0.0...RELEASE-7.0.1-RC0
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-7.0.1-RC0/CHANGELOG.md
> >
> > The artifacts are available for download at:
> >
> >   https://dist.apache.org/repos/dist/dev/trafficcontrol/7.0.1/RC0
> >
> > BLAKE2 checksum:
> >
> 2838f959fa8832cbdf6ea35c8271b4e8c17996f53d91817b6a55c619a0006c4686fa7ecde0fa76cd40b9e327ab8e738c0e5fd1e7d9e5e8acc795f5e9cd38d0f5
> apache-trafficcontrol-7.0.1.tar.gz
> >
> >
> >
> >
> > SHA512 checksum:
> >
> fc6c7328979d0ed369bb76ac6bd2a961aa626f905bb8a9e192f2ca703e2f888053ebd4b5e63381023229b9f2544cf1161f55c59e38ab6a82ac9aef52f7e8462f
> apache-trafficcontrol-7.0.1.tar.gz
> >
> >
> > This corresponds to git refs:
> >
> >   Hash: c076b138a88d21daf1a17d594b83f4c03020c179
> >   Tag: RELEASE-7.0.1-RC0
> >
> > Which can be verified with the following command:
> >
> >   $ git tag -v RELEASE-7.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.
> >
> > The vote will remain open for at least 72 hours (15:00 UTC on Sunday,
> > July 24th) and passes if a majority of at least 3 +1 PMC votes are
> > cast.
> >   [ ] +1 approve
> >   [ ] +0 no opinion
> >   [ ] -1 disapprove (and reason why)
> >
> > Thanks!
> > Steve Hamrick shamr...@apache.org
> >
> >
>

Re: 2022-08-16 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Our goal is quarterly releases. 7.0 was the Q2 release. What is the Q3
release going to be? 7.1, 8.0?

On Tue, Aug 16, 2022 at 9:12 AM Steve Hamrick  wrote:

> Discuss View Profile > DS's TP bug in 7.0.0.
>
> On Tue, Aug 9, 2022 at 10:16 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 7.0.0-RC2

[Jeremy Mitchell]

+1. We've had RC2 in a production environment for almost a week.

On Fri, Jul 22, 2022 at 12:06 PM Zach Hoffman  wrote:

> +1, weasel passes, and default and optional components build as expected
>
> -Zach
>
> On Thu, Jul 21, 2022 at 10:44 AM Steve Hamrick 
> wrote:
>
> > Hello All,
> >
> > I've prepared a release for 7.0.0-RC2. Changes since RELEASE-6.1.0
> >
> >
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-6.1.0...RELEASE-7.0.0-RC2
> >
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-7.0.0-RC2/CHANGELOG.md
> >
> > The artifacts are available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/7.0.0/RC2
> >
> > Change since previous RCs
> >
> >
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-7.0.0-RC0..RELEASE-7.0.0-RC2
> >
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-7.0.0-RC1..RELEASE-7.0.0-RC2
> >
> > BLAKE2 checksum:
> >
> >
> 64451309b850a3381a18f78a0ed48531c2bb970dc4909d20257eb6686afb94f3e3e114e42439f8c6edf7fee0b08739968628eac7df2dc138cffd34eb7b08b736
> >  apache-trafficcontrol-7.0.0.tar.gz
> >
> >
> >
> > SHA512 checksum:
> >
> >
> 8177d4123c507ccb43e10145931c03f9baa53c790499ebc6912d5d8e768ac953f57c29ec97e92012d05a16f11a7f2e0fadd29595b785e3f565181327b44ba969
> >  apache-trafficcontrol-7.0.0.tar.gz
> >
> >
> > This corresponds to git refs:
> >
> > Hash: ffcd4b26521b711996eaab1b415893251b7c439
> > Tag: RELEASE-7.0.0-RC2
> >
> > Which can be verified with the following command:
> >
> > $ git tag -v RELEASE-7.0.0-RC2
> >
> > 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.
> >
> > The vote will remain open for at least 72 hours (15:00 UTC on Sunday,
> > July 24th) and passes if a majority of at least 3 +1 PMC votes are
> > cast.
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Thanks!
> > Steve Hamrick shamr...@apache.org
> >
>

Re: 2022-07-12 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Let's review the 7.0 milestone
 and also discuss
any new/existing regression bugs

to see if we're ready for a release.

On Wed, Jul 6, 2022 at 10:49 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-05 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

1. Attendance
- Eric Holguin
- Srijeet Chatterjee
- Taylor Frey
- Juliet Ngwe
- Jeremy Mitchell
- Solomon Bosco
2. Open Floor: 7.0.0 Milestone
<https://github.com/apache/trafficcontrol/milestone/26> review
- #6917 <https://github.com/apache/trafficcontrol/pull/6917>
(documentation changes) in review currently by Eric Holguin
- #6912 <https://github.com/apache/trafficcontrol/pull/6912> regression bug
fix that still needs a reviewer
- #6697 <https://github.com/apache/trafficcontrol/issues/6697> in
progress
- In addtion, we have 11 open regression bugs
<https://github.com/apache/trafficcontrol/issues?q=is%3Aissue+is%3Aopen+label%3A%22regression+bug%22>
- 4 appear to have been introduced since our last official release - status
of those as blockers is
ultimately up to the RM: Stephen Hamrick

On Tue, Jul 5, 2022 at 9:19 AM Jeremy Mitchell 
wrote:

> Let's look at the progress of the 7.0 milestone
>
> On Tue, Jun 28, 2022 at 9:38 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-05 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Let's look at the progress of the 7.0 milestone

On Tue, Jun 28, 2022 at 9:38 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-05-31 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Attendance
- Zach Hoffman
- Jeremy Mitchell
- Stephen Hamrick
- Srijeet Chatterjee
- Amy Wilson
2. Usage of EPEL ATS 9
- zach created an issue to facilitate discussion:
https://github.com/apache/trafficcontrol/issues/6871
3. 7.0.0 milestone <https://github.com/apache/trafficcontrol/milestone/26>
update:
- Squash migrations PR
<https://github.com/apache/trafficcontrol/pull/6802> still in review
- 2 new PRs added to handle removal of API v2 by Zach:
- Grove PR <https://github.com/apache/trafficcontrol/pull/6868> -
requested review from Rob Butts
- Tools PR <https://github.com/apache/trafficcontrol/pull/6869> -
needs reviewer(s)

On Tue, May 31, 2022 at 9:19 AM Jeremy Mitchell 
wrote:

> update on milestone 7.0 status -
> https://github.com/apache/trafficcontrol/milestone/26
>
> On Tue, May 31, 2022 at 9:15 AM Zach Hoffman  wrote:
>
>> Consider discussing:
>>
>> ATS 9 will likely be in EPEL within the next week <
>>
>> https://github.com/apache/trafficserver/issues/6855#issuecomment-1136490669
>> >,
>> but hard-coded `/opt/trafficserver/*` paths are still always used in some
>> places <https://github.com/apache/trafficcontrol/issues/6198>, so we are
>> not yet ready for stock ATS
>>
>> On Tue, May 24, 2022 at 9:41 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-05-31 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

update on milestone 7.0 status -
https://github.com/apache/trafficcontrol/milestone/26

On Tue, May 31, 2022 at 9:15 AM Zach Hoffman  wrote:

> Consider discussing:
>
> ATS 9 will likely be in EPEL within the next week <
> https://github.com/apache/trafficserver/issues/6855#issuecomment-1136490669
> >,
> but hard-coded `/opt/trafficserver/*` paths are still always used in some
> places , so we are
> not yet ready for stock ATS
>
> On Tue, May 24, 2022 at 9:41 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-05-10 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

was an email going to be sent to discuss marking issue/PRs stale?

On Tue, May 10, 2022 at 9:21 AM Jeremy Mitchell 
wrote:

> let's talk about 7.0 status
>
> On Tue, May 10, 2022 at 9:16 AM Zach Hoffman  wrote:
>
>> Consider discussing:
>> - As of this last week, we have C++ code scanning alerts. What other
>> static
>> analysis should we add?
>>
>> Active mailing list threads:
>> - Blueprint: Cache Config Service <
>> https://lists.apache.org/thread/7wsffkd52r21dmwkjxyl0cnqnhdjgm99>
>>
>> -Zach
>>
>> On Tue, May 3, 2022 at 10:16 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-05-10 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

let's talk about 7.0 status

On Tue, May 10, 2022 at 9:16 AM Zach Hoffman  wrote:

> Consider discussing:
> - As of this last week, we have C++ code scanning alerts. What other static
> analysis should we add?
>
> Active mailing list threads:
> - Blueprint: Cache Config Service <
> https://lists.apache.org/thread/7wsffkd52r21dmwkjxyl0cnqnhdjgm99>
>
> -Zach
>
> On Tue, May 3, 2022 at 10:16 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: Can we get rid of /servers/details yet?

[Jeremy Mitchell]

looks like we use it a bunch at comcast still

On Tue, Apr 26, 2022 at 5:50 PM ocket   wrote:

> Well it needs to be deprecated first, but as of right now it could be
> deprecated in 3.x and removed in 4.x
>
> On Tue, Apr 26, 2022, 15:54 Jeremy Mitchell  wrote:
>
> > does it first need to be deprecated before being removed? i.e. deprecated
> > in 4.x and removed in 5.x
> >
> > On Tue, Apr 26, 2022 at 1:15 PM ocket   wrote:
> >
> > > AFAIK the only difference between this and /servers is that
> > > /servers/details is missing some things (e.g. routerPortName) that
> > > exist on /servers servers, but they have this "hwinfo" property. Even
> > > in APIv1 /hwinfo was read-only and now that endpoint no longer exists
> > > (removed in v2). "Hwinfo" as a concept has sort of passed into
> > > obscurity as new servers can't have it as of at least a little more
> > > than a year ago.
> > >
> > > Remembering to update an unused endpoint is difficult, and actually
> > > doing so is annoying. As a result, the object definitions between
> > > /servers and /servers/details have drifted to the point that I'm not
> > > sure how the latter could possibly be useful anymore. Which will
> > > likely continue unless we just get rid of it.
> > >
> >
>

Re: Can we get rid of /servers/details yet?

[Jeremy Mitchell]

does it first need to be deprecated before being removed? i.e. deprecated
in 4.x and removed in 5.x

On Tue, Apr 26, 2022 at 1:15 PM ocket   wrote:

> AFAIK the only difference between this and /servers is that
> /servers/details is missing some things (e.g. routerPortName) that
> exist on /servers servers, but they have this "hwinfo" property. Even
> in APIv1 /hwinfo was read-only and now that endpoint no longer exists
> (removed in v2). "Hwinfo" as a concept has sort of passed into
> obscurity as new servers can't have it as of at least a little more
> than a year ago.
>
> Remembering to update an unused endpoint is difficult, and actually
> doing so is annoying. As a result, the object definitions between
> /servers and /servers/details have drifted to the point that I'm not
> sure how the latter could possibly be useful anymore. Which will
> likely continue unless we just get rid of it.
>

Re: 2022-04-19 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

let's discuss TC 7.0 and the progress on the milestone if  any:
https://github.com/apache/trafficcontrol/milestone/26

On Tue, Apr 12, 2022 at 10:02 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.
>

supported API versions

[Jeremy Mitchell]

Is there a place I'm unaware of that shows which API versions are supported
for a given TC release? something like this:

TC 6.1.x:
- API 4.x unstable
- API 3.x stable
- API 2.x deprecated

i think i can dig thru the api documentation to figure this out but didn't
feel like digging. anyhow, maybe if we don't have this, it could go here?
although that doesn't seem quite right:
https://github.com/apache/trafficcontrol/security/policy

Jeremy

Re: 2022-03-29 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

let's discuss what needs to be done to get ready for our Q2 release: TC
7.0.0

On Tue, Mar 29, 2022 at 9:19 AM Zach Hoffman  wrote:

> Consider discussing:
>
> - Since the Docker hub now uses rate limiting, we should take
> advantage of the GitHub Container Registry to speed up our CI.
> Example: https://github.com/apache/trafficcontrol/pull/6699
> - Do we want to be notified of wiki edits in #traffic-control-commits?
>
> -Zach
>
> On Tue, Mar 22, 2022 at 9:28 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: [ACTION REQUIRED] Time to create GSoC ideas

[Jeremy Mitchell]

well, we have no shortage of new feature requests. 191 to be exact:
https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3A%22new+feature%22

The question is which would make a good GSoC project and who wants to
serves as the mentor, right?

On Wed, Feb 16, 2022 at 11:18 AM Zach Hoffman  wrote:

> Anyone have a Google Summer of Code idea to submit for Apache Traffic
> Control?
>
> To see ideas already submitted (includes 2022 and past years):
>
> https://issues.apache.org/jira/browse/COMDEV-438?jql=project=COMDEV+AND+component=%22GSoC%2FMentoring+ideas%22
>
> -Zach
>
> -- Forwarded message -
> From: Maxim Solodovnik 
> Date: Tue, Feb 15, 2022 at 9:32 PM
> Subject: [ACTION REQUIRED] Time to create GSoC ideas
> To: mentors 
>
>
> Hello mentors,
>
> As you may know GSoC 2022 is coming :)
> I'm creating application on behalf of ASF
>
> It's time to collect GSoc ideas!
> As usual the process is described here [1]
>
> There are changes in rules this year I would like to highlight:
>   1) NOT only students can apply
> so from now on "GSoC contributor" should be 18+, and should be
> "beginner contributor" [2]
>   2) there will be 2 types of projects this year ~175 hour (medium) and 350
> hour (large)
>   NOTE: there is an option to extend the standard 12 week coding time
> frame to a maximum of 22 weeks
> 3) we will provide scoring for GSoC contributors to Google for automatic
> conflict resolution
>
> Please add "*full-time*" label to the JIRA for 350 hour project OR "
> *part-time*" label for 175 hours project
>
> I'll update my scripts so this information will be available in Ideas list:
> [3]
>
> Thanks in advance!
>
>
> [1]
> https://community.apache.org/gsoc.html#prospective-asf-mentors-read-this
> [2]
>
> https://groups.google.com/g/google-summer-of-code-mentors-list/c/TRqoysISSo8/m/4pnYQo9tBAAJ?utm_medium=email_source=footer
> [3] https://s.apache.org/gsoc2022ideas
>

Re: 2022-02-15 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

honestly, i would like to see API 4.x become stable in our Q2 release. It's
been "unstable" since september 2021? Seems like we need to draw a line at
some point. things are always going to be "in progress" otherwise. imo it's
not fair to people that are coding to 4.x (to get access to new api
features) to leave it unstable for a long time. (which basically requires
them to keep an eye out for 4.x changes so they can quickly make changes if
their api consumer breaks). just my 2 cents.

On Wed, Feb 16, 2022 at 7:32 AM Eric Friedrich  wrote:

> With 4.x remaining unstable in our "Q2" release, does that remove our
> reasoning for cutting a major release?
>
> What will happen for the Q3 release when the 4.x TO API is ready? Will
> we want to cut another 8.x major release?
>
> 
> I am all for making progress to remove deprecated codes, but for many
> users (myself included), major releases present a large investment in
> effort to adopt. I think the 1, maybe 2 major release per year cadence
> is reasonable. Three or more major releases in a year would be rather
> difficult to accommodate.
>
> --Eric
>
>
> On Tue, Feb 15, 2022 at 11:28 AM Taylor Frey 
> wrote:
> >
> > 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: [EXTERNAL] Re: TC Q2 release (6.2 or 7.0?)

[Jeremy Mitchell]

Hooray for Steve!

On Fri, Feb 11, 2022 at 10:15 AM Wilson, Amy 
wrote:

> Thanks Steve. Much appreciated.
>
> ~A
>
> From: Steve Hamrick 
> Date: Friday, February 11, 2022 at 9:39 AM
> To: dev@trafficcontrol.apache.org 
> Subject: Re: [EXTERNAL] Re: TC Q2 release (6.2 or 7.0?)
> I'd be interested in being a release manager.
>
> Steve H
>
>
> On Fri, Feb 11, 2022 at 9:12 AM Jeremy Mitchell 
> wrote:
>
> > any more thoughts here? otherwise, looks like our next version will be
> 7.0
> > (api 4.x stablization and api 2.x removal tbd). this means we will need a
> > new volunteer for release manager. any volunteers?
> >
> > On Tue, Feb 8, 2022 at 4:05 PM Rawlin Peters  wrote:
> >
> > > We don't really support upgrading more than one major version at a
> > > time anyways (esp. due to things like squashing the DB migrations), so
> > > you generally need to upgrade only one major version at a time (e.g.
> > > 4.x -> 5.x -> 6.x -> 7.x).
> > >
> > > - Rawlin
> > >
> > > On Tue, Feb 8, 2022 at 3:47 PM Gray, Jonathan
> > >  wrote:
> > > >
> > > > Removing API 2.x will mean that there is no migration path from ATC
> 4.x
> > > to ATC 7 without jumping through ATC 5||6 to get to API 3.0+.  This
> might
> > > be ok, but just a reminder.  Specifically the existing ansible code
> still
> > > relies on API 2.x as well.
> > > >
> > > > Jonathan G
> > > >
> > > >
> > > > From: Rawlin Peters 
> > > > Date: Tuesday, February 8, 2022 at 3:32 PM
> > > > To: dev@trafficcontrol.apache.org 
> > > > Subject: [EXTERNAL] Re: TC Q2 release (6.2 or 7.0?)
> > > > If we decide that we're going to declare TO API 4.x stable as part of
> > > > ATC 7.0 on April 1, we're effectively setting a deadline for
> > > > work-in-progress (Layered Profiles) upon which the release hinges.
> > > > Ideally, we would wait until the Layered Profiles feature is
> > > > implemented in TO API 4.0 before we consider stabilizing TO API 4.0.
> > > > We don't want to delay the release because a new feature isn't ready
> > > > yet.
> > > >
> > > > That said, I don't see a problem with removing API 2.x and Riak
> > > > support (as well as any of those other "major" things) and calling it
> > > > ATC 7.0.
> > > >
> > > > - Rawlin
> > > >
> > > > On Tue, Feb 8, 2022 at 12:33 PM Jeremy Mitchell <
> > mitchell...@apache.org>
> > > wrote:
> > > > >
> > > > > In today's TC working group, we discussed our next official release
> > > slated
> > > > > for Q2 (April 1). We have 2 options:
> > > > >
> > > > > 1. TC 6.2.0
> > > > > 2. TC 7.0.0
> > > > >
> > > > > ^^ note: this doesn't include any patch releases we may need prior
> to
> > > April
> > > > > 1.
> > > > >
> > > > > We felt option #2 was probably the better option so we could:
> > > > >
> > > > > - stabilize API 4.x which is currently "unstable"
> > > > > - deprecate API 3.x which is currently considered "stable"
> > > > > - remove API 2.x which is currently deprecated
> > > > > - optionally (if needed) add API 5.x as "unstable" to allow more
> > > breaking
> > > > > API changes if needed
> > > > >
> > > > > In addition, we could potentially remove RIAK support
> > > > > <
> > >
> >
> https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/issues/6546__;!!CQl3mcHX2A!XgJ4rHATX7p8UEz7mVduk1HnteBDNBxQEqUFIHrEMRI4nE5CjpvAiRCK-UuVbZ2wWxcU$
> <
> https://urldefense.com/v3/__https:/github.com/apache/trafficcontrol/issues/6546__;!!CQl3mcHX2A!XgJ4rHATX7p8UEz7mVduk1HnteBDNBxQEqUFIHrEMRI4nE5CjpvAiRCK-UuVbZ2wWxcU$
> >
> > > >, introduce a
> > > > > new/replacement auth mechanism (i.e. JWT) and upgrade TR to Java 17
> > as
> > > well
> > > > > as other "major" things.
> > > > >
> > > > > Or, we could do none/subset of that and plan on a 6.2 for April.
> > > > >
> > > > > Thoughts?
> > >
> >
>

Re: [EXTERNAL] Re: TC Q2 release (6.2 or 7.0?)

[Jeremy Mitchell]

any more thoughts here? otherwise, looks like our next version will be 7.0
(api 4.x stablization and api 2.x removal tbd). this means we will need a
new volunteer for release manager. any volunteers?

On Tue, Feb 8, 2022 at 4:05 PM Rawlin Peters  wrote:

> We don't really support upgrading more than one major version at a
> time anyways (esp. due to things like squashing the DB migrations), so
> you generally need to upgrade only one major version at a time (e.g.
> 4.x -> 5.x -> 6.x -> 7.x).
>
> - Rawlin
>
> On Tue, Feb 8, 2022 at 3:47 PM Gray, Jonathan
>  wrote:
> >
> > Removing API 2.x will mean that there is no migration path from ATC 4.x
> to ATC 7 without jumping through ATC 5||6 to get to API 3.0+.  This might
> be ok, but just a reminder.  Specifically the existing ansible code still
> relies on API 2.x as well.
> >
> > Jonathan G
> >
> >
> > From: Rawlin Peters 
> > Date: Tuesday, February 8, 2022 at 3:32 PM
> > To: dev@trafficcontrol.apache.org 
> > Subject: [EXTERNAL] Re: TC Q2 release (6.2 or 7.0?)
> > If we decide that we're going to declare TO API 4.x stable as part of
> > ATC 7.0 on April 1, we're effectively setting a deadline for
> > work-in-progress (Layered Profiles) upon which the release hinges.
> > Ideally, we would wait until the Layered Profiles feature is
> > implemented in TO API 4.0 before we consider stabilizing TO API 4.0.
> > We don't want to delay the release because a new feature isn't ready
> > yet.
> >
> > That said, I don't see a problem with removing API 2.x and Riak
> > support (as well as any of those other "major" things) and calling it
> > ATC 7.0.
> >
> > - Rawlin
> >
> > On Tue, Feb 8, 2022 at 12:33 PM Jeremy Mitchell 
> wrote:
> > >
> > > In today's TC working group, we discussed our next official release
> slated
> > > for Q2 (April 1). We have 2 options:
> > >
> > > 1. TC 6.2.0
> > > 2. TC 7.0.0
> > >
> > > ^^ note: this doesn't include any patch releases we may need prior to
> April
> > > 1.
> > >
> > > We felt option #2 was probably the better option so we could:
> > >
> > > - stabilize API 4.x which is currently "unstable"
> > > - deprecate API 3.x which is currently considered "stable"
> > > - remove API 2.x which is currently deprecated
> > > - optionally (if needed) add API 5.x as "unstable" to allow more
> breaking
> > > API changes if needed
> > >
> > > In addition, we could potentially remove RIAK support
> > > <
> https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/issues/6546__;!!CQl3mcHX2A!XgJ4rHATX7p8UEz7mVduk1HnteBDNBxQEqUFIHrEMRI4nE5CjpvAiRCK-UuVbZ2wWxcU$
> >, introduce a
> > > new/replacement auth mechanism (i.e. JWT) and upgrade TR to Java 17 as
> well
> > > as other "major" things.
> > >
> > > Or, we could do none/subset of that and plan on a 6.2 for April.
> > >
> > > Thoughts?
>

TC Q2 release (6.2 or 7.0?)

[Jeremy Mitchell]

In today's TC working group, we discussed our next official release slated
for Q2 (April 1). We have 2 options:

1. TC 6.2.0
2. TC 7.0.0

^^ note: this doesn't include any patch releases we may need prior to April
1.

We felt option #2 was probably the better option so we could:

- stabilize API 4.x which is currently "unstable"
- deprecate API 3.x which is currently considered "stable"
- remove API 2.x which is currently deprecated
- optionally (if needed) add API 5.x as "unstable" to allow more breaking
API changes if needed

In addition, we could potentially remove RIAK support
, introduce a
new/replacement auth mechanism (i.e. JWT) and upgrade TR to Java 17 as well
as other "major" things.

Or, we could do none/subset of that and plan on a 6.2 for April.

Thoughts?

Re: 2022-02-08 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Now that 6.1.0 is official, do we want to start thinking about our next
official release planned for April 1 (start of Q2)? Are we thinking this
will be 6.2.x or 7.0.x?

On Tue, Feb 1, 2022 at 9:36 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 6.1.0-RC2

[Jeremy Mitchell]

+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://github.com/apache/trafficcontrol/compare/RELEASE-6.0.2...RELEASE-6.1.0-RC2
>
> https://github.com/apache/trafficcontrol/blob/RELEASE-6.1.0-RC2/CHANGELOG.md
>
> The artifacts are available for download at:
>
> https://dist.apache.org/repos/dist/dev/trafficcontrol/6.1.0/RC2/
>
> 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://dist.apache.org/repos/dist/release/trafficcontrol/KEYS
>
> 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: [RESULT][VOTE] Release Apache Traffic Control 6.1.0-RC1

[Jeremy Mitchell]

:( sorry about that...

On Tue, Jan 25, 2022 at 9:00 AM Zach Hoffman  wrote:

> Voting for ATC 6.1.0 Release Candidate 1 has closed. 6.1.0 RC1 fails with
> 0 +1 votes and 0 -1 votes.
>
> +-++++
> | PMC member  | +1 | +0 | -1 |
> +-++++
> | covener ||||
> +-++++
> | dangogh ||||
> +-++++
> | dewrich ||||
> +-++++
> | dgelinas||||
> +-++++
> | elsloo  ||||
> +-++++
> | friede  ||||
> +-++++
> | hbeatty ||||
> +-++++
> | jvd ||||
> +-++++
> | mitchell852 ||||
> +-++++
> | mtorluemke  ||||
> +-++++
> | neuman  ||||
> +-++++
> | ocket   ||||
> +-++++
> | rawlin  ||||
> +-++++
> | rob ||||
> +-++++
> | smalenfant  ||||
> +-++++
> | sorber  ||||
> +-++++
> | zrhoffman   ||||
> +-++++
> | zwoop   ||||
> +-++++
>
> Voting results can be found here: <
> https://lists.apache.org/thread/0qks6x1jd0gv2qnb1odm5zp2ofocgjjy>
>
> I will cut another 6.1.0 release candidate early next week.
>
> -Zach
>

Re: [VOTE] Release Apache Traffic Control 5.1.6-RC0

[Jeremy Mitchell]

+1

On Thu, Jan 20, 2022 at 11:50 AM Zach Hoffman  wrote:

> +1
>
> On Tue, Jan 18, 2022 at 11:07 PM ocket   wrote:
> >
> > Hello All,
> >
> > I've prepared a release for 5.1.6-RC0. Changes since RELEASE-5.1.5:
> >
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.5...RELEASE-5.1.6-RC0
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-5.1.6-RC0/CHANGELOG.md
> >
> > The artifacts are available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/5.1.6/RC0/
> >
> > SHA512 checksum:
> >
> fc8ec80a591d496adf98dbf641d5d88a94a80015045e865c741b129d1e18cb001cdf499c324ace37b563b7af8de9cdb70c1e33d70865f15e63d2f1a4dde4dc0d
> >
> > This corresponds to git refs:
> >
> > Hash: e4d38dbd57b1ee9143db19f9201a83b36f68aae7
> > Tag: RELEASE-5.1.6-RC0
> >
> > Which can be verified with the following command:
> >
> > $ git tag -v RELEASE-5.1.6-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.
> >
> > The vote is open until 06:06:00 UTC on Saturday, January 22 and passes
> > if a majority of at least 3 +1 PMC votes are cast.
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> >
> > Thanks!
> > ocket ocket8...@gmail.com
>

change log entry improvement

[Jeremy Mitchell]

In today's TC working group, we discussed improving change log entries to
include all components touched by the change.

example:

Fixes #5739 - Prevent looping in case of a failed login attempt

would be changed to:

Fixes #5739 - Prevent looping in case of a failed login attempt (TO, TM, TR)

This would enable release managers to create release notes grouped by
component such as:

https://github.com/apache/trafficcontrol/releases/tag/RELEASE-6.0.0

thoughts? concerns?

if this sounds ok, Taylor is going to add the suggestion to the PR template.

Re: 2022-01-18 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Maybe we can put some impact and effort labels on the following tech debt
items:

https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3A%22tech+debt%22++-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22

On Tue, Jan 18, 2022 at 9:14 AM Jeremy Mitchell 
wrote:

> Status of 6.1
>
> On Tue, Jan 11, 2022 at 9:43 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-18 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Status of 6.1

On Tue, Jan 11, 2022 at 9:43 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: Layered Profiles Blueprint

[Jeremy Mitchell]

yep, do what rob said. thanks for the guidance rob.

On Wed, Jan 12, 2022 at 9:23 AM Steve Malenfant 
wrote:

> Thanks Rob, I’ll do some cleanup and see how that goes.
>
> On Wed, Jan 12, 2022 at 10:34 AM Robert O Butts  wrote:
>
> > > In the past, these DS specific parameters have been causing
> > trouble(cloning an older profile with a DS that doesn't exist anymore,
> but
> > location still does). Is there anything in this blueprint that helps with
> > that?
> >
> > Since ATC 5.0 all Delivery Service specific config files are inferred,
> and
> > no longer require location Parameters.
> >
> > Just delete your url_sig_ and other DS (uri_signing_, hdr_rw_,
> > regex_remap_) location Parameters, and the files will be created when
> > necessary.
> >
> >
> > On Tue, Jan 11, 2022 at 10:23 PM Steve Malenfant 
> > wrote:
> >
> > > Jeremy,
> > >
> > > I missed this whole discussion. I really noticed by checking the latest
> > > commit. I'm sorry if I miss anything prior to that.
> > >
> > > I saw in the blueprint this parameter as an example:
> > > | Name |Config File
> > >   | Value| Profile   |
> > >
> > >
> >
> |--|--|--|---|
> > > | location |
> url_sig_myds.config
> > >| /opt/trafficserver/etc/trafficserver | EDGE  |
> > >
> > > In the past, these DS specific parameters have been causing trouble
> > > (cloning an older profile with a DS that doesn't exist anymore, but
> > > location still does). Is there anything in this blueprint that helps
> with
> > > that?
> > >
> > > Steve
> > >
> > > On Mon, Dec 13, 2021 at 11:44 AM Jeremy Mitchell <
> mitchell...@gmail.com>
> > > wrote:
> > >
> > > > Hi everyone. If you have feedback for Rima on her blueprint, may I
> ask
> > > that
> > > > you get it in this week so we can move forward with the development
> of
> > > this
> > > > feature: https://github.com/apache/trafficcontrol/pull/6095
> > > >
> > > > 4 months is probably ample time :)
> > > >
> > > > thanks!
> > > >
> > > > On Tue, Aug 10, 2021 at 12:46 PM Shah, Rima
> > >  > > > >
> > > > wrote:
> > > >
> > > > > Hello All,
> > > > >
> > > > >
> > > > > I’ve opened a PR to propose a new feature for Traffic Control:
> > Layered
> > > > > Profiles. Layered Profiles allow assigning multiple profiles, in
> > order,
> > > > to
> > > > > both Servers and Delivery Services. Layered Profiles is exactly as
> > > > powerful
> > > > > as the existing profiles, it doesn't enable any new things. It
> makes
> > > > > profiles much easier to manage.
> > > > >
> > > > > Please take a look at it and let me know your thoughts.
> > > > >
> > > > > The blueprint can be found at:
> > > > > https://github.com/apache/trafficcontrol/pull/6095
> > > > >
> > > > >
> > > > > Thanks and Regard,
> > > > > Rima Shah
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [EXTERNAL] Re: 6.1.0 Planning

[Jeremy Mitchell]

@jonathan - the in progress "layered server profiles
<https://github.com/apache/trafficcontrol/blob/master/blueprints/layered-profile-server.md>"
requires 4.0 remain unstable if i recall correctly, therefore, TC 6.1 will
still have an unstable API 4.0. maybe our next release for march is 7.0
with a stable api 4.0 and an unstable 5.x?

On Thu, Jan 6, 2022 at 11:01 AM Gray, Jonathan
 wrote:

> With 6.1.0 should API 4.0 be considered stable or is there still
> outstanding work in flight?
>
> Jonathan G
>
> From: Zach Hoffman 
> Date: Thursday, January 6, 2022 at 10:09 AM
> To: dev@trafficcontrol.apache.org 
> Subject: [EXTERNAL] Re: 6.1.0 Planning
> If there's anything anyone else wants included in 6.1.0, let's try to
> get it in before the expected 6.1.0 release branch cut date
> 2021-01-11.
>
> -Zach
>
> On Thu, Jan 6, 2022 at 10:06 AM Zach Hoffman  wrote:
> >
> > In the 2021-01-04 TC working group, we went through open issues and
> > PRs and put together the 6.1.0 milestone
> > <
> https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/milestone/19__;!!CQl3mcHX2A!XEggSAgJjuxCs_cjtUY4Lqa1Y4wdsC-fw0IpB_qsl1glGMFx4QvrrCSgGY9GPoDpAgs6$
> >:
> > - Replace github.com/dgrijalva/jwt-go with
> github.com/lestrrat-go/jwx/jwt
> > - Create a secure parameter read permission to be able to see the
> > values of secure parameters
> > - Remove postgresql13-devel package dependency from Traffic Ops rpm
> > - Revert automatic log rotation Log4J configuration
> >
> > -Zach
> >
> > On Thu, Jan 6, 2022 at 10:04 AM Eric Friedrich 
> wrote:
> > >
> > > Sounds good, Thanks Zach.
> > >
> > > How's the state of master? Are we feeling good that its ready to cut a
> > > release off of?
> > >
> > > On Thu, Jan 6, 2022 at 11:16 AM Jeremy Mitchell 
> wrote:
> > > >
> > > > +1
> > > >
> > > > On Thu, Jan 6, 2022 at 9:13 AM Zach Hoffman 
> wrote:
> > > >
> > > > > Planning to cut the 6.1.0 release branch from master on Tuesday,
> January
> > > > > 11.
> > > > >
> > > > > -Zach
> > > > >
>

Re: 6.1.0 Planning

[Jeremy Mitchell]

+1

On Thu, Jan 6, 2022 at 9:13 AM Zach Hoffman  wrote:

> Planning to cut the 6.1.0 release branch from master on Tuesday, January
> 11.
>
> -Zach
>

Re: 2022-01-04 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

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: New committer: Srijeet Chatterjee

[Jeremy Mitchell]

Congrats Srijeet!

On Mon, Jan 3, 2022 at 8:29 AM Zach Hoffman  wrote:

> The Project Management Committee (PMC) for Apache Traffic Control has
> invited Srijeet Chatterjee to become a committer, and we are pleased
> to announce that he has accepted!
>
> Since April 2020, Srijeet has authored 84 merged Pull Requests, fixing
> 46 Issues across various ATC components. In addition to contributing
> to numerous projects in the last 21 months, Sijeet implemented
> If-Modified-Since and If-Unmodified-Since header support in Traffic
> ops, and, more recenly, blueprinted and implemented CDN Locks before
> presenting it at ApacheCon@Home 2021.
>
> 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.
>
> -Zach
>

Re: [VOTE] Release Apache Traffic Control 5.1.5-RC0

[Jeremy Mitchell]

+1

On Mon, Dec 20, 2021 at 2:47 PM ocket   wrote:

> And actually the 23rd is a Thursday.
>

Re: [VOTE] Release Apache Traffic Control 6.0.2-RC2

[Jeremy Mitchell]

+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://github.com/apache/trafficcontrol/compare/RELEASE-6.0.1...RELEASE-6.0.2-RC2
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-6.0.2-RC2/CHANGELOG.md
> >
> > The artifacts are available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/6.0.2/RC2/
> >
> > 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://dist.apache.org/repos/dist/release/trafficcontrol/KEYS
> >
> > 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: 2021-12-14 Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Can we add impact/effort labels to our tech debt issues to help determine
priority:
https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3A%22tech+debt%22+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+

On Tue, Dec 7, 2021 at 10:17 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: Layered Profiles Blueprint

[Jeremy Mitchell]

Hi everyone. If you have feedback for Rima on her blueprint, may I ask that
you get it in this week so we can move forward with the development of this
feature: https://github.com/apache/trafficcontrol/pull/6095

4 months is probably ample time :)

thanks!

On Tue, Aug 10, 2021 at 12:46 PM Shah, Rima 
wrote:

> Hello All,
>
>
> I’ve opened a PR to propose a new feature for Traffic Control: Layered
> Profiles. Layered Profiles allow assigning multiple profiles, in order, to
> both Servers and Delivery Services. Layered Profiles is exactly as powerful
> as the existing profiles, it doesn't enable any new things. It makes
> profiles much easier to manage.
>
> Please take a look at it and let me know your thoughts.
>
> The blueprint can be found at:
> https://github.com/apache/trafficcontrol/pull/6095
>
>
> Thanks and Regard,
> Rima Shah
>
>

Re: GH issue labels to help determine priority

[Jeremy Mitchell]

or better yet, even help close some of the `[TC-XYZ]` issues as i'm
guessing many of them are no longer relevant...

On Tue, Dec 7, 2021 at 12:15 PM Jeremy Mitchell 
wrote:

> @eric - sure, maybe others can help you with your issues that start with
> `[TC-XYZ]` as you simply created them during the issue migration:
>
>
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort%22+author%3A%22limited%22+
>
>
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+author%3A%22limited%22
>
> On Tue, Dec 7, 2021 at 10:39 AM Eric Friedrich 
> wrote:
>
>> I have plenty of issues under my username which were opened when we
>> automated the transfer from Jira to Github. I dont have the context
>> needed to be able to mark impact/effort.
>>
>> Is there anyone who could help filter through those?
>>
>> --Eric
>>
>> On Tue, Dec 7, 2021 at 12:30 PM Jeremy Mitchell 
>> wrote:
>> >
>> > Just a reminder if you haven't added impact and/or effort labels to your
>> > issues, please do so (if you have a rough estimate) to help with issue
>> > prioritization. If you are unable to add labels, please reach out to a
>> > project committer for help. Committers are documented here:
>> > https://projects.apache.org/committee.html?trafficcontrol
>> >
>> > your own issues with no "impact" label:
>> >
>> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+author%3A%40me
>> >
>> > your own issues with no "effort" label:
>> >
>> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+
>> > effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort
>> > %22+author%3A%40me
>> >
>> > thanks again.
>> >
>> > On Tue, Nov 30, 2021 at 11:54 AM Zach Hoffman 
>> wrote:
>> >
>> > > > Please help us apply these labels by adding them (if missing) to
>> your own
>> > > > issues with your best estimate.
>> > >
>> > > Your own issues with no "impact" label:
>> > >
>> > >
>> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+author%3A%40me
>> > >
>> > > Your own issues with no "effort" label:
>> > >
>> > >
>> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort%22+author%3A%40me
>> > >
>> > > -Zach
>> > >
>> > > On Tue, Nov 30, 2021 at 11:48 AM Jeremy Mitchell <
>> mitchell...@apache.org>
>> > > wrote:
>> > > >
>> > > > In order to help us prioritize our open issues
>> > > > <https://github.com/apache/trafficcontrol/issues> (currently at
>> 560),
>> > > the
>> > > > TC working group discussed and introduced 2 new label types:
>> > > >
>> > > > - impact (high, medium and low) <-- note: this used to be the
>> critical,
>> > > > major, medium and minor labels
>> > > > - level of effort (high, medium and low)
>> > > >
>> > > > Please help us apply these labels by adding them (if missing) to
>> your own
>> > > > issues with your best estimate. If you are unable to, please reach
>> out
>> > > to a
>> > > > committer to apply the labels. Thanks in advance!
>> > > >
>> > > >
>> > >
>> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+
>> > > >
>> > > >
>> > >
>> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort%22+
>> > > >
>> > > > ^^ filter by author == you
>> > >
>>
>

Re: GH issue labels to help determine priority

[Jeremy Mitchell]

@eric - sure, maybe others can help you with your issues that start with
`[TC-XYZ]` as you simply created them during the issue migration:

https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort%22+author%3A%22limited%22+

https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+author%3A%22limited%22

On Tue, Dec 7, 2021 at 10:39 AM Eric Friedrich 
wrote:

> I have plenty of issues under my username which were opened when we
> automated the transfer from Jira to Github. I dont have the context
> needed to be able to mark impact/effort.
>
> Is there anyone who could help filter through those?
>
> --Eric
>
> On Tue, Dec 7, 2021 at 12:30 PM Jeremy Mitchell 
> wrote:
> >
> > Just a reminder if you haven't added impact and/or effort labels to your
> > issues, please do so (if you have a rough estimate) to help with issue
> > prioritization. If you are unable to add labels, please reach out to a
> > project committer for help. Committers are documented here:
> > https://projects.apache.org/committee.html?trafficcontrol
> >
> > your own issues with no "impact" label:
> >
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+author%3A%40me
> >
> > your own issues with no "effort" label:
> >
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+
> > effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort
> > %22+author%3A%40me
> >
> > thanks again.
> >
> > On Tue, Nov 30, 2021 at 11:54 AM Zach Hoffman 
> wrote:
> >
> > > > Please help us apply these labels by adding them (if missing) to
> your own
> > > > issues with your best estimate.
> > >
> > > Your own issues with no "impact" label:
> > >
> > >
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+author%3A%40me
> > >
> > > Your own issues with no "effort" label:
> > >
> > >
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort%22+author%3A%40me
> > >
> > > -Zach
> > >
> > > On Tue, Nov 30, 2021 at 11:48 AM Jeremy Mitchell <
> mitchell...@apache.org>
> > > wrote:
> > > >
> > > > In order to help us prioritize our open issues
> > > > <https://github.com/apache/trafficcontrol/issues> (currently at
> 560),
> > > the
> > > > TC working group discussed and introduced 2 new label types:
> > > >
> > > > - impact (high, medium and low) <-- note: this used to be the
> critical,
> > > > major, medium and minor labels
> > > > - level of effort (high, medium and low)
> > > >
> > > > Please help us apply these labels by adding them (if missing) to
> your own
> > > > issues with your best estimate. If you are unable to, please reach
> out
> > > to a
> > > > committer to apply the labels. Thanks in advance!
> > > >
> > > >
> > >
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+
> > > >
> > > >
> > >
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort%22+
> > > >
> > > > ^^ filter by author == you
> > >
>

Re: GH issue labels to help determine priority

[Jeremy Mitchell]

Just a reminder if you haven't added impact and/or effort labels to your
issues, please do so (if you have a rough estimate) to help with issue
prioritization. If you are unable to add labels, please reach out to a
project committer for help. Committers are documented here:
https://projects.apache.org/committee.html?trafficcontrol

your own issues with no "impact" label:
https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+author%3A%40me

your own issues with no "effort" label:
https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+
effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort
%22+author%3A%40me

thanks again.

On Tue, Nov 30, 2021 at 11:54 AM Zach Hoffman  wrote:

> > Please help us apply these labels by adding them (if missing) to your own
> > issues with your best estimate.
>
> Your own issues with no "impact" label:
>
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+author%3A%40me
>
> Your own issues with no "effort" label:
>
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort%22+author%3A%40me
>
> -Zach
>
> On Tue, Nov 30, 2021 at 11:48 AM Jeremy Mitchell 
> wrote:
> >
> > In order to help us prioritize our open issues
> > <https://github.com/apache/trafficcontrol/issues> (currently at 560),
> the
> > TC working group discussed and introduced 2 new label types:
> >
> > - impact (high, medium and low) <-- note: this used to be the critical,
> > major, medium and minor labels
> > - level of effort (high, medium and low)
> >
> > Please help us apply these labels by adding them (if missing) to your own
> > issues with your best estimate. If you are unable to, please reach out
> to a
> > committer to apply the labels. Thanks in advance!
> >
> >
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+
> >
> >
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort%22+
> >
> > ^^ filter by author == you
>

Re: 2021-12-07 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Can we add some "impact" and "effort" labels to our tech debt items to help
people prioritize them?
https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3A%22tech+debt%22

On Tue, Dec 7, 2021 at 9:09 AM Jeremy Mitchell 
wrote:

> Do we plan to remove Riak as an option for Traffic Vault now that Postgres
> TV is available?
>
> On Tue, Nov 30, 2021 at 10:16 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: 2021-12-07 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Do we plan to remove Riak as an option for Traffic Vault now that Postgres
TV is available?

On Tue, Nov 30, 2021 at 10:16 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
>

GH issue labels to help determine priority

[Jeremy Mitchell]

In order to help us prioritize our open issues
 (currently at 560), the
TC working group discussed and introduced 2 new label types:

- impact (high, medium and low) <-- note: this used to be the critical,
major, medium and minor labels
- level of effort (high, medium and low)

Please help us apply these labels by adding them (if missing) to your own
issues with your best estimate. If you are unable to, please reach out to a
committer to apply the labels. Thanks in advance!

https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+impact%22+-label%3A%22medium+impact%22+-label%3A%22low+impact%22+

https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+-label%3A%22high+effort%22+-label%3A%22medium+effort%22+-label%3A%22low+effort%22+

^^ filter by author == you

Re: 2021-11-30 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Should we consider changing
https://github.com/apache/trafficcontrol/blob/master/VERSION to "master"
rather than a version number?

On Tue, Nov 23, 2021 at 9: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
>
> Rolling over from last week:
> - Bash 3.x no longer works with pkg
>

Re: TR Ultimate Test Harness blueprint

[Jeremy Mitchell]

Thanks Zach! by the way, i'm sure most know this but you can view the
rendered text here:
https://github.com/apache/trafficcontrol/pull/6358/files?short_path=cd015d3#diff-cd015d3849e531f0b3c651f611c5089a7145375c572e19b948eacecd79850b17

On Thu, Nov 18, 2021 at 9:05 AM Zach Hoffman  wrote:

> Hi ATC,
>
> I've opened a PR for a blueprint for the Traffic Router Ultimate Test
> Harness ,
> previously demoed at ApacheCon@Home 2021
> .
>
> Please read it and post your thoughts.
>
> Thanks!
>
> -Zach
>

Re: Making Use of GitHub Triage role

[Jeremy Mitchell]

+1

On Tue, Nov 16, 2021 at 9:42 AM ocket   wrote:

> +1
>
> On Tue, Oct 26, 2021 at 8:57 AM Zach Hoffman  wrote:
> >
> > Hi ATC,
> >
> > Besides the Maintain GitHub role (which ASF committers get), there is
> > a Triage role that lets the user:
> >
> > - Apply/dismiss labels
> > - Close, reopen, and assign all issues and pull requests
> > - Apply milestones
> > - Mark duplicate issues and pull requests
> > - Request pull request reviews
> >
> > Like most Apache repos, ours as a .asf.yaml file
> > , and any GitHub user added to a
> > `github.collaborators` list in our .asf.yaml will be granted the
> > GitHub Triage role for our repo only, until that username is removed
> > from the list.
> >
> > We could potentially take advantage of this feature by granting a
> > Triage role to active ATC contributors who are not (yet) committers,
> > if we think they could be useful for applying labels to Issues and PRs
> > or for closing stale Issues that no longer apply.
> >
> > Who would we want to grant the triage role? Perhaps non-committer
> > contributors who have over 5 commits in the past month? And then maybe
> > we could later remove that role for contributors who no longer meet
> > that mark.
> >
> > -Zach
>

Re: 2021-11-16 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

Are we planning a 6.0.2? This seems like a good fix to ensure the
successful migration from riak to the postgres traffic vault:
https://github.com/apache/trafficcontrol/pull/6353

On Tue, Nov 16, 2021 at 9:04 AM Jeremy Mitchell 
wrote:

> I'd like to try to assign a severity level (critical, major, medium,
> minor) to our tech debt issues:
> https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3A%22tech+debt%22
>
> On Tue, Nov 9, 2021 at 9:40 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: 2021-11-16 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

I'd like to try to assign a severity level (critical, major, medium, minor)
to our tech debt issues:
https://github.com/apache/trafficcontrol/issues?q=is%3Aopen+is%3Aissue+label%3A%22tech+debt%22

On Tue, Nov 9, 2021 at 9:40 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 6.0.1-RC0

[Jeremy Mitchell]

+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

[Jeremy Mitchell]

+1

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: [EXTERNAL] Re: [PROPOSAL] ATC Release Schedule

[Jeremy Mitchell]

More frequent releases require planning, decisions, voting, etc. All things
that we have limited bandwidth for, hence, the reason I originally
suggested time-boxed quarterly releases. I, personally, am still in favor
of that approach and IF a feature gets merged between official quarterly
releases and somebody wants that feature NOW, they can simply pull master
to get that feature. This however assumes that master is always
"releasable" and I think we've all agreed on that.

Jeremy

On Wed, Nov 3, 2021 at 9:24 AM Eric Friedrich 
wrote:

> I like the idea of more frequent releases. Trying to think ahead a month.
>
> Are there any problems we foresee with cutting a 6.1 RC and voting? Do
> we have a plan for how to address these, or do we just handle as
> issues arise?
> (Partial features in progress, important bugs we want to squeeze in,
> etc...)
>
> --Eric
>
> On Tue, Nov 2, 2021 at 5:45 PM Dave Neuman  wrote:
> >
> > sure, seems like what we originally agreed to :)
> >
> >
> > On Tue, Nov 2, 2021 at 3:17 PM Jeremy Mitchell 
> > wrote:
> >
> > > OK, so can we agree on this?
> > >
> > > - minor/major releases every start of a quarter (1/1, 4/1, 7/1, 10/1)
> > > - patch releases in between as determined by release manager
> > >
> > > by that logic, we may have N patch releases between now and 12/31 and
> on
> > > 1/1 we will have 6.1.0 (or 7.0 if a major is warranted).
> > >
> > > Jeremy
> > >
> > >
> > >
> > > On Wed, Oct 27, 2021 at 12:52 PM ocket  
> wrote:
> > >
> > > > Fortunately bugfixes rarely require migrations, those are usually
> only
> > > for
> > > > new features, or backporting would probably be impossible.
> > > >
> > > > On Wed, Oct 27, 2021 at 10:06 AM Jeremy Mitchell <
> mitchell...@gmail.com>
> > > > wrote:
> > > >
> > > > > Just to be clear, cherry-picks (aka backports) (from master to the
> > > > release
> > > > > branch) should be limited to bug fixes and would only apply to
> patch
> > > > > releases (i.e. 6.0.1) and I would expect the release manager to
> > > determine
> > > > > if the cherry-pick is safe or not. Yes, some can be very messy and
> > > > > dangerous and IMO those should probably be punted to the next
> release
> > > > > branch.
> > > > >
> > > > > jeremy
> > > > >
> > > > > On Wed, Oct 27, 2021 at 8:59 AM Gray, Jonathan
> > > > >  wrote:
> > > > >
> > > > > > > > why not instead ask “Is it good enough?” and “Is it better
> than
> > > > what
> > > > > we
> > > > > > presently have?” as often as possible.
> > > > > >
> > > > > > > may not help very much, because fixing a bug is always "better
> than
> > > > > what
> > > > > > we
> > > > > > presently have".
> > > > > >
> > > > > > Not always.  Sometimes the risks entailed with cherry-picking and
> > > > > > repatching bugfixes isn’t small.  Sometimes bugfixes rely on
> subtle
> > > > side
> > > > > > effects or behaviors not captured in the PR.  It’s not safe to
> assume
> > > > > that
> > > > > > taking code out of the context in which it was written and
> tested to
> > > be
> > > > > > inherently stable or better.
> > > > > >
> > > > > > TO specifically has a problem with the idea of cherry-picking
> with
> > > TODB
> > > > > > migrations.  Since the migrations are linear and there still has
> to
> > > be
> > > > a
> > > > > > forward path from one of these cherry-picked releases, you could
> end
> > > up
> > > > > in
> > > > > > a situation where you’ve got database schema conflicts
> introduced by
> > > a
> > > > > > cherry-pick.  It feels like the desire I’m reading here is
> wanting
> > > the
> > > > > > benefits of adopting GitFlow, while trying to still use
> GitHubFlow in
> > > > the
> > > > > > repo.
> > > > > >
> > > > > > Jonathan G
> > > > > >
> > > > > > From: ocket  
> > > > > > Date: Tuesday, October 26, 2021 at 10:23 PM

Re: [EXTERNAL] Re: [PROPOSAL] ATC Release Schedule

[Jeremy Mitchell]

OK, so can we agree on this?

- minor/major releases every start of a quarter (1/1, 4/1, 7/1, 10/1)
- patch releases in between as determined by release manager

by that logic, we may have N patch releases between now and 12/31 and on
1/1 we will have 6.1.0 (or 7.0 if a major is warranted).

Jeremy



On Wed, Oct 27, 2021 at 12:52 PM ocket   wrote:

> Fortunately bugfixes rarely require migrations, those are usually only for
> new features, or backporting would probably be impossible.
>
> On Wed, Oct 27, 2021 at 10:06 AM Jeremy Mitchell 
> wrote:
>
> > Just to be clear, cherry-picks (aka backports) (from master to the
> release
> > branch) should be limited to bug fixes and would only apply to patch
> > releases (i.e. 6.0.1) and I would expect the release manager to determine
> > if the cherry-pick is safe or not. Yes, some can be very messy and
> > dangerous and IMO those should probably be punted to the next release
> > branch.
> >
> > jeremy
> >
> > On Wed, Oct 27, 2021 at 8:59 AM Gray, Jonathan
> >  wrote:
> >
> > > > > why not instead ask “Is it good enough?” and “Is it better than
> what
> > we
> > > presently have?” as often as possible.
> > >
> > > > may not help very much, because fixing a bug is always "better than
> > what
> > > we
> > > presently have".
> > >
> > > Not always.  Sometimes the risks entailed with cherry-picking and
> > > repatching bugfixes isn’t small.  Sometimes bugfixes rely on subtle
> side
> > > effects or behaviors not captured in the PR.  It’s not safe to assume
> > that
> > > taking code out of the context in which it was written and tested to be
> > > inherently stable or better.
> > >
> > > TO specifically has a problem with the idea of cherry-picking with TODB
> > > migrations.  Since the migrations are linear and there still has to be
> a
> > > forward path from one of these cherry-picked releases, you could end up
> > in
> > > a situation where you’ve got database schema conflicts introduced by a
> > > cherry-pick.  It feels like the desire I’m reading here is wanting the
> > > benefits of adopting GitFlow, while trying to still use GitHubFlow in
> the
> > > repo.
> > >
> > > Jonathan G
> > >
> > > From: ocket  
> > > Date: Tuesday, October 26, 2021 at 10:23 PM
> > > To: dev@trafficcontrol.apache.org 
> > > Subject: Re: [EXTERNAL] Re: [PROPOSAL] ATC Release Schedule
> > > > Thusly, the version number will "choose itself" based on the SemVer
> > > tenants.
> > >
> > > only really works for major vs minor. Micro versions are backport-only,
> > so
> > > they don't necessarily have anything to do with whether or not breaking
> > > changes have been made on master. Which is also why
> > >
> > > > why not instead ask “Is it good enough?” and “Is it better than what
> we
> > > presently have?” as often as possible.
> > >
> > > may not help very much, because fixing a bug is always "better than
> what
> > we
> > > presently have".
> > >
> > > Essentially it seems like our release cadence wouldn't actually change
> > very
> > > much, the proposal isn't to get rid of the quarterly releases we strive
> > > for, but just adding a plan to backport bug fixes every month. Which,
> we
> > > could also decide not to do, if no bugs were fixed that month, or if
> it's
> > > too much trouble to backport the fix - "as-needed" as Jeremy puts it.
> The
> > > big difference is we typically only do micro releases for critical bugs
> > > that slipped through the validation process, or for security fixes,
> > whereas
> > > under the terms of the proposal we'd make an effort to collect things
> > that
> > > could be fixed in supported releases every month.
> > >
> > > > asking folks to vote on new RC every few weeks isn’t feasible unless
> > it’s
> > > a standing “good enough” process
> > >
> > > that would definitely be better, but I think we hope that few enough
> > things
> > > are going into micro releases, with very little unknown since the last
> > > minor, that validation could be focused just on "are these bugs
> actually
> > > fixed?" Could be harder with non-trivial backports, to be sure. It
> would
> > > definitely be better to have that process, and it's definitely
> possible a
> > > micro ve

Re: [EXTERNAL] Re: [PROPOSAL] ATC Release Schedule

[Jeremy Mitchell]

Just to be clear, cherry-picks (aka backports) (from master to the release
branch) should be limited to bug fixes and would only apply to patch
releases (i.e. 6.0.1) and I would expect the release manager to determine
if the cherry-pick is safe or not. Yes, some can be very messy and
dangerous and IMO those should probably be punted to the next release
branch.

jeremy

On Wed, Oct 27, 2021 at 8:59 AM Gray, Jonathan
 wrote:

> > > why not instead ask “Is it good enough?” and “Is it better than what we
> presently have?” as often as possible.
>
> > may not help very much, because fixing a bug is always "better than what
> we
> presently have".
>
> Not always.  Sometimes the risks entailed with cherry-picking and
> repatching bugfixes isn’t small.  Sometimes bugfixes rely on subtle side
> effects or behaviors not captured in the PR.  It’s not safe to assume that
> taking code out of the context in which it was written and tested to be
> inherently stable or better.
>
> TO specifically has a problem with the idea of cherry-picking with TODB
> migrations.  Since the migrations are linear and there still has to be a
> forward path from one of these cherry-picked releases, you could end up in
> a situation where you’ve got database schema conflicts introduced by a
> cherry-pick.  It feels like the desire I’m reading here is wanting the
> benefits of adopting GitFlow, while trying to still use GitHubFlow in the
> repo.
>
> Jonathan G
>
> From: ocket  
> Date: Tuesday, October 26, 2021 at 10:23 PM
> To: dev@trafficcontrol.apache.org 
> Subject: Re: [EXTERNAL] Re: [PROPOSAL] ATC Release Schedule
> > Thusly, the version number will "choose itself" based on the SemVer
> tenants.
>
> only really works for major vs minor. Micro versions are backport-only, so
> they don't necessarily have anything to do with whether or not breaking
> changes have been made on master. Which is also why
>
> > why not instead ask “Is it good enough?” and “Is it better than what we
> presently have?” as often as possible.
>
> may not help very much, because fixing a bug is always "better than what we
> presently have".
>
> Essentially it seems like our release cadence wouldn't actually change very
> much, the proposal isn't to get rid of the quarterly releases we strive
> for, but just adding a plan to backport bug fixes every month. Which, we
> could also decide not to do, if no bugs were fixed that month, or if it's
> too much trouble to backport the fix - "as-needed" as Jeremy puts it. The
> big difference is we typically only do micro releases for critical bugs
> that slipped through the validation process, or for security fixes, whereas
> under the terms of the proposal we'd make an effort to collect things that
> could be fixed in supported releases every month.
>
> > asking folks to vote on new RC every few weeks isn’t feasible unless it’s
> a standing “good enough” process
>
> that would definitely be better, but I think we hope that few enough things
> are going into micro releases, with very little unknown since the last
> minor, that validation could be focused just on "are these bugs actually
> fixed?" Could be harder with non-trivial backports, to be sure. It would
> definitely be better to have that process, and it's definitely possible a
> micro version gets too big or complex to validate cleanly. In that case,
> the release fails, which honestly isn't a big deal if there's no critical
> bug or security fix.
>
> On Tue, Oct 26, 2021 at 9:02 PM Jeremy Mitchell 
> wrote:
>
> > So the idea behind regularly-scheduled, predictable patch/minor/major
> > releases was a couple of things:
> >
> > 1. setting release schedule expectations with the open source community
> (as
> > Dave said). i.e. you can expect a minor/major release 1x a quarter and
> > patch releases in between (monthly)
> > 2. removing the ambiguity of what a minor/major release contains. it
> simply
> > contains whatever was merged in that quarter. nothing to plan. nothing to
> > debate.
> >
> > The truth is feature-based release planning is hard and requires a lot of
> > communication. I don't believe we have the level of communication
> required
> > (via working group or mailing list) to effectively pull off
> feature.-based
> > releases, hence, time-based seems like the better option for us IMO and
> if
> > we go that route, we need to stick to the schedule to be successful.
> >
> > Yeah, I get it. Going from quarterly releases (which we've failed at) to
> > monthly seems like the wrong direction. What if we change NOTHING and
> > recommit to our quarterly major/minor re

Re: [EXTERNAL] Re: [PROPOSAL] ATC Release Schedule

[Jeremy Mitchell]

gt; 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://urldefense.com/v3/__https://semver.org/__;!!CQl3mcHX2A!Q7m483_Mi3eCFQqXNwoXRG_EA0fdl7zl1R6ecyfz7auYIYCuI5rcDvl2EfkIcooWVEU3$
> > ) 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 <
> > mitchell...@gmail.com>
> > > > 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
> > > >
> > >
> >
>

[PROPOSAL] ATC Release Schedule

[Jeremy Mitchell]

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

ATC Release Schedule

[Jeremy Mitchell]

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 and agreed
that we need to 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/agreed:

   - Quarterly minor releases (unless a Major is warranted and will be
   determined on case-by-case basis)
   - Monthly patch releases

Example:

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

Thanks,

Jeremy

Re: 2021-10-19 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

- is it time to make the unstable API (4.0) stable?
- what is our next version and when?  6.0.1? 6.1? 7.0?

On Tue, Oct 12, 2021 at 10:01 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: 2021-10-12 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

More items to discuss:

-  when is it time to make unstable (4.0) stable?
- what is our next version and when?  6.0.1? 6.1?

On Tue, Oct 12, 2021 at 9:18 AM Zach Hoffman  wrote:

> Suggest discussing:
>
> - Due to Go's interpretation of semantic versioning, we will need to
> change the ATC package path to github.com/apache/trafficcontrol/v6 in
> order for ATC 6 godocs to show up, which will never replace ATC 5
> non-module godocs
>
> Other Active mailing list threads:
> - TC 6.0.0 is released
> - TC 5.1.3 is released
> - CVE-2021-42009: Apache Traffic Control Arbitrary Email Content
> Insertion in /deliveryservices/request
>
> On Tue, Oct 5, 2021 at 9:24 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.3-RC0

[Jeremy Mitchell]

+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: [VOTE] Release Apache Traffic Control RELEASE-6.0.0-RC4

[Jeremy Mitchell]

+1

RC4 is installed in our staging environment (minus one t3c commit). auto ui
and api tests have passed in addition to other smoke tests.

On Mon, Oct 4, 2021 at 7:55 AM Eric Friedrich  wrote:

> +1
>
> Verified sigs/hashes and build via ./pkg on OS X.
>
> I tried to bring up CIAB, but had trouble following the instructions to
> prep the rpms into the right locations.
>
> On Wed, Sep 29, 2021 at 6:48 PM Zach Hoffman  wrote:
>
> > I've prepared a release for 6.0.0-RC4. Changes since RELEASE-5.1.2:
> >
> >
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.2...RELEASE-6.0.0-RC4
> >
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-6.0.0-RC4/CHANGELOG.md
> >
> > The artifacts are available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/6.0.0/RC4/
> >
> > BLAKE2 checksum:
> >
> 94e462c1d751edc60f398dc7c588603190cc830e029fbb39acdee74d291a31ffb7d1bdc74fad4678f146c463f43b82537c0706183149c7b85b7564f98e093a94
> > apache-trafficcontrol-6.0.0.tar.gz
> >
> > SHA512 checksum:
> >
> 94da739c6af1cbb307d192e24d346de13cab2a139e5233fafdaa5308729dece748f15beab6a8ab0b7caa160f3c9116ecb986da101ace6aaaf65738036a00ea89
> > apache-trafficcontrol-6.0.0.tar.gz
> >
> > This corresponds to git refs:
> >
> > Hash: 5a2eea21a3175ad76839d54cacbd0386c09966f4
> > Tag: RELEASE-6.0.0-RC4
> >
> > Which can be verified with the following command:
> >
> > $ git tag -v RELEASE-6.0.0-RC4
> >
> > 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.
> >
> > The vote is open until 22:00 UTC on Monday, October 4 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: 2021-09-21 TC Working Group Agenda and Meeting Notes

[Jeremy Mitchell]

+1

On Tue, Sep 14, 2021 at 11:12 PM ocket   wrote:

> that sounds good
>
> On Tue, Sep 14, 2021 at 7:05 PM Zach Hoffman  wrote:
>
> > A 2021-09-21 working group meeting would fall a couple hours after
> > ApacheCon@Home 2021 starts, maybe we should plan on pushing the next TC
> > working group meeting out a week to 2021-09-28.
> >
> > -Zach
> >
> > On Tue, Sep 14, 2021 at 9:31 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 RELEASE-6.0.0-RC3

[Jeremy Mitchell]

steve m.,

who do you plan to assign to
https://github.com/apache/trafficcontrol/issues/6201

jeremy

On Tue, Sep 14, 2021 at 5:48 PM Zach Hoffman  wrote:

> If they have not commented on the issue, only ATC committers can be
> assigned a given Issue. Anyone can be assigned that Issue once they comment
> on it, though.
>
> -Zach
>
>
> On Tue, Sep 14, 2021 at 4:28 PM Steve Malenfant 
> wrote:
>
> > Jeremy,
> >
> > For some reason I can’t assign some folks to issues.
> >
> > Steve
> >
> > On Tue, Sep 14, 2021 at 12:57 PM Jeremy Mitchell 
> > wrote:
> >
> > > Here's the milestone:
> > > https://github.com/apache/trafficcontrol/milestone/18
> > >
> > > From what i can tell all are accounted for except for #6201
> > >
> > > On Tue, Sep 14, 2021 at 10:54 AM Jeremy Mitchell <
> mitchell...@gmail.com>
> > > wrote:
> > >
> > > > so if https://github.com/apache/trafficcontrol/issues/6201 is
> blocking
> > > TC
> > > > 6.0, do we have an assignee for this issue?
> > > >
> > > > On Mon, Sep 13, 2021 at 6:48 PM Steve Malenfant <
> smalenf...@gmail.com>
> > > > wrote:
> > > >
> > > >> I believe those would need fixed/merged (POST TC3):
> > > >>
> > > >> Issues:
> > > >> t3c: Status API fails because FQDN is used as a hostname #6174
> (Merged
> > > >> after RC3)
> > > >> t3c-apply report mode doesn't appear to work (no output) #6201
> > > >> t3c logspam because responses are on stderr #6202
> > > >>
> > > >> PR (restore report functionality of traffic_ops_ort wrapper):
> > > >> t3c-apply report mode. Ignore update server flag #6200
> > > >>
> > > >> Steve
> > > >>
> > > >> On Mon, Sep 13, 2021 at 8:40 PM Robert O Butts 
> > wrote:
> > > >>
> > > >> > @smalenfant I see a lot of t3c Github issues in the last few days.
> > > Which
> > > >> > issues need fixed for the release (versus being non-critical that
> > can
> > > >> > wait)?
> > > >> >
> > > >> > Thanks,
> > > >> >
> > > >> > On Mon, Sep 13, 2021 at 6:17 PM Steve Malenfant <
> > smalenf...@gmail.com
> > > >
> > > >> > wrote:
> > > >> >
> > > >> > > -1
> > > >> > >
> > > >> > > There is a few issues related to cache config that needs
> resolved.
> > > >> > >
> > > >> > > On Tue, Sep 7, 2021 at 6:08 PM Zach Hoffman <
> zrhoff...@apache.org
> > >
> > > >> > wrote:
> > > >> > >
> > > >> > > > I've prepared a release for 6.0.0-RC3. Changes since
> > > RELEASE-5.1.2:
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.2...RELEASE-6.0.0-RC3
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-6.0.0-RC3/CHANGELOG.md
> > > >> > > >
> > > >> > > > The artifacts are available for download at:
> > > >> > > >
> > > >> > > >
> > > >> > https://dist.apache.org/repos/dist/dev/trafficcontrol/6.0.0/RC3/
> > > >> > > >
> > > >> > > > BLAKE2 checksum:
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> 5e81d4e91b6bdea8056955a39f1f1a54770212a8b1977f32fe338d885fba3209bfc72dac2b3b7c2a9f869835bac32abaeb3b6886d72230c22a99bde522b79ac8
> > > >> > > > apache-trafficcontrol-6.0.0.tar.gz
> > > >> > > >
> > > >> > > > SHA512 checksum:
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> 9ad059436edb11f009e38c6a0b946bb37defa8f439d24a01e03380c5cd8a85a0fe722d47812a7146abad24b6014e10dd7f0bffa944f41bda449688c87402e997
> > > >> > > > apache-trafficcontrol-6.0.0.tar.gz
> > > >> > > >
> > > >> > > > This corresponds to git refs:
> > > >> > > >
> > > >> > > > Hash: 89d8f70d6fa4ebcbd22b5023d43256a42eb288d5
> > > >> > > > Tag: RELEASE-6.0.0-RC3
> > > >> > > >
> > > >> > > > Which can be verified with the following command:
> > > >> > > >
> > > >> > > > $ git tag -v RELEASE-6.0.0-RC3
> > > >> > > >
> > > >> > > > 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.
> > > >> > > >
> > > >> > > > The vote is open until 23:00 UTC on Friday, September 10 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 RELEASE-6.0.0-RC3

[Jeremy Mitchell]

Here's the milestone: https://github.com/apache/trafficcontrol/milestone/18

>From what i can tell all are accounted for except for #6201

On Tue, Sep 14, 2021 at 10:54 AM Jeremy Mitchell 
wrote:

> so if https://github.com/apache/trafficcontrol/issues/6201 is blocking TC
> 6.0, do we have an assignee for this issue?
>
> On Mon, Sep 13, 2021 at 6:48 PM Steve Malenfant 
> wrote:
>
>> I believe those would need fixed/merged (POST TC3):
>>
>> Issues:
>> t3c: Status API fails because FQDN is used as a hostname #6174 (Merged
>> after RC3)
>> t3c-apply report mode doesn't appear to work (no output) #6201
>> t3c logspam because responses are on stderr #6202
>>
>> PR (restore report functionality of traffic_ops_ort wrapper):
>> t3c-apply report mode. Ignore update server flag #6200
>>
>> Steve
>>
>> On Mon, Sep 13, 2021 at 8:40 PM Robert O Butts  wrote:
>>
>> > @smalenfant I see a lot of t3c Github issues in the last few days. Which
>> > issues need fixed for the release (versus being non-critical that can
>> > wait)?
>> >
>> > Thanks,
>> >
>> > On Mon, Sep 13, 2021 at 6:17 PM Steve Malenfant 
>> > wrote:
>> >
>> > > -1
>> > >
>> > > There is a few issues related to cache config that needs resolved.
>> > >
>> > > On Tue, Sep 7, 2021 at 6:08 PM Zach Hoffman 
>> > wrote:
>> > >
>> > > > I've prepared a release for 6.0.0-RC3. Changes since RELEASE-5.1.2:
>> > > >
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.2...RELEASE-6.0.0-RC3
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/trafficcontrol/blob/RELEASE-6.0.0-RC3/CHANGELOG.md
>> > > >
>> > > > The artifacts are available for download at:
>> > > >
>> > > >
>> > https://dist.apache.org/repos/dist/dev/trafficcontrol/6.0.0/RC3/
>> > > >
>> > > > BLAKE2 checksum:
>> > > >
>> > >
>> >
>> 5e81d4e91b6bdea8056955a39f1f1a54770212a8b1977f32fe338d885fba3209bfc72dac2b3b7c2a9f869835bac32abaeb3b6886d72230c22a99bde522b79ac8
>> > > > apache-trafficcontrol-6.0.0.tar.gz
>> > > >
>> > > > SHA512 checksum:
>> > > >
>> > >
>> >
>> 9ad059436edb11f009e38c6a0b946bb37defa8f439d24a01e03380c5cd8a85a0fe722d47812a7146abad24b6014e10dd7f0bffa944f41bda449688c87402e997
>> > > > apache-trafficcontrol-6.0.0.tar.gz
>> > > >
>> > > > This corresponds to git refs:
>> > > >
>> > > > Hash: 89d8f70d6fa4ebcbd22b5023d43256a42eb288d5
>> > > > Tag: RELEASE-6.0.0-RC3
>> > > >
>> > > > Which can be verified with the following command:
>> > > >
>> > > > $ git tag -v RELEASE-6.0.0-RC3
>> > > >
>> > > > 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.
>> > > >
>> > > > The vote is open until 23:00 UTC on Friday, September 10 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 RELEASE-6.0.0-RC3

[Jeremy Mitchell]

so if https://github.com/apache/trafficcontrol/issues/6201 is blocking TC
6.0, do we have an assignee for this issue?

On Mon, Sep 13, 2021 at 6:48 PM Steve Malenfant 
wrote:

> I believe those would need fixed/merged (POST TC3):
>
> Issues:
> t3c: Status API fails because FQDN is used as a hostname #6174 (Merged
> after RC3)
> t3c-apply report mode doesn't appear to work (no output) #6201
> t3c logspam because responses are on stderr #6202
>
> PR (restore report functionality of traffic_ops_ort wrapper):
> t3c-apply report mode. Ignore update server flag #6200
>
> Steve
>
> On Mon, Sep 13, 2021 at 8:40 PM Robert O Butts  wrote:
>
> > @smalenfant I see a lot of t3c Github issues in the last few days. Which
> > issues need fixed for the release (versus being non-critical that can
> > wait)?
> >
> > Thanks,
> >
> > On Mon, Sep 13, 2021 at 6:17 PM Steve Malenfant 
> > wrote:
> >
> > > -1
> > >
> > > There is a few issues related to cache config that needs resolved.
> > >
> > > On Tue, Sep 7, 2021 at 6:08 PM Zach Hoffman 
> > wrote:
> > >
> > > > I've prepared a release for 6.0.0-RC3. Changes since RELEASE-5.1.2:
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.2...RELEASE-6.0.0-RC3
> > > >
> > > >
> > >
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-6.0.0-RC3/CHANGELOG.md
> > > >
> > > > The artifacts are available for download at:
> > > >
> > > >
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/6.0.0/RC3/
> > > >
> > > > BLAKE2 checksum:
> > > >
> > >
> >
> 5e81d4e91b6bdea8056955a39f1f1a54770212a8b1977f32fe338d885fba3209bfc72dac2b3b7c2a9f869835bac32abaeb3b6886d72230c22a99bde522b79ac8
> > > > apache-trafficcontrol-6.0.0.tar.gz
> > > >
> > > > SHA512 checksum:
> > > >
> > >
> >
> 9ad059436edb11f009e38c6a0b946bb37defa8f439d24a01e03380c5cd8a85a0fe722d47812a7146abad24b6014e10dd7f0bffa944f41bda449688c87402e997
> > > > apache-trafficcontrol-6.0.0.tar.gz
> > > >
> > > > This corresponds to git refs:
> > > >
> > > > Hash: 89d8f70d6fa4ebcbd22b5023d43256a42eb288d5
> > > > Tag: RELEASE-6.0.0-RC3
> > > >
> > > > Which can be verified with the following command:
> > > >
> > > > $ git tag -v RELEASE-6.0.0-RC3
> > > >
> > > > 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.
> > > >
> > > > The vote is open until 23:00 UTC on Friday, September 10 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 RELEASE-6.0.0-RC1

[Jeremy Mitchell]

Not sure this warrants a -1 but I found a bug with the "delivery service
supported TLS versions" feature:
https://github.com/apache/trafficcontrol/issues/6168

On Tue, Sep 7, 2021 at 9:52 AM Rawlin Peters  wrote:

> -1 due to critical bug in `t3c` when generating ATS configs for
> topology-based DSes:
> https://github.com/apache/trafficcontrol/pull/6166
>
> - Rawlin
>
> On Wed, Sep 1, 2021 at 7:18 PM Zach Hoffman  wrote:
> >
> > I've prepared a release for 6.0.0-RC1. Changes since RELEASE-5.1.2:
> >
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.2...RELEASE-6.0.0-RC1
> >
> https://github.com/apache/trafficcontrol/blob/RELEASE-6.0.0-RC1/CHANGELOG.md
> >
> > The artifacts are available for download at:
> >
> > https://dist.apache.org/repos/dist/dev/trafficcontrol/6.0.0/RC1/
> >
> > BLAKE2 checksum:
> >
> 252c0d82575c6b922744e861a3499bb2f6810c6ee878323a79407f1325bdc0d4e86ffc9328952047f609c7d693f12c49bf3b5d2758b2ed334ad5af3eef443f80
> apache-trafficcontrol-6.0.0.tar.gz
> >
> > SHA512 checksum:
> >
> 143e6e37a569d3f0a177985e62ab39ad7e7953e1c64ca7344f9ab2b03197eea38b1f6106fa07cb7c44e095390f1aab7c86398fc76f03d3d7cd6a8895c24b2511
> apache-trafficcontrol-6.0.0.tar.gz
> >
> > This corresponds to git refs:
> >
> > Hash: 912f8ff30e582b1c565ca3db3af910d9853752c7
> > Tag: RELEASE-6.0.0-RC1
> >
> > Which can be verified with the following command:
> >
> > $ git tag -v RELEASE-6.0.0-RC1
> >
> > 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.
> >
> > The vote is open until 22:00 UTC on Wednesday, September 8 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: new committer: Steve Hamrick

[Jeremy Mitchell]

congrats Steve! well deserved.

On Tue, Sep 7, 2021 at 11:45 AM Zach Hoffman  wrote:

> Well done, Steve! Glad that your frequent contributing has been formally
> recognized.
>
> -Zach
>
> On Tue, Sep 7, 2021 at 11:31 AM Taylor Frey  wrote:
>
> > 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: Proposal: Remove "Events" wiki section

[Jeremy Mitchell]

+1 not sure a list of past events has much value.

On Tue, Aug 31, 2021 at 4:11 PM ocket   wrote:

> Sure. I didn't see any on the one or two I checked out to understand what
> the section is about. Those should go with all the other presentations IMO
> - however that winds up getting grouped.
>
> On Tue, Aug 31, 2021 at 3:51 PM Zach Hoffman  wrote:
>
> > A few Event subpages include slides for presentations given. The slides,
> as
> > well as the corresponding schedule of presentations, should be preserved.
> >
> > -Zach
> >
> > On Tue, Aug 31, 2021 at 3:03 PM ocket   wrote:
> >
> > > https://cwiki.apache.org/confluence/display/TC/Events
> > >
> > > Rather than transfer that over to the GH wiki, I vote we just get rid
> of
> > > it entirely. It looks like the information here has no purpose beyond
> > > whatever historical value we want to assign it - and since this does
> NOT
> > > contain the presentations that I know we want to keep, I don't see that
> > > there's much historical value, especially not for the things like
> Google
> > > Maps embeds for directions and public transit route planning, since
> > nobody
> > > can plan to attend an event in the past.
> > >
> > > If we want to keep things like schedules, dates, and locations, then
> I'd
> > > suggest we use those to group the saved presentations, rather than
> having
> > > the two separate sections.
> > >
> >
>

Re: Proposal: Remove "Hardware" wiki section

[Jeremy Mitchell]

+1 for removal

On Tue, Aug 31, 2021 at 4:11 PM ocket   wrote:

> https://cwiki.apache.org/confluence/display/TC/Hardware
>
> This section details hardware requirements for different components as
> unitless "+"s which can make them hard to translate into the proper
> documentation - but also the hardware requirements vary widely with the
> expectations for the system and its use cases and configurations etc. Plus,
> TO and TR already document hardware requirements (with units) in the
> official documentation.
>
> If anybody knows the hardware requirements for components with currently
> undocumented requirements, we could also add those, but in any event we
> won't be able to get them from this wiki section.
>

Re: [EXTERNAL] Re: Deprecate APIv2 and v3

[Jeremy Mitchell]

> > > > >> > for
> > > > >> > > > API clients.
> > > > >> > > > >
> > > > >> > > > > TC 5.0:
> > > > >> > > > > - API 1.x no longer supported, only API 2.x is supported
> > > > >> > > >
> > > > >> > > > The only reason APIv1 exists in 5.x is because "starting
> with
> > > this
> > > > >> > > > release, you need to start migrating external clients off
> of 1.x
> > > > >> over
> > > > >> > to
> > > > >> > > > 2.0" wound up taking much, much longer than we thought it
> would.
> > > > The
> > > > >> > > plan,
> > > > >> > > > as I understand it, was always for only three API versions
> to
> > > ever
> > > > >> > > coexist
> > > > >> > > > - and only two released versions:
> > > > >> > > > - legacy version, deprecated, what everyone's using prior to
> > > > >> upgrade to
> > > > >> > > > ATC version that deprecates it
> > > > >> > > > - supported version, latest released
> > > > >> > > > - development version, not released, nobody should use
> except
> > > ATC
> > > > >> > > > components under active development.
> > > > >> > > >
> > > > >> > > > On Tue, Jul 27, 2021 at 11:56 AM Rawlin Peters <
> > > raw...@apache.org
> > > > >
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > >> I guess the question now is what do we think is "fair" for
> our
> > > > >> users?
> > > > >> > > >> Shouldn't they decide? Can we survey them? If it were me
> doing
> > > > the
> > > > >> > > >> updates, I think I'd prefer to do the 2nd update as close
> to
> > > the
> > > > >> 1st
> > > > >> > > >> update as possible, since those necessary changes would
> still
> > > be
> > > > >> fresh
> > > > >> > > >> in memory. Especially knowing that a 2nd update is coming
> at
> > > some
> > > > >> > > >> point, I'd rather just get it over with as soon as
> possible and
> > > > not
> > > > >> > > >> have to worry about planning for it later down the line.
> > > > >> > > >>
> > > > >> > > >> - Rawlin
> > > > >> > > >>
> > > > >> > > >> On Tue, Jul 27, 2021 at 11:36 AM Zach Hoffman <
> > > > >> zrhoff...@apache.org>
> > > > >> > > >> wrote:
> > > > >> > > >> >
> > > > >> > > >> > > > Does API 4.x exist before 6.0?
> > > > >> > > >> > > According to the most recent docs, yes.
> > > > >> > > >> >
> > > > >> > > >>
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> https://urldefense.com/v3/__https://traffic-control-cdn.readthedocs.io/en/latest/api/index.html*api-v4-routes__;Iw!!CQl3mcHX2A!Q_lvH7GunLsRSIigt4CHJwosp0fih_-ArK7UVI4Z2cr5_J00BL2ZxgbYrYcu9fyRz_Si$
> > > > <
> > > >
> > >
> https://urldefense.com/v3/__https:/traffic-control-cdn.readthedocs.io/en/latest/api/index.html*api-v4-routes__;Iw!!CQl3mcHX2A!Q_lvH7GunLsRSIigt4CHJwosp0fih_-ArK7UVI4Z2cr5_J00BL2ZxgbYrYcu9fyRz_Si$
> > > > >
> > > > >> <
> > > > >>
> > > >
> > >
> https://urldefense.com/v3/__https:/traffic-control-cdn.readthedocs.io/en/latest/api/index.html*api-v4-routes__;Iw!!CQl3mcHX2A!Q_lvH7GunLsRSIigt4CHJwosp0fih_-ArK7UVI4Z2cr5_J00BL2ZxgbYrYcu9fyRz_Si$
> > > > >> >
> > > > >> > > >> >
> > > > >> > > >> > Those are the docs for the master branch.
> > > > >> > > >> > There is no mention of API 4.x in the ATC 5.1.2 docs:
> > > > >> > > >> >
> > > > >>
> > > >
> > >
> https://urldefense.com/v3/_

Re: Moving to Migrate from Goose

[Jeremy Mitchell]

down with goose!

On Tue, Jul 27, 2021 at 4:09 PM Dave Neuman  wrote:

> sounds good to me
>
> On Tue, Jul 27, 2021 at 7:50 AM Zach Hoffman  wrote:
>
> > Hi ATC,
> >
> > All good things eventually come to an end, but so does Goose. I have a PR
> > out there that gets us using Migrate <
> > https://github.com/golang-migrate/migrate> instead of Goose:
> > https://github.com/apache/trafficcontrol/pull/6057
> >
> > The big improvement is that Migrate is compiled into `db/admin` as a
> > library. It does not need to be installed after installing Traffic Ops,
> you
> > already have it because the Traffic Ops RPM includes the `db/admin` tool.
> > Benefits of this:
> > • Traffic Ops no longer requires an Internet connection to run
> > `postinstall` script.
> > • Golang has been removed as a dependency from Traffic Ops. Although it
> was
> > not listed in the RPM spec, building Goose also required Git, which is
> also
> > no longer needed.
> > • Goose required CGO, which precluded building a Traffic Ops RPM
> targeting
> > x86_64 Linux from other platforms like macOS and Windows if we ever ended
> > up including the `goose` binary in the Traffic Ops RPM. This is no longer
> > an issue.
> >
> > Compatibility features:
> > • The database config file stays the same, you can keep using your
> existing
> > `dbconf.yml` as-is.
> > • With the exception of `db/admin status`, all `db/admin` commands work
> > like they used to (`db/admin status` explained below in the Differences
> > section). For example, the command to run the migrations is still
> `db/admin
> > -env production migrate`.
> > • Although the "up" and "down" migrations are split into separate files
> > now, the contents of each existing migration are otherwise unmodified,
> > other than removing Goose annotations like `+goose Up` and `+goose
> > StatementBegin`.
> > • No extra migration steps should be necessary, you can run `db/admin
> -env
> > production migrate` to migrate from Goose (which uses the
> > `goose_db_version` table) to Migrate (which uses the `schema_migrations`
> > table), meaning that Migrate will start at the migration version that
> Goose
> > used. The `goose_db_version` table is renamed to
> `goose_db_version_unused`
> > to preserve the Goose migration history while ensuring that only Migrate
> is
> > used going forward. If for any reason you do want to go back to Goose,
> you
> > can run the `00_init.down.sql` migration to rename the Goose
> > table back to `goose_db_version`, so this is a non-destructive change.
> > • The `install_goose.sh` script still exists in the repo, it just does
> not
> > do anything. It will be removed in a future ATC release.
> >
> > As a new feature, you can now create migrations directly from `db/admin`
> > using `db_admin create_migration NAME`. Migrations created this way have
> > 16-digit timestamps (as opposed to the 14-digit timestamps that `goose
> > create` produced) and contain the Apache License 2.0.
> >
> > Differences:
> > • Migrate keeps track of the migration version and "dirty" status (true
> or
> > false) in the `schema_migrations` table. If "dirty" is `true`, that means
> > that the last migration to run failed. If it is set, the "dirty" flag
> needs
> > to be cleared manually.
> > • Other than storing the version of the last migration to have run,
> Migrate
> > does *not* keep track of which migrations in the past have run. If a new
> > migration is created with a timestamp before the current migration
> version,
> > Migrate will ignore that migration.
> > • `db/admin status` is now an alias for `db/admin dbversion`. This is
> > because `db/admin status` was a wrapper for `goose status`, which printed
> > the status of each migration. `db/admin status` has been deprecated,
> > pending removal in a future ATC release.
> > • Because each "up" migration and its corresponding "down" migration are
> > split into separate files, and because there are no longer any Goose
> > annotations, Goose cannot use the new Migrate migrations.
> >
> > That's it! Thoughts and suggestions are welcome both in the PR and here
> on
> > the mailing list.
> >
> > -Zach
> >
>

Re: [EXTERNAL] Re: Deprecate APIv2 and v3

[Jeremy Mitchell]

sorry about that. i'm +1 on deprecating APIv2 and APIv3 in the fashion you
mentioned.

On Tue, Jul 20, 2021 at 2:39 PM ocket   wrote:

> I don't really want to propose anything more complex than deprecating APIv2
> and APIv3 in this  thread. Which isn't to say that I don't have opinions on
> all of this, but it's starting to confuse the point when people are giving
> +1s and -1s on things besides the thread subject.
>
> On Tue, Jul 20, 2021 at 2:17 PM Robert O Butts  wrote:
>
> > > so really TO (api) seems to have many versions
> >
> > The Traffic Ops application has a single project/app version. The TO
> > Application "serves" multiple API Versions, which are unrelated to that
> > application version. TO doesn't "have" many versions, it has one
> version. A
> > particular Traffic Ops version "10" might serve API versions X,Y,Z. But
> > those API versions aren't "part" of the Traffic Ops Versions. There
> exists
> > no "Traffic Ops version 10" which serves any other API versions. And
> there
> > might exist other Traffic Ops versions which also serve X,Y,Z. So, TO
> only
> > has one version, "10." X,Y,Z are unrelated to 10, except that 10 is
> > documented as serving X,Y,Z.
> >
> > > ATC is version 5.x, for example, so all the components are version 5.x,
> > right?
> >
> > As an aside, IMO having separate application versions would make a lot of
> > sense and make a lot of things easier. I don't want to push for that
> right
> > now, but something to think about. Maybe part of the version after the
> > project, e.g. ATC could be Version 10.11 and Traffic Ops could have its
> own
> > application version 5.7, so Traffic Ops would have the complete version
> > "atc-10.11-to-5.7-hash-abc123.rpm" or whatever. I think that might make
> it
> > clearer when one app hasn't changed even if the project did, especially
> > with our apps that don't change very often. Something to think about.
> >
> >
> >
> > On Tue, Jul 20, 2021 at 1:44 PM Jeremy Mitchell 
> > wrote:
> >
> > > All good points but also consider this, ATC is version 5.x, for
> example,
> > so
> > > all the components are version 5.x, right? meaning the TO component
> (aka
> > > the TO api) is version 5.x :)
> > >
> > > so really TO (api) seems to have many versions (5.x inherited from the
> > > project and 2.x, 3.x, 4.x, the versions of the "interface"). yes,
> > > confusing...
> > >
> > >
> > >
> > > On Tue, Jul 20, 2021 at 1:32 PM Robert O Butts  wrote:
> > >
> > > > > Also, after years of API confusion, is it time to simply sync the
> ATC
> > > > > version with the API version (brennan has touched on this in the
> > past)
> > > > > starting with our "next" API version. So instead of APIv5, we'd
> just
> > > jump
> > > > > to APIv7. ex:
> > > >
> > > > I strongly disagree with "synchronizing" the API and project version.
> > The
> > > > idea that they need to be the same is deeply confused about what they
> > > are,
> > > > and making them the same will reinforce that confusion with the
> people
> > > who
> > > > are confused.
> > > >
> > > > The project version and the API version are completely independent
> and
> > > > unrelated things. The idea that they need to be versioned together
> and
> > > are
> > > > somehow the same thing is incredibly confused and mistaken about the
> > > > fundamental idea of what an API is and what a code project is.
> > > >
> > > > The API is the API. The project is the project. An API is an
> > Application
> > > > Programming Interface: an interface, like an electric outlet or a
> water
> > > > faucet connection. The Traffic Control project is a code project: a
> > > > collection of applications, written in code, to do a thing, in this
> > case
> > > a
> > > > CDN.
> > > >
> > > > These are completely, entirely, totally different things. It would be
> > > like
> > > > working for a company that sells both laptops and capacitors, and
> > saying,
> > > > "Our capacitors and laptops should have the same serial numbers,
> > because
> > > > they both contain iron atoms."
> > > >
> > > > Yes, the code in the project serves certain

Re: [EXTERNAL] Re: Deprecate APIv2 and v3

[Jeremy Mitchell]

All good points but also consider this, ATC is version 5.x, for example, so
all the components are version 5.x, right? meaning the TO component (aka
the TO api) is version 5.x :)

so really TO (api) seems to have many versions (5.x inherited from the
project and 2.x, 3.x, 4.x, the versions of the "interface"). yes,
confusing...



On Tue, Jul 20, 2021 at 1:32 PM Robert O Butts  wrote:

> > Also, after years of API confusion, is it time to simply sync the ATC
> > version with the API version (brennan has touched on this in the past)
> > starting with our "next" API version. So instead of APIv5, we'd just jump
> > to APIv7. ex:
>
> I strongly disagree with "synchronizing" the API and project version. The
> idea that they need to be the same is deeply confused about what they are,
> and making them the same will reinforce that confusion with the people who
> are confused.
>
> The project version and the API version are completely independent and
> unrelated things. The idea that they need to be versioned together and are
> somehow the same thing is incredibly confused and mistaken about the
> fundamental idea of what an API is and what a code project is.
>
> The API is the API. The project is the project. An API is an Application
> Programming Interface: an interface, like an electric outlet or a water
> faucet connection. The Traffic Control project is a code project: a
> collection of applications, written in code, to do a thing, in this case a
> CDN.
>
> These are completely, entirely, totally different things. It would be like
> working for a company that sells both laptops and capacitors, and saying,
> "Our capacitors and laptops should have the same serial numbers, because
> they both contain iron atoms."
>
> Yes, the code in the project serves certain APIs. But the two things are
> completely independent. Giving them the same version will reinforce the
> wrong and confused belief that they're somehow the same thing, when
> literally the only thing they have in common as ideas is that they're two
> version numbers published by Apache Traffic Control.
>
> Moreover, All Traffic Control applications will always have to serve at
> least one major version back, in order to make it possible to upgrade. So
> the confused idea that they're somehow the same will be made even more
> confusing, because now people think "The API is the same as the Project,
> and the version proves it, but the project has to serve multiple APIs."
> Making people even more confused.
>
> In fact, I'm inclined to think making the versions completely different
> schemes, such as one being letters and the other numbers, would help reduce
> the confusion, and make it more clear that the two versioned things are
> completely unrelated.
>
>
> On Tue, Jul 20, 2021 at 1:00 PM Jeremy Mitchell 
> wrote:
>
> > ^^ I'm good with this.
> >
> > Also, after years of API confusion, is it time to simply sync the ATC
> > version with the API version (brennan has touched on this in the past)
> > starting with our "next" API version. So instead of APIv5, we'd just jump
> > to APIv7. ex:
> >
> > ATCv7 supports APIv7 (to get inline with ATC version) and APIv4 (the api
> > version from ATCv6)
> > ATCv8 supports APIv8 and APIv7
> > etc
> >
> > but then i guess that begs the question, if we bump the major ATC version
> > for another reason (big feature or something), does that mean we have to
> > bump the API version if not really necessary just to keep ATCv == APIv?
> >
> > jeremy
> >
> > On Mon, Jul 19, 2021 at 1:08 PM Rawlin Peters  wrote:
> >
> > > > What kind of backward compatibility expectation are we aiming for
> here?
> > > With 1.x we were coming from 5+ years of backward compatibility
> > >
> > > I don't think we ever intended for API 1.x to live for so long, but we
> > > also never promised an agreed-upon amount of time for backwards
> > > compatibility. I think the intention is that we'd like to have one
> > > major release cycle where both major API versions are supported (in
> > > order for clients to have a transitionary period), then we are free to
> > > remove the deprecated API version in the following release. The amount
> > > of time we remain backwards-compatible should really depend on how
> > > long the release cycles are, which we're aiming for quarterly.
> > >
> > > I agree it is a lot of headache to update 3rd party tooling as API
> > > versions are deprecated and removed (which is why I'm hoping we don't
> > > introduce another major API version very soo

Re: [EXTERNAL] Re: Deprecate APIv2 and v3

[Jeremy Mitchell]

^^ I'm good with this.

Also, after years of API confusion, is it time to simply sync the ATC
version with the API version (brennan has touched on this in the past)
starting with our "next" API version. So instead of APIv5, we'd just jump
to APIv7. ex:

ATCv7 supports APIv7 (to get inline with ATC version) and APIv4 (the api
version from ATCv6)
ATCv8 supports APIv8 and APIv7
etc

but then i guess that begs the question, if we bump the major ATC version
for another reason (big feature or something), does that mean we have to
bump the API version if not really necessary just to keep ATCv == APIv?

jeremy

On Mon, Jul 19, 2021 at 1:08 PM Rawlin Peters  wrote:

> > What kind of backward compatibility expectation are we aiming for here?
> With 1.x we were coming from 5+ years of backward compatibility
>
> I don't think we ever intended for API 1.x to live for so long, but we
> also never promised an agreed-upon amount of time for backwards
> compatibility. I think the intention is that we'd like to have one
> major release cycle where both major API versions are supported (in
> order for clients to have a transitionary period), then we are free to
> remove the deprecated API version in the following release. The amount
> of time we remain backwards-compatible should really depend on how
> long the release cycles are, which we're aiming for quarterly.
>
> I agree it is a lot of headache to update 3rd party tooling as API
> versions are deprecated and removed (which is why I'm hoping we don't
> introduce another major API version very soon), but hopefully the vast
> majority of cases are simply updating the URLs from 2.0 or 3.0 to 4.0,
> since there should only be a small number of breakages from 2.0 to 4.0
> (mostly servers-related routes) that would actually require changing
> more than just the URL. Migrating from 1.x has probably been more
> difficult since we dropped a lot of redundant routes.
>
> - Rawlin
>
>
> - Rawlin
>
> On Mon, Jul 19, 2021 at 11:43 AM Gray, Jonathan
>  wrote:
> >
> > What kind of backward compatibility expectation are we aiming for here?
> With 1.x we were coming from 5+ years of backward compatibility and now it
> seems like we’re aiming for < 1 year with rotation at every major rev.
> That’s a lot of headache for 3rd party tooling support to constantly be
> changing regardless if that means you’re upgrading SDK dependencies or raw
> HTTP calls.
> >
> > Jonathan G
> >
> > From: Rawlin Peters 
> > Date: Friday, July 16, 2021 at 11:54 AM
> > To: dev@trafficcontrol.apache.org 
> > Subject: [EXTERNAL] Re: Deprecate APIv2 and v3
> > +1 on deprecating API v2-3 with the release of ACTv6 and removing them
> > in ATCv7. Hopefully we won't need a TO API v5 very soon so we can have
> > a break from the API instability.
> >
> > +1 on not requiring every v2 and v3 endpoint to return deprecation
> > notices. I think just mentioning it on the mailing list, the
> > changelog, and the docs should cover it. Updating all the v2/v3
> > endpoints to return deprecation notices would be quite a lot of code
> > change with very little benefit IMO. However, for certain endpoints
> > that have no v4 equivalent, we are returning deprecation notices (e.g.
> > cachegroup parameters).
> >
> > - Rawlin
> >
> > On Fri, Jul 16, 2021 at 11:28 AM ocket   wrote:
> > >
> > > With the release of APIv4 in ATCv6, should we simultaneously deprecate
> > > APIv2 and APIv3? I think so, that'll mean we can remove them in ATCv7,
> > > whereupon the stable API 4.0 will have existed for a full major rev,
> and
> > > APIv5 will ostensibly be released (if not sooner, since we could do
> that
> > > e.g. in a 6.1).
> > >
> > > If so, we should also discuss what that will mean materially. With
> > > endpoints that disappear between API versions we have them return
> > > warning-level alerts that indicate they won't be available on upgrade,
> but
> > > for APIv1 as a whole we didn't issue any kind of formal notice afaik,
> not
> > > even a changelog entry. I think the right answer is somewhere between
> these
> > > - a changelog entry and notices on the APIv2 and APIv3 reference
> sections
> > > of the documentation. I don't think it's necessary to mention on each
> > > endpoint that the entire API version is deprecated, either in the
> > > documentation or in the API through Alerts.
>

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

[Jeremy Mitchell]

yeah, what rob said. let's kill them but follow the correct api deprecation
process to avoid any "surprises".

jeremy

On Mon, Jun 28, 2021 at 10:02 PM Robert O Butts  wrote:

> I'm +1 on getting rid of those fields, but unfortunately we need to support
> them in older APIs. People have scripts that rely on them, and parse magic
> data they've put in those fields.
>
> We can remove the field from the API in newer major versions. But we need
> to somehow still serve it in the existing API versions (which will need
> supported for at least 1 major ATC version after the deprecation is
> announced).
>
> I agree, they're terrible and need removed. But I know for a fact there are
> people putting arbitrary data in them in Production systems, which they
> parse with custom scripts hitting the API. Even if we didn't know that for
> sure, we still need to follow the Deprecation/removal process, to avoid
> breaking users who don't necessarily follow the mailing lists closely.
>
> So, ATC 6.0 is about to be released, which introduces API 4.0. If we remove
> `longDesc2` and `longDesc3` from API 4.0 and declare API 3.x deprecated in
> ATC 6.0, we can remove API 3.x and older in ATC 7.0. Which will allow us to
> delete the database fields in ATC 7.0.
>
> If we actually delete the database fields, we need to stop serving API 3.x
> and older. We historically haven't removed API versions as often as we
> could, mostly because it's painful to users. But serving a half-baked API
> will cause all kinds of subtle bugs and data loss. If we delete the DB
> field, we need to actually stop serving /api/3.x.
>
> > 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.
>
> I'm not so sure about this, though. If someone has a specific format,
> key-value, JSON, etc, just joining the fields is going to break their
> scripts. It might be better to make the upgrade fail if the field isn't
> empty, requiring users to handle and move or delete the data themselves
> before upgrading.
>
>
> On Mon, Jun 28, 2021 at 3:56 PM Chatterjee, Srijeet
>  wrote:
>
> > 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: Approved means "Merge it now"

[Jeremy Mitchell]

I will admit, I am often tempted to merge "approved" PRs probably due to my
desire to bring down the open PR count (currently 84). And originally, I
agreed more with Zach and thought some sort of process/agreement was needed
around what "approved" means but after thinking about it more and reading
Rob's response maybe the onus is on the merger to make sure it's "ready to
merge" (by talking to the contributor and the approver(s)) OR maybe if i'm
not involved with a PR (not the contributor or an approver) I should not
concern myself with the PR and let contributor/approvers work to get it
merged.

TLDR; if you are about to hit the merge button, make sure you talk to the
contributor/approvers first (or read the comments like Rob said) to make
sure it's ready for merge.

On Mon, Jun 21, 2021 at 8:33 AM Robert O Butts  wrote:

> I'm not really a fan of putting more rules in place around PRs. We already
> have a lot of rules around when you're allowed to make a PR, exactly what
> it has to look like, exactly what you have to put in the issue text.
>
> More specifically, it's pretty common to say "I'm approving this one part
> of this PR." People can read, I don't think we've ever had a big problem
> with PRs getting accidentally merged, because someone "Approved X but not
> Y," and people didn't read it and hit merge.
>
> I also occasionally Approve to mean "I am technically ok with this being
> merged in and maybe a Github Issue being created for some missing thing,
> but I would really like to see that thing added if the author doesn't
> mind." In which case, people should read what I wrote, and not merge it,
> unless it's clear the author isn't going to. In which case the merger also
> needs to make that Issue, not just Merge without thinking about it.
>
> In a nutshell, people Merging always need to read the issue, not just look
> for "is it approved?" And I think they do, I don't think we have a problem
> with that.
>
> The more rules we have, the harder it is to build community, the harder it
> is to get new contributors, the harder it is to keep the contributors we do
> have. If we already had a big, thriving community, and had issues with PRs
> being unmanageable, it might make more sense. But right now, we struggle
> with community building drastically more than with PR management. We need
> to be making contributing easier, not harder.
>
> I understand not having strict rules leads to occasional confusion, and as
> you say, accidental merges, and then that has to be managed. But it's
> really not that much work to revert, or make a new PR, or whatever the fix
> is. It's just git, and the `master` branch isn't release-ready anyway, it's
> not a big deal for it to not be perfect at all times.
>
> With where our project is in terms of community health, I think those minor
> inconveniences are drastically outweighed by the cost to community building
> of adding more rules around contributing.
>
>
> On Fri, Jun 18, 2021 at 5:02 PM Zach Hoffman  wrote:
>
> > A number of PRs submitted in the last 6 months were approved without that
> > PR being merged. This has caused confusion among committers, and in some
> > cases, the PR has been merged before the PR approver intended the PR to
> be
> > merged. To avoid confusion in the future, it would help if we could agree
> > on some guidelines for approving PRs. Here is a draft:
> >
> > If you approve a PR, you are vouching that:
> > 1. You have already tested the PR
> > 2. You will not request for the PR to be changed any further before it is
> > merged.
> > 3. The PR is ready to merge *right away*, and if someone merges it, you
> are
> > okay with that and accept accountability for your approving PR review.
> >
> > When not to approve the PR:
> > • If you have not tested a PR (especially if you intend to test it before
> > merging), do not approve the PR.
> > • If you want, or might want, the PR to be changed in some way before it
> is
> > merged, do not approve the PR.
> >
> > Cases where you might approve the PR without want it to be immediately
> > merged:
> > • If you are reviewing only part of a PR and are relying on other
> > contributors to review the rest of the PR, approving the PR is okay as
> long
> > as you make it clear that you are only approving that specific part. For
> > example, if a PR affects both Traffic Ops and Traffic Portal and you only
> > intend to review the Traffic Portal portion, approving the PR is okay as
> > long as you mention that you are only approving the Traffic Portal
> portion
> > of the PR.
> > • If CI (GitHub Actions for us, currently) is running or pending and you
> > 100% sure that the CI will pass, approving the PR is okay. For example,
> if
> > you have already seen that the GitHub Actions pass for that PR, then the
> > submitter adds an additional commit that should not keep the GitHub
> Actions
> > from passing again, approving the PR is okay.
> >
> > I'm a bit reluctant to submit a PR to add it to our CONTRIBUTING.md 

Re: misc/traffic-control-cdn

[Jeremy Mitchell]

I think you are right. Safe to delete and remember Git never forgets
anyhow...

On Tue, Jun 15, 2021 at 10:31 AM ocket   wrote:

> Is anyone using the misc/traffic-control-cdn directory? It appears to be an
> older version of our current website at https://trafficcontrol.apache.org/
> so I think we can safely remove it, but I thought I'd make sure no one's
> using it first.
>

Re: Remove /deliveryservices/request

[Jeremy Mitchell]

In case anyone was wondering what POST /deliveryservices/request does - it
basically sends the payload request json to a specified email address. it
was used to send the contents of a ds request form to a specified email
address. comcast had an internal form that was using it and that form is no
longer being used, therefore, comcast no longer uses that endpoint. not
sure if anyone else uses that endpoint or not. i'm guessing no.

jeremy

On Mon, Jun 7, 2021 at 3:37 PM ocket   wrote:

> I just opened https://github.com/apache/trafficcontrol/issues/5921 which
> proposes removing the /deliveryservices/request endpoint. Wanted to put
> that on the dev list's radar in case anyone's using that API endpoint.
>

Re: Using the ASF slack

[Jeremy Mitchell]

I'm all for moving to ASF slack

On Tue, May 25, 2021 at 11:35 AM Dave Neuman  wrote:

> I don't think we have any more good reasons to stay on a standalone slack.
> We do have about 700 users in our current slack and I doubt we get them all
> to move, but I suppose all of the active folks would move.
>
>
> On Tue, May 25, 2021 at 9:14 AM Zach Hoffman  wrote:
>
> > Hi ATC,
> >
> > The official Apache Software Foundation slack (
> https://the-asf.slack.com/
> > ,
> > invite at https://s.apache.org/slack-invite ) did not exist when
> > https://traffic-control-cdn.slack.com/ was made. It's on an enterprise
> > plan, so it does not face the limitations that our Slack workspace faces,
> > such as only being able to see the last 10,000 messages, only being able
> to
> > add 10 bots, etc.
> >
> > ASF Infra has added a webhook for the repo's commit activity to be posted
> > to #traffic-control-commits in the ASF slack, and we can add as many
> > channels as we want. Any reason not to switch?
> >
> > -Zach
> >
>

Re: ATC PMC Chair Change

[Jeremy Mitchell]

Thanks Dave for performing a thankless job and somehow convincing Eric to
take it. ;) Under your watch, TC has grown significantly and knowing Eric,
I'm sure it will continue to do so. Congrats Eric!

Jeremy

On Thu, Apr 22, 2021 at 9:37 AM Zach Hoffman  wrote:

> Thank you Dave for your years of service as ATC's first PMC Chair.
>
> And congrats, Eric! I trust ATC to continue growing under your watch.
>
> -Zach
>
> On Thu, Apr 22, 2021 at 9:00 AM Dave Neuman  wrote:
>
> > Hey everyone,
> >
> > I have decided the time has come for me to pass the torch as PMC Chair
> for
> > Traffic Control. It has been a great one and I am so honored to have
> served
> > in this position.  With that being said, please help me congratulate and
> > support our new PMC Chair and VP of the Apache Traffic Control Project;
> > Eric Friedrich!
> >
> > Thanks,
> > Dave
> >
> >
>

Re: [EXTERNAL] Scripting guidelines/suggestions

[Jeremy Mitchell]

I suppose let's just build up a library of scripts (many that are converted
from perl) written in python and then it should be pretty obvious what the
preference is but won't preclude people from taking a different route that
may suit their needs better.

On Wed, Apr 14, 2021 at 1:23 PM Rawlin Peters  wrote:

> > It's really just meant to be a suggestion.
>
> Right, I'm just worried about the tendency of codified suggestions to
> become rules/requirements (or be wielded as such) later on.
>
> - Rawlin
>
> On Wed, Apr 14, 2021 at 1:06 PM ocket   wrote:
> >
> > > requiring
> >
> > I would never
> >
> > It's really just meant to be a suggestion. If that seems like it would
> > sound like a requirement, we shouldn't put it in. That wasn't the
> intention.
> >
> > I really don't feel strongly about this, personally. It's just something
> > that came up in the WG meeting and I volunteered to talk about it on the
> > list.
> >
> > On Wed, Apr 14, 2021 at 9:56 AM Rawlin Peters  wrote:
> >
> > > I don't think we should really make any kind of language suggestions
> > > in the project. While I agree Python should be considered for scripts
> > > that are too complex for Bash, there may be other reasons where it
> > > would make more sense for it to be written in Go or some other
> > > compiled language. For instance, `db/admin.pl` was replaced with Go
> > > instead of Python because we didn't want to add internet dependencies
> > > during installation and wanted a single static binary to include in
> > > the rpm. For those reasons, Go was the best tool for the job, and we
> > > should always try to use the best tool for the job rather than
> > > requiring everyone to use a specific tool.
> > >
> > > - Rawlin
> > >
> > > On Wed, Apr 14, 2021 at 8:50 AM ocket  
> wrote:
> > > >
> > > > > What would that be for?
> > > >
> > > > Not much, to be honest. Just a suggestion. I also see I didn't
> mention
> > > this
> > > > originally, but the suggestion is also intended to specifically
> mention
> > > > Python as a good choice for when rewriting old scripts from Perl.
> > > >
> > > > > From the homepage of the project, you can see what languages are
> > > > leveraged and realize that by picking something else you run the
> risk of
> > > > having your PR rejected for unmaintainability
> > > >
> > > > Sort of. If you looked a month ago using that decision-making process
> > > you'd
> > > > maybe conclude you should write your scripts in Perl. If you look
> today,
> > > > you'll see:
> > > > -
> > > > - * Go 55.3% 
> > > > - * JavaScript
> > > 12.2%
> > > > 
> > > > 
> > > > - * Java 9.0% <
> https://github.com/apache/trafficcontrol/search?l=java>
> > > > - * HTML 7.2% <
> https://github.com/apache/trafficcontrol/search?l=html>
> > > > - *
> > > TypeScript
> > > > 4.3% 
> > > > - * Shell
> 3.4%
> > > > 
> > > > * Other 8.6%
> > > > 
> > > >
> > > > So you wouldn't see Python anywhere on that list
> > > >
> > > > On Tue, Apr 13, 2021 at 11:35 AM Gray, Jonathan
> > > >  wrote:
> > > >
> > > > > What would that be for?  The project should accept useful
> additions in
> > > any
> > > > > maintainable language already.  From the homepage of the project,
> you
> > > can
> > > > > see what languages are leveraged and realize that by picking
> something
> > > else
> > > > > you run the risk of having your PR rejected for
> unmaintainability.  In
> > > > > those cases, sharing links to the scripts are still useful on the
> > > mailing
> > > > > lists, but simply wouldn't be merged.
> > > > >
> > > > > Jonathan G
> > > > >
> > > > > On 4/13/21, 11:16 AM, "ocket "  wrote:
> > > > >
> > > > > I was thinking about adding a section to CONTRIBUTING.md
> and/or the
> > > > > development docs that suggests Python as the language to use
> for
> > > > > scripts
> > > > > that are too complex for bash but don't need the performance
> > > afforded
> > > > > by a
> > > > > compiled language - any objections?
> > > > >
> > > > >
> > >
>

Re: [VOTE] Release Apache Traffic Control 5.1.2-RC1

[Jeremy Mitchell]

disregard everything i said here as i'm commenting on an old RC :)

On Mon, Apr 12, 2021 at 1:49 PM Jeremy Mitchell 
wrote:

> and there's a PR for  https://github.com/apache/trafficcontrol/issues/5712 so
> i'd suggest we get that PR merged and do a 5.1.2 RC2 with a
> fully-functional dual homing feature.
>
> On Mon, Apr 5, 2021 at 11:58 AM Jeremy Mitchell 
> wrote:
>
>> -1 due to the fact that the 5.x Traffic Stats does not appear to be
>> working - https://github.com/apache/trafficcontrol/issues/5712
>>
>> So basically until this is fixed, Traffic Control is like a car that has
>> a broken speedometer / odometer. Does the car still work? Sure but...
>>
>> On Fri, Apr 2, 2021 at 12:06 PM Zach Hoffman 
>> wrote:
>>
>>> +1
>>>
>>> On 2021/04/02 18:03:12, ocket   wrote:
>>> > Hello All,
>>> >
>>> > I've prepared a release for v5.1.2-RC1
>>> >
>>> > 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://github.com/apache/trafficcontrol/compare/RELEASE-5.1.1...RELEASE-5.1.2-RC1
>>> >
>>> > This corresponds to git:
>>> > Hash: 2f0bdadbd54e07a4dc5715d64846e353bdd527e5
>>> > Tag: RELEASE-5.1.2-RC1
>>> >
>>> > Which can be verified with the following: git tag -v RELEASE-5.1.2-RC1
>>> >
>>> > 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.2/RC1
>>> >
>>> > Thanks!
>>> > ocket ocket8...@apache.org
>>> >
>>>
>>

Re: [VOTE] Release Apache Traffic Control 5.1.2-RC2

[Jeremy Mitchell]

Let me try that again. Bad links.

-1 due to the fact that the dual homing feature (one of the 5.x drivers)
does not appear to be working -
https://github.com/apache/trafficcontrol/issues/5695 - until this PR is
merged: https://github.com/apache/trafficcontrol/pull/5730

On Mon, Apr 12, 2021 at 1:58 PM Jeremy Mitchell 
wrote:

> -1 due to the fact that the dual homing feature (one of the 5.x drivers)
> does not appear to be working -
> https://github.com/apache/trafficcontrol/issues/5712 - until this PR is
> merged: https://github.com/apache/trafficcontrol/pull/5730
>
> On Fri, Apr 9, 2021 at 2:06 PM Zach Hoffman  wrote:
>
>> There is not currently a way using the `pkg` command, unfortunately. I
>> posted a hacky way to do it in another thread:
>>
>> https://lists.apache.org/thread.html/r7adb9b427ed9651c6a0d6cf722d17412e55da4dbecb5985bc622e674%40%3Cdev.trafficcontrol.apache.org%3E
>>
>> Does the Traffic Portal RPM build successfully for you now?
>>
>> -Zach
>>
>> On Fri, Apr 9, 2021 at 11:56 AM Hank Beatty  wrote:
>>
>> > Is there a way to use docker-compose so that all components can be built
>> > in parallel instead of in serial?
>> >
>> > On 4/9/21 1:40 PM, Zach Hoffman wrote:
>> > >> That's the command for CentOS 7?
>> > >
>> > > It is not, CentOS 7 is
>> > >
>> > >  ./pkg -v -7 traffic_portal_build
>> > >
>> > > The command for CentOS 7 builds the Traffic Portal RPM successfully
>> for
>> > me,
>> > > as well, using
>> > >
>> >
>> https://dist.apache.org/repos/dist/dev/trafficcontrol/5.1.2/RC2/apache-trafficcontrol-5.1.2.tar.gz
>> > > as sources.
>> > >
>> > > -Zach
>> > >
>> > > On Fri, Apr 9, 2021 at 11:18 AM Hank Beatty 
>> wrote:
>> > >
>> > >> That's the command for CentOS 7?
>> > >>
>> > >> On 4/9/21 1:03 PM, Zach Hoffman wrote:
>> > >>>> -1 The traffic_portal rpm does not build for me.
>> > >>> I'm having trouble reproducing this, the Traffic Portal RPM built
>> > >>> successfully for me when building using
>> > >>>
>> > >>>   ./pkg -v traffic_portal_build
>> > >>>
>> > >>> using
>> > >>>
>> > >>
>> >
>> https://dist.apache.org/repos/dist/dev/trafficcontrol/5.1.2/RC2/apache-trafficcontrol-5.1.2.tar.gz
>> > >>> as sources.
>> > >>>
>> > >>> -Zach
>> > >>>
>> > >>> On Fri, Apr 9, 2021 at 10:56 AM Hank Beatty 
>> > wrote:
>> > >>>
>> > >>>> -1 The traffic_portal rpm does not build for me.
>> > >>>>
>> > >>>> /usr/lib/node_modules/grunt-cli/node_modules/micromatch/index.js:44
>> > >>>>let isMatch = picomatch(String(patterns[i]), { ...options,
>> > >> onResult
>> > >>>> }, true);
>> > >>>>   ^^^
>> > >>>>
>> > >>>> SyntaxError: Unexpected token ...
>> > >>>>at createScript (vm.js:56:10)
>> > >>>>at Object.runInThisContext (vm.js:97:10)
>> > >>>>at Module._compile (module.js:549:28)
>> > >>>>at Object.Module._extensions..js (module.js:586:10)
>> > >>>>at Module.load (module.js:494:32)
>> > >>>>at tryModuleLoad (module.js:453:12)
>> > >>>>at Function.Module._load (module.js:445:3)
>> > >>>>at Module.require (module.js:504:17)
>> > >>>>at require (internal/module.js:20:19)
>> > >>>>at Object.
>> > >>>>
>> > >>
>> >
>> (/usr/lib/node_modules/grunt-cli/node_modules/findup-sync/index.js:12:10)
>> > >>>> error: Bad exit status from /var/tmp/rpm-tmp.9gsYil (%build)
>> > >>>>
>> > >>>>
>> > >>>> RPM build errors:
>> > >>>>Bad exit status from /var/tmp/rpm-tmp.9gsYil (%build)
>> > >>>> RPM BUILD FAILED: 1
>> > >>>> Error on line 1 of traffic_portal/build/build_rpm.sh
>> > >>>> traffic_portal failed: traffic_portal/build/build_rpm.sh
>> > >>>> The following subdirect

Re: [VOTE] Release Apache Traffic Control 5.1.2-RC2

[Jeremy Mitchell]

-1 due to the fact that the dual homing feature (one of the 5.x drivers)
does not appear to be working -
https://github.com/apache/trafficcontrol/issues/5712 - until this PR is
merged: https://github.com/apache/trafficcontrol/pull/5730

On Fri, Apr 9, 2021 at 2:06 PM Zach Hoffman  wrote:

> There is not currently a way using the `pkg` command, unfortunately. I
> posted a hacky way to do it in another thread:
>
> https://lists.apache.org/thread.html/r7adb9b427ed9651c6a0d6cf722d17412e55da4dbecb5985bc622e674%40%3Cdev.trafficcontrol.apache.org%3E
>
> Does the Traffic Portal RPM build successfully for you now?
>
> -Zach
>
> On Fri, Apr 9, 2021 at 11:56 AM Hank Beatty  wrote:
>
> > Is there a way to use docker-compose so that all components can be built
> > in parallel instead of in serial?
> >
> > On 4/9/21 1:40 PM, Zach Hoffman wrote:
> > >> That's the command for CentOS 7?
> > >
> > > It is not, CentOS 7 is
> > >
> > >  ./pkg -v -7 traffic_portal_build
> > >
> > > The command for CentOS 7 builds the Traffic Portal RPM successfully for
> > me,
> > > as well, using
> > >
> >
> https://dist.apache.org/repos/dist/dev/trafficcontrol/5.1.2/RC2/apache-trafficcontrol-5.1.2.tar.gz
> > > as sources.
> > >
> > > -Zach
> > >
> > > On Fri, Apr 9, 2021 at 11:18 AM Hank Beatty 
> wrote:
> > >
> > >> That's the command for CentOS 7?
> > >>
> > >> On 4/9/21 1:03 PM, Zach Hoffman wrote:
> >  -1 The traffic_portal rpm does not build for me.
> > >>> I'm having trouble reproducing this, the Traffic Portal RPM built
> > >>> successfully for me when building using
> > >>>
> > >>>   ./pkg -v traffic_portal_build
> > >>>
> > >>> using
> > >>>
> > >>
> >
> https://dist.apache.org/repos/dist/dev/trafficcontrol/5.1.2/RC2/apache-trafficcontrol-5.1.2.tar.gz
> > >>> as sources.
> > >>>
> > >>> -Zach
> > >>>
> > >>> On Fri, Apr 9, 2021 at 10:56 AM Hank Beatty 
> > wrote:
> > >>>
> >  -1 The traffic_portal rpm does not build for me.
> > 
> >  /usr/lib/node_modules/grunt-cli/node_modules/micromatch/index.js:44
> > let isMatch = picomatch(String(patterns[i]), { ...options,
> > >> onResult
> >  }, true);
> >    ^^^
> > 
> >  SyntaxError: Unexpected token ...
> > at createScript (vm.js:56:10)
> > at Object.runInThisContext (vm.js:97:10)
> > at Module._compile (module.js:549:28)
> > at Object.Module._extensions..js (module.js:586:10)
> > at Module.load (module.js:494:32)
> > at tryModuleLoad (module.js:453:12)
> > at Function.Module._load (module.js:445:3)
> > at Module.require (module.js:504:17)
> > at require (internal/module.js:20:19)
> > at Object.
> > 
> > >>
> > (/usr/lib/node_modules/grunt-cli/node_modules/findup-sync/index.js:12:10)
> >  error: Bad exit status from /var/tmp/rpm-tmp.9gsYil (%build)
> > 
> > 
> >  RPM build errors:
> > Bad exit status from /var/tmp/rpm-tmp.9gsYil (%build)
> >  RPM BUILD FAILED: 1
> >  Error on line 1 of traffic_portal/build/build_rpm.sh
> >  traffic_portal failed: traffic_portal/build/build_rpm.sh
> >  The following subdirectories had errors:
> >    traffic_portal
> >  Error on line 1 of ./build/build.sh
> > 
> > 
> > 
> >  On 4/7/21 12:11 PM, ocket  wrote:
> > > Hello All,
> > >
> > > I've prepared a release for v5.1.2-RC2
> > >
> > > 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://github.com/apache/trafficcontrol/compare/RELEASE-5.1.1...RELEASE-5.1.2-RC
> > > <
> > 
> > >>
> >
> https://github.com/apache/trafficcontrol/compare/RELEASE-5.1.1...RELEASE-5.1.2-RC1
> > >
> > > 2
> > >
> > > This corresponds to git:
> > > Hash: 924138d143febb66e926f0e6be82b22d450bfbd9
> > > Tag: RELEASE-5.1.2-RC2
> > >
> > > Which can be verified with the following: git tag -v
> > RELEASE-5.1.2-RC2
> > >
> > > 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.2/RC2
> > >
> > > Thanks!
> > > ocket ocket8...@apache.org
> > >
> > 
> > >>>
> > >>
> > >
> >
>

Re: [VOTE] Release Apache Traffic Control 5.1.2-RC1

[Jeremy Mitchell]

and there's a PR for  https://github.com/apache/trafficcontrol/issues/5712 so
i'd suggest we get that PR merged and do a 5.1.2 RC2 with a
fully-functional dual homing feature.

On Mon, Apr 5, 2021 at 11:58 AM Jeremy Mitchell 
wrote:

> -1 due to the fact that the 5.x Traffic Stats does not appear to be
> working - https://github.com/apache/trafficcontrol/issues/5712
>
> So basically until this is fixed, Traffic Control is like a car that has a
> broken speedometer / odometer. Does the car still work? Sure but...
>
> On Fri, Apr 2, 2021 at 12:06 PM Zach Hoffman  wrote:
>
>> +1
>>
>> On 2021/04/02 18:03:12, ocket   wrote:
>> > Hello All,
>> >
>> > I've prepared a release for v5.1.2-RC1
>> >
>> > 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://github.com/apache/trafficcontrol/compare/RELEASE-5.1.1...RELEASE-5.1.2-RC1
>> >
>> > This corresponds to git:
>> > Hash: 2f0bdadbd54e07a4dc5715d64846e353bdd527e5
>> > Tag: RELEASE-5.1.2-RC1
>> >
>> > Which can be verified with the following: git tag -v RELEASE-5.1.2-RC1
>> >
>> > 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.2/RC1
>> >
>> > Thanks!
>> > ocket ocket8...@apache.org
>> >
>>
>

Re: Deprecate TO API endpoint vault/bucket/:bucket/key/:key/values

[Jeremy Mitchell]

+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: [VOTE] Release Apache Traffic Control 5.1.2-RC1

[Jeremy Mitchell]

-1 due to the fact that the 5.x Traffic Stats does not appear to be working
- https://github.com/apache/trafficcontrol/issues/5712

So basically until this is fixed, Traffic Control is like a car that has a
broken speedometer / odometer. Does the car still work? Sure but...

On Fri, Apr 2, 2021 at 12:06 PM Zach Hoffman  wrote:

> +1
>
> On 2021/04/02 18:03:12, ocket   wrote:
> > Hello All,
> >
> > I've prepared a release for v5.1.2-RC1
> >
> > 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://github.com/apache/trafficcontrol/compare/RELEASE-5.1.1...RELEASE-5.1.2-RC1
> >
> > This corresponds to git:
> > Hash: 2f0bdadbd54e07a4dc5715d64846e353bdd527e5
> > Tag: RELEASE-5.1.2-RC1
> >
> > Which can be verified with the following: git tag -v RELEASE-5.1.2-RC1
> >
> > 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.2/RC1
> >
> > Thanks!
> > ocket ocket8...@apache.org
> >
>

New automated TP tests

[Jeremy Mitchell]

Dandy Pham has been kind enough to contribute a more robust suite of
automated TP tests (and a better TP test framework) to open source and
Steve Hamrick has created a GitHub Action/Workflow to run these tests on
any/all new PRs.

These TP tests can be found here:
https://github.com/apache/trafficcontrol/tree/master/traffic_portal/test/integration

And the GHA/workflow can be found here:
https://github.com/apache/trafficcontrol/blob/master/.github/workflows/tp.integration.tests.yml

This means the following tests have been deprecated (and will eventually be
deleted):
https://github.com/apache/trafficcontrol/tree/master/traffic_portal/test/end_to_end

Action items:

1. New TP tests should be added to traffic_portal/test/integration instead
of traffic_portal/test/end_to_end

2. If you have any internal CI hooked into traffic_portal/test/end_to_end,
switch it to traffic_portal/test/integration

Thanks,

Jeremy