Re: Slack Invite request

Hi Tanguy, You should receive an invite shortly if you have not already. Thanks, Dave On Mon, Jan 9, 2023 at 8:33 AM Tanguy Person wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? > > > > This message and any attachment are confidential and

Re: Slack Invite request

Done On Thu, Dec 29, 2022 at 06:58 Jackie Brazeal wrote: > tWill someone please invite me to the ASF Slack so I can join the > #traffic-control channel? >

Re: Slack Invite request

Done On Thu, Dec 22, 2022 at 09:36 Robert Bouchard wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? >

Re: Slack Invite request

Done On Mon, Dec 19, 2022 at 09:29 Denis Bouchard < denis.bouchard...@videotron.com> wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? >

Re: Slack Invite request

Done On Thu, Dec 22, 2022 at 07:20 Leonard Michael Digeno wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? > > Don DiGeno >

Re: Slack Invite request

Done On Fri, Aug 26, 2022 at 7:21 AM Fatemeh Nasiri wrote: > Hello, > > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? > > Kind regards, > Fatemeh Nasiri > > > This message and any attachment are confidential and may be privileged or > otherwise

Re: Slack Invite request

Done On Tue, Aug 23, 2022 at 01:34 Adrien GIROT wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? > > > *Adrien GIROT* > *Technical Lead* > 33604144823 > agi...@scaleway.com >

Re: Slack Invite request

Done On Wed, Aug 10, 2022 at 06:50 Matthieu MOREL wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? > > Best Regard, > > Matthieu > > -- > [image: img] > > *Matthieu MOREL* > *DevOps Engineer* > > mmo...@scaleway.com >

Re: Slack Invite request

done On Fri, Jul 29, 2022 at 9:51 AM Turhan durmaz Yılmaz wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? >

Re: Slack Invite request

sent On Wed, Jul 6, 2022 at 4:53 AM PHONG NGUYEN VAN < nguyenvanphong_...@hus.edu.vn> wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? >

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

>> - Zach proposes/iss working on a geographic Topology builder using Cache Group latitude/longitude to map them out I would suggest incorporating the physical locations of the hosts as well. Maybe as a drill down? Cache groups can be as big as a whole country, having the actual locations of

Re: Slack Invite request

Hi Noah, I have sent an invite. Thanks, Dave On Wed, May 11, 2022 at 1:39 PM Noah wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? >

Re: Slack Invite request

Done On Sat, Apr 23, 2022 at 06:32 Nischal Bhandari wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? >

Re: Slack Invite request

Hey Henry, I have invited you. Thanks, Dave On Wed, Apr 20, 2022 at 3:16 PM Henry Lui wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? >

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

t; Linux is what the ATC project will support if we're going to use it > > moving forward, and the working group does not have the authority to > > make that call. > > > > On Tue, Feb 1, 2022 at 9:39 AM Dave Neuman wrote: > > > > > > - Need mailing

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

- Need mailing list confirmation that moving to Rocky is the plan, then our CI can be converted to Rocky Linux Do we though? Can't we just put in support for Rocky and if folks want support for other things they could add it? Seems like going to 7 is going backwards for what reason? On Tue, Feb

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

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

Re: Slack Invite request

Done On Wed, Jan 5, 2022 at 10:51 AM Nanthakumaar, Gopi < gopi.nanthakum...@warnermedia.com> wrote: > Will someone Will someone please invite me to the ASF Slack so I can join > the #traffic-control channel? > > -- > Information

Re: Slack Invite request

Hey Nick, I sent you an invite. Thanks, Dave On Mon, Nov 8, 2021 at 2:09 PM Nick Dunkin wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? > > > > *Nick Dunkin* > > Director, Software Engineering > > Manager – Architecture and New Product

Re: Slack Invite request

Hey Ulf, I just sent an invite. Thanks, Dave On Mon, Nov 8, 2021 at 06:44 Ulf Bjork wrote: > Will someone please invite me to the ASF Slack so I can join the > #traffic-control channel? > > Best Regards, > Ulf >

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

le 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 > > > > >

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

> - Zach will open an Issue making note of places where a specific > architecture is assumed/alluded to. > > On Wed, Oct 27, 2021 at 9:40 AM Dave Neuman wrote: > > > If we talked about releases - as indicated in the releases ML discussion > - > > why is it not in the note

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

