Re: Proposal: Remove Traffic Ops API Cache Config Endpoints

llable from the API, then maybe it should be a TP > extension, so operators can still see generated configuration files. > > On Mon, Nov 4, 2019 at 7:57 PM Robert Butts wrote: > > > >If we do it right, maintaining the two data-loading paths separately > from > >

Re: Proposal: Remove Traffic Ops API Cache Config Endpoints

: > > > > What if the config generator was an external service configurable through > > cdn.conf ? You could keep all the logic in one place, the API could > remain > > unbroken (depending on configuration), and people using Traffic Portal > > could still use the &q

Proposal: Remove Traffic Ops API Cache Config Endpoints

I'd like to propose we deprecate & remove the Traffic Ops ATS Cache Config endpoints. In fact, I'd like to propose we Deprecate in Master now, and in the following Major Release (5.0) that we remove the code and change the endpoints to return a 501 Not Implemented. This follows the TC SemVer

Re: [EXTERNAL] TO API routing blacklist

> I would propose that newly rewritten routes be added to this hardcoded list in TO-Go. Then after being in one release as "Perl-routable", they would become "non-Perl-routable" in the following release. I'm a big +1, as long as we're extra-vigilant about this. More than unroutable, we need to

Re: Question: Use ES6+ in Traffic Monitor UI?

gt; best practices updates and reformatting to make it easier to read? > > On Mon, Oct 21, 2019 at 10:43 AM Robert Butts wrote: > > > Quick question: would anyone be opposed if we used modern JS in the TM > UI? > > This is currently ECMAScript 2018, but I'm really asking if we

Question: Use ES6+ in Traffic Monitor UI?

Quick question: would anyone be opposed if we used modern JS in the TM UI? This is currently ECMAScript 2018, but I'm really asking if we're ok allowing any standard supported by the latest Firefox and Chrome. Of course, we could use a big framework like Angular, or a shim/polyfill compile tool

Re: Feature Proposal: Server Capabilities

| > > > On Wed, Oct 9, 2019 at 2:38 PM Derek Gelinas wrote: > > > I love this. +1 > > > > On Wed, Oct 9, 2019 at 12:46 PM Robert Butts wrote: > > > > > Hi all! We have a proposal for a new feature for TC: Server > Capabilities. > > &g

Feature Proposal: Server Capabilities

Hi all! We have a proposal for a new feature for TC: Server Capabilities. Blueprint is here: https://github.com/apache/trafficcontrol/pull/3972 In a nutshell, the problem we're solving is that it's impossible to only use certain Mids for certain Delivery Services. You can manually assign

Re: [EXTERNAL] Re: Inclusion of Golang Linter in CI

I think `pkg` is the right place to put this. `pkg` isn't just for building. I think it has that name because it's short, not because it's limited to "packaging." It also does things like the license checking via Weasel. It's more like `make`, which also isn't limited to building. It's really for

Re: New dependency: UUID

. We don't use any of > that information, so why bother doing it? Idk, do you think that could be > useful? Or just unnecessary? > > On Mon, Sep 23, 2019 at 10:24 AM Robert Butts wrote: > > > -0 > > > > Not a big deal, the library seems small and stable enough, and the >

Re: New dependency: UUID

-0 Not a big deal, the library seems small and stable enough, and the license is fine. But is it really necessary? Generating a V4 GUID is as simple as: uuid := make([]byte, 16) _, err := rand.Read(uuid) Do we need V1 GUIDs? IMO we should never be generating V1 GUIDs, unless they're absolutely

Re: Deprecate /capabilities/{{name}}

>- don't bother converting `/capabilities/{{name}}` from Perl to Go But we still have to support those routes, until API 1.x is no longer supported, which is far in the future. We should still rewrite deprecated Perl routes in Go, just so we can get rid of Perl sooner than that. On Thu, Aug

Re: Non-api API endpoints

api versions under 1.4, > but I want to be sure that's what you're saying. > > On Mon, Aug 12, 2019 at 2:59 PM Robert Butts wrote: > > > >GET /internal/api/$version/cdns/dnsseckeys/refresh > > > Exactly the same as /api/1.4/cdns/dnsseckeys/r