If we talked about releases - as indicated in the releases ML discussion - why is it not in the notes? On Tue, Oct 26, 2021 at 9:07 AM Zach Hoffman wrote: > Consider discussing: > - Apple M1 processors are fast and power-saving, and in the future, > they or other ARM processors might even be

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

critical flaws, so we don’t end up cherry-picking and fixing up patches > moving the next cadence window further and further out. > > Jonathan G > > > From: Dave Neuman > Date: Tuesday, October 26, 2021 at 4:02 PM > To: dev@trafficcontrol.apache.org > Subject: [EXTERNAL]

Re: [PROPOSAL] ATC Release Schedule

So we are trying to address our inability to meet our current release goals by adding more releases? Why don't we just try to get more consistent with the quarterly releases before we change things? If we need to do a patch release it is probably because some critical issue was found, are we

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

+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

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

>> 6. Our Slack invite is no longer a >> Slack invite >> - We should make a web form to allow people to request access. >> - Need a volunteer. Why not just have people send an email to the mailing list requesting access? Isn't that a lot easier than making a

Re: [EXTERNAL] Proposal: stable vs unstable TO API versions

Another versioning discussion, yay! In all seriousness, I am +1 for whatever makes development easier as long as the risk to operations doesn't outweigh the savings. In other words, if we feel like this change is going to provide a lot more simplicity for our development cycle -- including the

Re: Proposal: Remove "Hardware" wiki section

+1 for removal as well On Tue, Aug 31, 2021 at 19:06 Jeremy Mitchell wrote: > +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 > >

Re: The purpose, structure, and future of the ATC Confluence Wiki

We used cwiki because GH wiki did not exist at the time. I personally get the most value from the presentations that we have on our wiki. As long as we move those to GH wiki, I have no problem moving off of cwiki. We need to make sure we update our webpage (trafficcontrol.apache.org) and docs as

Re: Moving to Migrate from Goose

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

Re: [EXTERNAL] Re: Deprecate APIv2 and v3

ote: > >> > > >> > > > Does API 4.x exist before 6.0? > >> > > According to the most recent docs, yes. > >> > > >> > https://traffic-control-cdn.readthedocs.io/en/latest/api/index.html#api-v4-routes > >> > > >> &g

Re: [EXTERNAL] Re: Deprecate APIv2 and v3

Does API 4.x exist before 6.0? I am worried about basically telling our users that before they can go to 6.x they have to get off API 1.x but the latest at that point is 3.x so then we are turning around and saying they have to update again. I would prefer if we gave more time and did 2.0 now and

Re: Proposal: Distributed Health Monitoring

Just wanted to clarify that this is the design that came from the requirements discussed in this thread: https://lists.apache.org/thread.html/rf985a2b9e8a440d396a0097a71882919bff5b3cb5f8d6c3a53143162%40%3Cdev.trafficcontrol.apache.org%3E I am +1, but interested in hearing all the feedback from

Re: Distributed Traffic Monitor Feedback/Requirements

ic > > On Fri, Jun 25, 2021 at 10:36 AM Dave Neuman wrote: > > > Hey Eric, > > Thanks for the questions/feedback. My responses are inline below. Most > of > > your questions will need to be addressed when we do design as right now I > > just want to make

Re: Distributed Traffic Monitor Feedback/Requirements

buted TM. As for its own repo, that is a larger conversation. I am not sure what that means for all of the ancillary pieces like cdn-in-a-box, the pkg script, etc. If it is worth the trouble then I am all for it, but I don't think we should let this thread get bogged down with that conversation.

Re: Approved means "Merge it now"

I just want to re-enforce that there are no guarantees that the master branch is production quality code. We do our best to ensure it is, but it is not a release branch which is production-ready code. I say that to say that if a PR is approved and merged before it is ready, we can just make a new

Distributed Traffic Monitor Feedback/Requirements

Hey All, One of the things we have been talking about doing for a long time is making Traffic Monitor capable of monitoring a subset of the CDN so that it can be deployed in a distributed fashion. The time has come for us to get moving on this. We have had some discussions internally to

Re: Using the ASF slack

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

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

+1 Validated signature, hash, and ran pkg -v to build all RPMs. On Tue, May 11, 2021 at 6:34 PM Rawlin Peters wrote: > +1 > > On Fri, May 7, 2021 at 10:08 AM ocket wrote: > > > > Hello All, > > > > I've prepared a release for v5.1.2-RC3 > > > > The vote is open for at least 72 hours and

ATC PMC Chair Change

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

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

+1 On Wed, Apr 7, 2021 at 10:11 AM 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 ...

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

+1 Verified Sha and signatures. Used pkg to build everything. Also, we are running (some of) this in prod. On Fri, Mar 26, 2021 at 10:47 PM Chatterjee, Srijeet wrote: > +1 > Everything builds fine, and local TO/ TP manual tests seem to be working. > > --Srijeet > > On 3/26/21, 7:48 PM, "Steve

Re: Proposal: ORT/t3c git

+1 to adding this as a local option. It could be a good stepping stone for something like Rawlin is suggesting. On Tue, Mar 16, 2021 at 16:46 Rawlin Peters wrote: > I don't really see a reason not to provide this option, even if it is > just local. > > However, I could see us using a remote

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

+1 I verified sha512sum, gpg signature, and built the RPMs using pkg -v Thanks, Dave On Thu, Mar 11, 2021 at 12:56 PM Jeremy Mitchell wrote: > +1 > > built in ciab and did some testing through TP. > > On Wed, Mar 10, 2021 at 3:22 PM ocket wrote: > > > +1 > > > > CiaB shows rpms build,

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

e, I believe our company has a legal > requirement to > > > have a separate "secret" database, so the Postgres secret > store needs to at > > > least have the ability to be a separate DB URL+auth than the > primary TO > > > Postgres

Re: Replace Riak w/ PostgreSQL

I am +1 for using Postgres, however we should consider implementing the "secret store" functionality in such a way that people can choose to implement whatever backend they want. I think it can be accomplished using the TO plugin functionality but I am sure people more familiar with the code

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

+1 Verified signatures and sha512. Used `pkg -v` to build packages and verified they all built. On Tue, Nov 24, 2020 at 5:47 PM Rawlin Peters wrote: > +1, cdn-in-a-box built and started successfully, and I was able to > `curl` the test delivery service. > > - Rawlin > > On Mon, Nov 23, 2020 at

Re: TR Upgrading to Java 11 LTS

I think a combination of what Zach suggested and option 2 are what I think sounds best. If the limitations of Bouncy Castle aren't insurmountable, I would rather use that than try to write our own. --Dave On Fri, Sep 11, 2020 at 4:25 PM ocket wrote: > > IMO refactoring to remove

New Committer: Zach Hoffman

The Project Management Committee (PMC) for Apache Traffic Control has invited Zach Hoffman to become a committer and we are pleased to announce that Zach has accepted! Please join us in congratulating Zach. Thanks, Dave

Re: Migrating to ci-builds.apache.org from builds.apache.org

Does GHA also host the builds for downloads? One nice thing about Jenkins is that it hosts helper builds that we can point people in the community to. On Thu, Aug 13, 2020 at 11:16 AM Jeremy Mitchell wrote: > I think it's time to move away from apache jenkins and embrace github > actions (GHA).

Re: [EXTERNAL] ATC 5.0 Release planning

, and since we haven't officially gotten the 4.1 votes we need yet, I am proposing that we push this by (at least) 2 weeks to the middle of July with the understanding that the end of July may be more realistic. Thanks, Dave On Tue, May 26, 2020 at 12:37 PM Dave Neuman wrote: > We've started to disc

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

+1, we have this running in production now. On Wed, Jun 10, 2020 at 5:51 PM Rawlin Peters wrote: > Hello All, > > I've prepared a release for v4.1.0-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 > >

ATC 5.0 Release planning

Hey everyone, In the spirit of trying to do a better job of release planning, I wanted to start the conversation around what will be in ATC 5.0, which will be our next release of ATC after 4.1. The first thing you may notice is that we will be bumping the major version, this is because there are

Traffic Control 4.1 Release

Hey All, I know we just got 4.0 released, but in the spirit of quicker and smaller releases, I think it is time to start working on our 4.1 release. 4.1 already has quite a bit of new functionality in it, as well as a move to the 2.0 API, so it's already big enough to warrant a new release. I put

Re: ORT Rewrite Proposal

Rawlin never even mentioned the word "Push" :) he was also referring to the potential of thousands of clients request many of the same end points all at once. Our CDN is good at that, Traffic Ops is not. Anyway, I think that problem can and should be solved outside the scope of the ORT re-write

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

hout the header. I've opened up a fix here: > > > > > > https://github.com/apache/trafficcontrol/pull/4431 > > > > > > > > > > > > FWIW, it is important to verify that any present weasel errors > are > > > > > > investigated prior to

Re: Multi-interface servers (blueprint)