Re: Non-api API endpoints

>GET /internal/api/$version/cdns/dnsseckeys/refresh > Exactly the same as /api/1.4/cdns/dnsseckeys/refresh - needs backport > to v1.1? It didn't exist in 1.1, new things require new minor versions. All of these will have to go in a new minor version, currently 1.4+. We can only "backport"

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

; time > > > >>>> ago > > > >>>>>> Matt Mills was talking about using Kafka as the configuration > > > >>>> transport > > > >>>>>> mechanism for Traffic Control. The idea is to use a Kafka

Re: [EXTERNAL] Re: Go Rewrite Milestone

> help organize the non-ported endpoints and make it more visible as to which > Perl endpoints are still being used. > > -Daisy > > On 8/6/19, 8:46 AM, "Robert Butts" wrote: > > >There definitely are some that are still defined and not > commented-out in &g

Re: Go Rewrite Milestone

in > the Perl routes file. I haven't really thought about what to do with those > - maybe I'll just open an issue for each that says something like "Decide > what to do about {{route}}" and then deal with it later. Thoughts? > > On Tue, Aug 6, 2019 at 8:26 AM Robert Butts wrot

Re: Go Rewrite Milestone

Just to check, you all know this isn't a list of all endpoints in Traffic Ops, right? As the issue says, "all tables queried for the CRConfig." That list, which really existed for my own use for Self Service, is only the endpoints which query tables used in the CRConfig, and not including ATS

Re: Cache-Side Config Generation

gt; > Is that the eventual plan? Or does our vision of the future include this > *and* ORT? > > > On 7/30/19 2:15 PM, Robert Butts wrote: > > Hi all! I've been working on moving the ATS config generation from > Traffic > > Ops to a standalone app alongside ORT, that quer

Cache-Side Config Generation

Hi all! I've been working on moving the ATS config generation from Traffic Ops to a standalone app alongside ORT, that queries the standard TO API to generate its data. I just wanted to put it here, and get some feedback, to make sure the community agrees this is the right direction. There's a

Re: Integration with LetsEncrypt needs TR updates / automatic Snapshot

I agree with @mitchell852 , automating snapshots is highly dangerous at the moment. Even the diff doesn't necessarily catch everything, and even if it did, there's a race between diffing and snapshotting. DS Snapshots mitigates the issue, but doesn't solve it entirely. The right solution is to

Re: Traffic Ops Mock Server implementation details

+1 >which do you think we should use? Both. Both offer different degrees of simplicity vs accuracy. If this is useful to @Brennan_Fieck, I vote we merge it in. If someone makes another mock server with a different simplicity/accuracy tradeoff, I vote we merge that in for them too. If one of

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

>What about a solution that still might employ nested, anonymous, versioned structs, except that the only code that is unique to each versioned struct is how requests of that version can be "upgraded" into requests of the next latest version? I'm +1 on that solution. I'm not 100% clear on what

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