Thanks Brennan! On Mon, Mar 23, 2020 at 9:42 AM ocket wrote: > I have a PR open with a blueprint for a new feature, servers with multiple > network interfaces. I don't want to try to explain too much since a > blueprint exists, so if that sounds interesting go check it out: >

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

+1 I verified that sha512sum and signature. I was able to build all of the components, but weasel failed for some reason. Since it's not critical to running a CDN, I won't let that hold us up. On Tue, Feb 11, 2020 at 9:42 AM Rawlin Peters wrote: > Hello All, > > I've prepared a release for

Re: I saw this job posting related to the traffic control project...

Hey Dean, I passed your info along. Thanks, Dave On Tue, Jan 14, 2020 at 16:58 Dean Hiller wrote: > Does anyone here know the manager for this job posting below? > > > https://jobs.comcast.com/jobs/description/regular?external_or_internal=external_id=206951 > > I used to be at Twitter dealing

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

I second your sentiment, Rawlin. On Wed, Dec 18, 2019 at 10:40 AM Rawlin Peters wrote: > In the spirit of getting releases out every 4-6 weeks, I'd like us to > refrain from downvoting the RC for minor issues. If we cut new RCs for > every minor issue that comes up, we'll never reach our goal

Re: EDNS0 Client Subnet for Delivery Services

ecsEnable CRConfig.json Boolean value to enable or disable ENDS0 client subnet extensions. On Thu, Dec 12, 2019 at 1:33 PM Jeremy Mitchell wrote: > Cool. Just curious. How do you enable it currently at the CDN level? A > parameter or something? > > Jeremy > > On Wed, Dec 11, 2019 at 2:32 PM

Re: [EXTERNAL] Re: Proposal: Only allow streaming downloads of ISOs

I believe we are relying on the downloadable version of the iso in some of our install automation. I'll have to take a look to see. On Tue, Dec 10, 2019 at 1:47 PM Jeremy Mitchell wrote: > Yeah, i think changing POST /api/1.1/isos?stream=false to return an error > instead of the expected link

Re: Time to make a 4.x release

by early next week. Thanks, Dave On Tue, Oct 29, 2019 at 9:10 AM Dave Neuman wrote: > Hey All, > Good news, Rawlin has volunteer to be our 4.x release manager! Thank you > Rawlin! > > I am going to work with Rawlin to get a 4.x branch created early next > week. Once this

Re: [EXTERNAL] Component leads

I agree with Rob and Jonathan on this one. I don't see a reason that committers cannot already gravitate toward a component, and I want to avoid adding any formal designation to community members outside of the defined Apache ones (contributor, commiter, and pmc). I think I would rather see us

Re: [EXTERNAL] TO API routing blacklist

I am +1 on this idea. On Fri, Nov 1, 2019 at 09:26 Gray, Jonathan wrote: > The available routes and what associated backend they go to are operator+ > sensitive information. I'd also lean towards a stronger degree of safety > and only make it read-only. > > Jonathan G > > On 11/1/19, 8:41 AM,

Re: [EXTERNAL] Re: Release Process

t; > cherry-pick everything into the 4.x branch as it gets merged into > > > master. Then, after 4-6 weeks of cherry-picking commits, if unstable > > > commits were not fixed/completed in time, I would reset the 4.x branch > > > to the last stable commit. This would mean tha

Re: [EXTERNAL] Re: Release Process

ster branch as stable as possible. > > The end result would be the same as just continually jumping up the > master branch from known good, stable points in time to the next, > creating a minor release branch at each of those points. > > - Rawlin > > >

Re: [EXTERNAL] Re: Release Process

ting will lead to general improvements to the > automated testing infrastructure, the ability to kill off legacy code in > our lifetimes, and make the stability of new releases more > certain.Time-based release cycles get a big +1 from me, and if I have to > live with cher

Re: [EXTERNAL] Re: Release Process

gh to start a release cycle with > one scope of both, yet at the end continue to revise that definition. > > Jonathan G > > > On 10/30/19, 2:36 PM, "Dave Neuman" wrote: > > Sorry, I have taken too long to respond. > > +100 on better CI and Tes

Re: [EXTERNAL] Re: Release Process

Sorry, I have taken too long to respond. +100 on better CI and Testing, I think we all agree that needs to get better and is a different beast than this topic. As for the release branches, I am trying to follow a process similar to ATS, which is usually the model we try to follow with our

Re: Time to make a 4.x release

Hey All, Good news, Rawlin has volunteer to be our 4.x release manager! Thank you Rawlin! I am going to work with Rawlin to get a 4.x branch created early next week. Once this branch is created, all changes that we want to include in 4.0 will need to have a backport PR opened against the 4.x

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

Sorry for forgetting about this. I verified signatures and sha512. Also verified I could build using pkg. +1 On Fri, Sep 6, 2019 at 2:43 PM wrote: > Hello All, > > I've prepared a release for v3.1.0-RC1 > > The vote is open for at least 72 hours and passes if a majority of at > least 3 +1 PMC

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

+1 On Tue, Sep 3, 2019 at 2:53 PM ocket wrote: > +1 > > On Tue, Sep 3, 2019 at 2:25 PM wrote: > > > Hello All, > > > > I've prepared a release for v3.0.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

Re: [EXTERNAL] Re: Cache-Side Config Generation

The original intention of this thread was cache-side config generation, we should take other conversations to other threads if we think now is the time to have them. First of all, thanks for putting the thought and time into this. I do think large changes like this might be better first discussed

Re: Mutable jobs

6 AM ocket wrote: > > > That works for me, I'll make the necessary changes. > > > > On Thu, Aug 1, 2019 at 10:08 AM Dave Neuman wrote: > > > >> Good summary Jeremy. > >> I agree with Rawlin, I think it is reasonable to allow jobs to be > change

Re: Mutable jobs

Good summary Jeremy. I agree with Rawlin, I think it is reasonable to allow jobs to be changed up until they are active (using PUT) and also allow them to be DELETED at any time. On Thu, Aug 1, 2019 at 9:28 AM Rawlin Peters wrote: > I think you summed that up pretty well, Jeremy. @ocket did

Re: [EXTERNAL] Go dependency management

This sounds like a good plan, but I wonder if this is something we want to try to do before we cut the next release, or something we want to do after? On Wed, Jul 10, 2019 at 10:31 AM Dan Kirkwood wrote: > +1 > > On Wed, Jul 10, 2019 at 10:26 AM Fieck, Brennan > > wrote: > > > +1 sounds

Re: TC issue template

Looks fine to me. Thanks for taking the initiative to make it better! On Mon, Jul 1, 2019 at 9:21 AM Jeremy Mitchell wrote: > In addition, I think/hope this issue template will help prevent the > premature disclosure of TC security vulnerabilities. > > Jeremy > > On Mon, Jul 1, 2019 at 9:03 AM

Re: PR3075 - Merging parent.config in traffic_ops_golang

g at the bit to add onto it :). I'll go ahead and merge it. > > - Rawlin > > On Fri, May 31, 2019 at 3:10 PM Dave Neuman wrote: > > > > As far as I know we haven't yet defined our next release so I don't see > why > > we are trying to rate limit the PRs we

Re: PR3075 - Merging parent.config in traffic_ops_golang

As far as I know we haven't yet defined our next release so I don't see why we are trying to rate limit the PRs we merge. I don't remember us providing any guarantees that master will be stable and production ready. That is why we have a release process. Rawlin if you are uncomfortable merging

Re: Opt in OAuth integration for Traffic Portal

Great work, thanks Matt! On Tue, May 14, 2019 at 3:33 PM Matthew Jackson wrote: > Hey all, > > I have submitted this PR: > https://github.com/apache/trafficcontrol/pull/3505 > > It is a first step toward using OAuth for login in Traffic Portal (first > step because it only works for OAuth

Re: New Feature: Cache Assignment Groups

This is exciting, thanks Eric. Any idea how well this fits in with flexible cache groups? On Thu, May 9, 2019 at 10:51 Eric Friedrich wrote: > GH Issue Link: https://github.com/apache/trafficcontrol/issues/3557 > > Background > -- > Edge caches can currently be assigned to delivery

Re: Deprecate STEERING in favor of CLIENT_STEERING

+1. I don’t think we actually use (old) steering anywhere in production. Steering does support the regex feature (use a regex to “pin” to a DS) and I don’t think the client_steering does, so we might want to consider moving that feature into client_steering. Steering also supports an overwrite

Re: New committer: Shihta Kuan

Welcome Shihta! On Mon, Mar 25, 2019 at 15:36 Dan Kirkwood wrote: > The Project Management Committee (PMC) for Apache Traffic Control has > invited Shihta Kuan to become a committer and we are pleased to announce > that he has accepted! > > Shihta has learned a great deal in a short amount of

Re: [EXTERNAL] [VOTE] Release Apache Traffic Control 3.0.0-RC4