ython+Java TO clients) to > continue > > working as they do today, only having to worry about the API > major > > version. > > > > For clients that might be more susceptible to data loss due to > > addition of unknown fields (e.g. G

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

> properly (e.g. Traffic Portal, Python+Java TO clients) to > > continue > > > working as they do today, only having to worry about the API > > major > > > version. > > > > > > For clients that might be more susceptible to da

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

; TO API v5 > > we support minor versions with TC but not with TO API. > > jeremy > > On Fri, Apr 19, 2019 at 12:01 PM Robert Butts wrote: > > > I'm trying really hard to come up with a solution that addresses > everyone's > > major concerns. I think we'll have a

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

lame for our > lack of progress on our migration to Golang, but it's one more thing > that is slowing us down and definitely hasn't helped improve progress. > -- > Thanks, > Jeff > > On Thu, Apr 18, 2019 at 3:23 PM Robert Butts wrote: > > > > >This is abo

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

ously we have to hold up our end of the deal and have good API > documentation and change logs. I think the cost of maintaining that is > much less than API versioning given our experience, especially after > we simplify the APIs. We're already doing much of that today. > -- > Th

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

>When API version 1.3 came out, why could I not call 1.3 for every API route even if the route didn't change? That was a Perl mistake, and a bug. >Why not point the 1.3 to the 1.1 for example? Go does, and we manually do in Perl now, too. On Thu, Apr 18, 2019 at 11:47 AM Hank Beatty wrote:

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

>Without minor versions, #3497 would not even an issue. It's only an issue because of the attempt to support minor versioning. That's simply not true. It's exactly the same issue. Removing minor versioning just hides the issue. You have declared: >only certain clients that don't handle new

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

ld not drop unknown fields > returned by the API". > > - Rawlin > > On Wed, Apr 17, 2019 at 12:55 PM Robert Butts wrote: > > > > It seems like we don't have consensus on this. SemVer is painful in Go; > but > > improves the user experience, and pre

Re: [EXTERNAL] Re: Traffic Ops API versioning issues

>>>> "Mojolicious Mindset" refers to the use of URL path > > > fragments as request parameters, e.g. > > > >>>> '/users/{{ID}}' instead of/in addition to > > > '/users?id={{ID}}'. From the perspective of someon

CiaB Test Compose Outputting JUnit?

Does anyone object to making the cdn-in-a-box test compose files (e.g. https://github.com/apache/trafficcontrol/blob/master/infrastructure/cdn-in-a-box/docker-compose.traffic-ops-test.yml) output JUnit format? I made an internal fork to do that for `docker-compose.traffic-ops-test.yml` as well as

Re: [EXTERNAL] Tenancy no longer optional?

> Not sure what's required in the Go to ensure that tenancy can't be turned off. And yes, it's pretty easy in Go, too. Just a matter of removing those query bits, and calls to IsTenancyEnabled. On Tue, Jan 8, 2019 at 10:09 AM Rawlin Peters wrote: > I believe we essentially agreed to make

Re: [EXTERNAL] Tenancy no longer optional?

> we discussed this and agreed that moving forward tenancy should no longer be optional in TP/TO but I can't find the email I think it's this discussion, subject "Enforcing capability rules"

Delivery Service Snapshots

I have a WIP PR for Delivery Service Snapshots, using the timestamp versioning plan: https://github.com/apache/trafficcontrol/pull/3175 It follows https://cwiki.apache.org/confluence/display/TC/Traffic+Control++Self+Service+Proposal+for+Change+Integrity With one major exception: it creates new

Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services produces indeterminate parent.config

OIN deliveryservice ds ON ds.id = o.deliveryservice WHERE o.is_primary ORDER BY fqdn; ``` On Tue, Dec 18, 2018 at 1:09 PM Robert Butts wrote: > >can you give an example of what parent.config looks like when 2 ds's > share an origin and have different a different topology? > > A

Re: [EXTERNAL] Re: Origins assigned to Multipe Delivery Services produces indeterminate parent.config

>can you give an example of what parent.config looks like when 2 ds's share an origin and have different a different topology? Answering because I encountered this directly, when rewriting parent.config. For example: Suppose you have one Delivery Service: XML_ID: foo Type: HTPT_LIVE_NATL Query

Re: Server groups (profiles)

Yep, already part of the Self Service plan. The plan is to add a "default_assignable" field to servers, to indicate which servers are assigned to new delivery services on creation. You're right, it's necessary for Self-Service, or non-operators wouldn't be able to create functioning DSes. And I

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

This sounds like an Asset Management thing, not a CDN thing. We currently have a number of "Asset Management" fields (like ASNs) which aren't necessary for the CDN itself, and just asset tracking. Personally, I'd rather see us move toward the CDN being a CDN, and operators using an Asset

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

Just FYI, it looks like it's on Github, by the original author: https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it looks like it'd be trivial to fix and keep, if we wanted to. On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan wrote: > +1 on removing > > I'm not super familiar

Re: Traffic Ops code re-structure

Well, when I originally wrote `traffic_ops_golang`, I just put everything in the `main` package, with the assumption that we'd move components as they got big enough. It seems self-evident to me that these should be packages, very little should go in `main` in any nontrivial Go app. I don't really

Re: Drop support for Traffic Ops DB downgrade

> simply restore pre-upgrade copy of the DB What about the data manually changed in-between? What if you've been running for a week before discovering a critical issue requiring rollback? All those changes would be lost? On Fri, Oct 19, 2018 at 8:07 AM Dave Neuman wrote: > I think this sounds

Re: API version and database id's

+1. All the +1s. I do think there are some "real" IDs we might have to keep, where an ID is the real, only Candidate Key (maybe regex?), But for everything else, using the real Candidate Key will be _drastically_ easier to work with. It'll make posting a DS or Server without prior info 1 req

Re: [EXTERNAL] Re: Single-Layer CDN Support - PR 2904

Just out of curiosity, how difficult would it be to similarly support an arbitrary number of tiers, by similarly checking if the parent _isn't_ an origin and doing the reverse? (I'm aware of the hackish and perilous ways TC can go edge-to-edge, I'm wondering about formalized and safe support.) On

Re: Traffic Ops Extensions in Go

so, there's the question of the plugin interface versioning. How > > > will we be versioning the plugin interface with guarantees to not > > > break any plugins outside of our repo? Should we start out by tagging > > > this plugin framework as experimental so that we don't really provide

Re: Traffic Ops Extensions in Go

e URL. > > Would that not work? > > Cheers, > JvD > > > On Oct 1, 2018, at 09:50, Robert Butts wrote: > > > > @jan this is for extensions, for code an organization isn't able to open > > source. > > > > Sure, you could just add a line to `routes

Re: Traffic Ops Extensions in Go

micro service? > > Rgds, > JvD > > > > On Oct 1, 2018, at 09:39, Robert Butts wrote: > > > > So, as we move Traffic Ops from Perl to Go, we need a way to write > > extensions in Go, like we have in Perl. > > > > I wrote a plugin system for Go, mod

Traffic Ops Extensions in Go

So, as we move Traffic Ops from Perl to Go, we need a way to write extensions in Go, like we have in Perl. I wrote a plugin system for Go, modeled after the plugin frameworks in Grove and Traffic Monitor, PR is here: https://github.com/apache/trafficcontrol/pull/2513 It's by no means complete,

Re: Traffic Ops profile import/export format

her. As long as the default > profiles are updated to the new format, I think that would solve most > of the problem for our users. > > - Rawlin > > On Mon, Sep 17, 2018 at 3:05 PM Robert Butts wrote: > > > > >It just seems wrong to me to add a new API endpoint to sup

Re: Traffic Ops profile import/export format

in the next > release. > > - Rawlin > > On Mon, Sep 17, 2018 at 1:51 PM Robert Butts wrote: > > > > >Do we really want to add a new API endpoint just to support the legacy > > format > > > > An endpoint and UI page are easier to use for Self-Ser

Re: Traffic Ops profile import/export format

; - Rawlin > On Mon, Sep 17, 2018 at 11:04 AM Robert Butts wrote: > > > > Ah, excellent. It wasn't clear from the docs that `POST > /api/1.2/profiles` > > and `GET /api/1.2/profiles/:id` accept parameters. We should fix that. > > > > That said, I would be in fav

Re: Traffic Ops profile import/export format

POST /api/*/profiles <-- this is how you create profiles. if you supply > > parameters as well you've essentially done an import. > > > > jeremy > > > > > > > > On Mon, Sep 17, 2018 at 9:16 AM Robert Butts wrote: > > > > > Can you cl

Re: [EXTERNAL] Re: Removing uid and gid from user

omise... > > > > i would be curious if > > > > PUT api/*/users/:id > > PUT api/*/user/current > > > > really allows you to change them and if it does even more of a reason to > > keep them because maybe somebody is setting those id's for some reason... >

Re: [EXTERNAL] Re: Removing uid and gid from user

id > PUT api/*/user/current > > really allows you to change them and if it does even more of a reason > to > keep them because maybe somebody is setting those id's for some > reason... > > TO API 2.x we nix those imo (unless somebody is really using those > fields)

Re: [EXTERNAL] Re: Removing uid and gid from user

-1 on removing them from the API, they're part of API 1.x, we can't remove them without breaking Semantic Versioning. +1 on removing from the db, hard-coding the API to return nulls, and documenting them as deprecated in the API. The db has no "version promise", we can definitely clean that up.

Re: Github PR/Issues Format Templates

to make the process better, we are > not trying to sabotage people so that they can never get their PRs merged. > We have already said that we know that all of this template won't > necessarily apply to all changes. > > At the very least we should try this for a few months, see if it

Re: Github PR/Issues Format Templates

rk with the > rest of the PMC to ensure it doesn't happen again. > > In my opinion, this template is the balance between getting things done and > doing things the right way. PR templates are pretty standard in the open > source community -- as are requiring tests and documentation for that

Re: Github PR/Issues Format Templates

> What is the best way to verify this PR? +1 > Check any that apply > >- [ ] This PR does *NOT* fix a serious security flaw. Read more: [ www.apache.org/security](http://www.apache.org/security/) >- [

Re: [EXTERNAL] Marking a Cachegroup as "Coverage Zone only"

this table rather than the one-off flag > > > Definitely +1 to keep this extensible, as there will be more > localization types in the future (Anycast, etc,… We at Cisco also have a > network hops localization policy engine too, although its not open-sourced) > &

Re: Making parent.config's go_direct directive configurable via Delivery service

I'm inclined to agree with not adding new DS types. Yeah, we'll need code for `if go_direct is undefined...`, but I'm pretty sure we'd need equal or more code, across all our apps, to handle the new types. We have a ton of code that checks `if dstype == HTTP_LIVE { ... } else if dstype ==

[ANNOUNCE] Apache Traffic Control 2.2.0 released

The Apache Traffic Control team is pleased to announce the release of Apache Traffic Control 2.2.0. Apache Traffic Control allows you to build a large-scale Content Delivery Network (CDN) using open source. Built around Apache Traffic Server as the caching software, Traffic Control implements all

Re: Removing dead Perl code

de into a new test-only function and call that > from the test? > Just delete the test because it depends on a dead endpoint? > Delete and rewrite it in the Go testing framework? > > - Rawlin > > On Sun, Jun 24, 2018 at 1:45 PM, Dan Kirkwood wrote: > > On Sat,

Re: Removing dead Perl code

>as long as we have 100% feature complete with the Go code (which I think we're fairly close?) We are not close. We are at 108 of 240 endpoints. >if we do not treat the tests as first class citizens (meaning we implement an Go endpoint and build coverage as we go), then why bother at all? It

Re: Removing dead Perl code

+1 on removing dead code. IMO the danger and cost of the dead code far outweighs the benefit of the Perl tests. Especially considering AFAIK most of the tests are just verifying the response is a 200, not actually checking the body or database or validating anything. We just had someone in the

Re: Enforcing capability rules

>will the self-service stuff rob butts is working on be affected in any way? Will self-service truly be turned off via a parameter? What I'm working on, change integrity, shouldn't be affected by turning off tenancy/roles/capabilities. And we shouldn't turn off the API-visible parts of what

Re: [VOTE] Update Traffic Control to Version 3.0

>Does this also present an opportunity to do some breaking API changes for Traffic Ops that we’ve been wanting to do? @jvd Technically yes, but I'd vote we don't, because it's going to add a lot more work to Self-Service to try to port APIs, maintain two major API versions for at least a major

Re: [VOTE] Update Traffic Control to Version 3.0

+1 Dropping support is breaking change, and needs a major version increment, per Semantic Versioning. On Tue, Jun 5, 2018 at 10:03 AM, Jeff Elsloo wrote: > In light of the major changes introduced into Traffic Router with PR > 2331, I would like to call a vote to increase the major version of

[RESULT][VOTE] Release Apache Traffic Control 2.2.0-RC6

Thanks to all who voted! The release has PASSED with the following IPMC votes: +1 Jeff Elsloo (binding) +1 Steve Malenfant (binding) +1 Dan Kirkwood (binding) I will proceed to publish the release and send ANNOUNCE. On behalf of Apache Traffic Control, thank you! Regards, Robert O Butts

Re: [VOTE] New Traffic Control Website

+1 Looks great! On Fri, May 18, 2018 at 9:06 AM, Eric Friedrich wrote: > Hey- > Based on some feedback from the incubator, we put together a new website > that doesn’t look like its from Geocities. > > I’m providing links to all the pages because some of the internal links