Do you have an example of an endpoint that is in the 3.0 release that will not work now because of this bug? I think we should take a look at what is effected and make our decision from there. A release is not guaranteed to have no known issues, but we do need to decide if we can live with the

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

+1 I verified the following: Sha512, GPG signature (had an warning but that is ok) Built all components using pkg on a fresh Centos7.5 VM. It looked like there might be issues with weasel, but I am not going to -1 because of that because it's not critical to running Traffic Control. Thanks, Dave

Re: Removing old migration instructions

Submit a PR to remove them. Anything < 2.2 is not officially supported anyway. On Tue, Jan 8, 2019 at 2:56 PM Jeremy Mitchell wrote: > makes perfect sense to me > > On Tue, Jan 8, 2019 at 2:42 PM Fieck, Brennan > wrote: > > > Can anybody think of a reason why the ATC 3.x docs should include

new committer: Mike Sandman

The Project Management Committee (PMC) for Apache Traffic Control has invited Mike Sandman to become a committer and we are pleased to announce that he has accepted! Mike is a valuable asset to our project who brings a fresh, operations focused perspective. Mike is active on our mailing list and

Re: [EXTERNAL] Re: SSL cert validation via Traffic Ops API

Traffic Control only supports a very limited few (one, maybe two), so we shouldn't need to worry about that. On Fri, Nov 30, 2018 at 3:14 PM Gray, Jonathan wrote: > The instructions on adding a custom root CA to a server trust store are > going to vary by OS, Distro, and Major Rev. > > Jonathan

Re: SSL cert validation via Traffic Ops API

I can live with it. I still feel like there should be a way to bypass the validation, but I don't have a compelling reason for that right now. Maybe when I get my hands on this new code I will, but that can be a different discussion. Thanks for the follow through Rawlin, it is much appreciated.

Re: SSL cert validation via Traffic Ops API

+1 as well. I like that we are validating certificates, but I think we need a way to bypass as well. I also like Eric's suggestion. On Thu, Nov 29, 2018 at 6:35 AM Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) wrote: > +1 > Sounds like a

Re: eliminate RAT from build process

Is Rat providing license checking that is not covered by Weasel? What are we losing but no longer using Rat? On Mon, Nov 26, 2018 at 2:47 PM Dan Kirkwood wrote: > Hi, all.. I think weasel is mature enough that it covers our license > usage well enough. RAT is run as a separate job from

Re: [EXTERNAL] Re: Adding a text field in Servers config of TP

ith specific columns > >> per point > >>> > of > >>> > > data. This is how we ended up with unparsable, yet critical, > >> data in the > >>> > > comment fields of physical location table when we should have > >

Re: Adding a text field in Servers config of TP

+1, I am fine with it. That table already has a lot of columns, what's one more!? On Mon, Nov 19, 2018 at 2:59 PM Jeremy Mitchell wrote: > Sounds like server "notes" or a server "description". Seems like a fair > ask. I don't see the harm in adding an optional column to the server table > with

Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router

If I recall correctly the “testing” is really just to compare our own developed version vs the jdnssec version. As far as I am concerned we have proven it is more than adequate by running in production so those tests are no longer necessary. +1 on removing the now unnecessary dependency

Re: [EXTERNAL] The future of the db/admin.pl script

only slightly familiar with all the different options > for db/ > > > > > admin.pl. > > > > > > > > > > > > I’m a big fan of Python, but reluctant to introduce another > language > > > > > into TC without a

Re: [EXTERNAL] The future of the db/admin.pl script

+1, seems reasonable. I don’t really have an opinion on python 2.x compatibility, but whatever makes the most sense for the amount of work is what I would prefer. On Fri, Nov 9, 2018 at 18:06 Gray, Jonathan wrote: > +1 There is already precedence in the repo for python for other purposes. >

Re: Documentation guidelines

This is a lot. I don't think it looks bad, just feels like too much. I trust that we can present these in a way that makes it feel easy to understand and doesn't make someone want to just TL;DR. On Wed, Oct 31, 2018 at 10:20 AM Fieck, Brennan wrote: > this is my first pass at a set of

Re: [EXTERNAL] [VOTE] Release Apache Traffic Control 3.0.0-RC1

ng grove ... > > fatal: Not a git repository (or any of the parent directories): .git > > Cannot find repository root. > > grove failed: > > The following subdirectories had errors: > >grove > > > > > > —Eric > > > > > > > > > On Nov

  1   2   >