Re: [VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC4

+1 Tested: TP TO API On Fri, Apr 13, 2018 at 3:46 PM, Jeff Elsloo wrote: > +1 > > Tested: > -`./pkg` > - signatures validate > - upgrade of Traffic Router works without issue > -- > Thanks, > Jeff > > > On Fri, Apr 13, 2018 at 10:26 AM, Dan Kirkwood

Re: Updated TO API guidelines

uffix should be supported for new API > endpoints? It seems pointless because the API will always return JSON. > > - Rawlin > > On Fri, Apr 6, 2018 at 3:14 PM, Jeremy Mitchell <mitchell...@gmail.com> > wrote: > > Rawlin, > > > > I have submitted a PR to change so

Re: Updated TO API guidelines

o you return if the query > parameter is left off, all uri signing keys? Is that useful? > > John > > > On Apr 4, 2018, at 3:23 PM, Jeremy Mitchell <mitchell...@gmail.com> > wrote: > > > > tbh i'm not sure about versioning. I was just trying to suggest that

Re: Traffic Control Doc's Proposal

Can you clarify what a "howto" is? Yes, it looks like our README's are a bit out of control. What if we consolidated them like such: ./README.md <-- this one links to general information about TC (readthedocs) and also links to the following: ./traffic_portal/README.md

Re: Updated TO API guidelines

query parameters breaks compatibility with 1.2 > and older, so new APIs in that format have to be a new major version, i.e. > 2.0, per Semantic Versioning, right? > > On Tue, Apr 3, 2018 at 3:26 PM, Jeremy Mitchell <mitchell...@apache.org> > wrote: > > > FYI - I've updat

Re: [VOTE] Resolution for Traffic Control graduation to TLP

> > >> direction of the Board of Directors as the chair of the Apache Traffic > > >> Control Project, and to have primary responsibility for management of > > >> the projects within the scope of responsibility of the Apache Traffic > > >> Control P

Updated TO API guidelines

FYI - I've updated the TO API guidelines to reflect our desire to move away from route/path params and embrace query params in the Golang API. https://cwiki.apache.org/confluence/display/TC/API+Guidelines Jeremy

Re: Traffic Ops Change log

; Service Requests (DSRs) comments. I think DSRs are turning out to be the > > Change Log for Delivery Services and comments on those are Change Log > noise. > > > > -Dew > > > > On Wed, Mar 21, 2018 at 10:24 AM, Jeremy Mitchell < > mitchell...@apache.or

Traffic Ops Change log

Currently, every POST (create), PUT (update) or DELETE (delete) TO API endpoint (or most of them) create a change log entry. For example when i PUT /api/cachegroups/4 it creates this CL entry: myusername - Updated Cachegroup named 'Foo' with id: 57 Question: In the golang rewrite of the TO API

Re: Traffic Ops Access Control v2

s NOT get > that admin DOES get? Trying to differentiate between the two. > > Thanks, > Dave > > On Thu, Mar 8, 2018 at 9:53 AM, Jeremy Mitchell <mitchell...@apache.org> > wrote: > > > There has been some discussion for quite some time regarding an overhaul >

Traffic Ops Access Control v2

There has been some discussion for quite some time regarding an overhaul of the TO access control model. I'd like to refresh eveyone's memory on that discussion. *Current system:* Since the beginning, resources (or routes (UI and API)) have been locked down by role, or more specifically,

Traffic Ops UI Deprecation in favor of Traffic Portal

At last year's TC summit, we discussed the deprecation of the TO UI in favor of the Traffic Portal. Now that TP has almost achieved feature parity with the TO UI, that day is coming soon. Here are 2 issues I know that need to be complete to achieve feature parity:

Re: [VOTE] Traffic Control graduation to TLP

+1 On Thu, Mar 1, 2018 at 2:06 PM, Nir Sopher wrote: > +1 > > On Mar 1, 2018 10:27 PM, "Steve Malenfant" wrote: > > > +1 > > > > On Thu, Mar 1, 2018 at 12:14 PM, Phil Sorber wrote: > > > > > +1 > > > > > > On Thu, Mar 1, 2018 at 1:12 PM

Re: Github PR/Issues Format Templates

the commit message mentions the appropriate > issue > >>> > number. > >>> > - [ ] This PR does *not* fix a serious security flaw. (Read more: > >>> > www.apache.org/security ) > >>> > - [ ] Automatic code formatters (like gofmt) have been ru

Re: Github PR/Issues Format Templates

ught to take a look at this?* > > ... > > We want to be friendly to committers, while still getting good > information for checking PRs. I could be easily convinced that the > "Tests" or "Doc updates" sections in there are too long, but I think > it should be c

Re: Github PR/Issues Format Templates

AM, Jeremy Mitchell <mitchell...@gmail.com> wrote: > With an issue and/or pr template, we will have 6/6 items checked: > > https://github.com/apache/incubator-trafficcontrol/community > > I actually think PR templates would be quite helpful. As a > committer/merger, it wo

Re: Steering Target Geo-Ordering

uld get the list [S1, > S2, D2, D1, B1, B2], where D1 and D2 are consistent hashed based upon > the requested URL and given weight. So if they request /bar maybe D1 > and D2 are switched so they get [S1, S2, D1, D2, B1, B2]. > > - Rawlin > > On Mon, Feb 26, 2018 at 8:18 PM, Jeremy Mitc

Re: Github PR/Issues Format Templates

With an issue and/or pr template, we will have 6/6 items checked: https://github.com/apache/incubator-trafficcontrol/community I actually think PR templates would be quite helpful. As a committer/merger, it would be nice to know what problem the PR is solving and how to verify the functionality.

Re: Steering Target Geo-Ordering

So, back to the Seattle, Denver, Boston example... To accomplish the geo ordering and redundant origin use case, you'd create 3 HTTP_LIVE delivery services? One with an origin in seattle. One with an origin in denver. One with an origin in boston. (or would you create 6 ds's so you have 2 in each

Re: Traffic Ops API Swagger Doc

t; > I guess this means there will need to be a PR to remove our current API > > docs as they get moved to swagger. > > > > On Tue, Feb 20, 2018 at 8:40 AM, Jeremy Mitchell <mitchell...@gmail.com> > > wrote: > > > >> I think this all sounds very promisi

Re: Traffic Ops API Swagger Doc

I think this all sounds very promising. Some advantages that I see are: - docs never drift from API implementation (currently our docs get out of sync real fast) - this provides yet another interface - https://app.swaggerhub.com/apis/dewrich/traffic-ops_api/1.3 - (in addition to TP) to interact

Re: New Self-Service Initiative - Delivery Service Request System

If you haven't had a chance to read https://cwiki.apache.org/ confluence/display/TC/Delivery+Service+Requests, I would recommend it. Self-service is quite a large undertaking so to make it more digestible, we've created the notion of "delivery service requests". Think of it like PRs (or pull

Re: Immutable DS CDN - resolving Riak/Postgres data coherency

First, I'm +100 on doing a riak clean-up on DS delete but not a partial cleanup (just latest) but a full cleanup (ALL SSL keys (if applicable), ALL url sig keys (if applicable), ALL URI signing keys (if applicable)). Otherwise, when a DS gets created down the road with that same xml-id, problems

Re: Delivery Service Self-Service

the actual caches, but can > use some filters/tagging for defining the caches to be used. > > Nir > > On Mon, Feb 5, 2018 at 8:23 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > > > Replies inline > > > > On Fri, Feb 2, 2018 at 1:43 PM, Jerem

Delivery Service Self-Service

As we move in the direction of self-service, there are a few obstacles that need to be overcome and I'd like to discuss them a bit so grab a cup of coffee... When I say self-service, what I really mean is "delivery service self-service" or the ability to manage your own delivery services (as

Re: [VOTE] CHANGELOG.md file (second try)

;>>> are super technical or involved in the day to day so we shouldn't just > >>>> point them at a list of PRs and say "figure it out"; we should make it > >>> easy > >>>> for them to figure out. > >>>> > >>>> I hav

Re: [VOTE] Release Apache Traffic Control (incubating) 2.1.0-RC3

+1 On Wed, Dec 20, 2017 at 5:34 PM, Steve Malenfant wrote: > +1 > > On Wed, Dec 20, 2017 at 5:14 PM, Dave Neuman wrote: > > > +1 > > > > On Wed, Dec 20, 2017 at 8:33 AM, Hank Beatty wrote: > > > > > Hello All, > > > > > > I've

Re: [VOTE] CHANGELOG.md file (second try)

ude a new CHANGELOG label that you could > > tack > > >> onto specific PR's that you wanted to be included (as well as grouped > > >> within Milestones) as the high level features that went into the > > release. > > >> As for the gotchas, I think those should be Gi

Re: [VOTE] CHANGELOG.md file (second try)

Those are the reasons why I tend to lean towards a manual changelog. It > gives us the ability to control how much information goes into the > changelog and the flexibility to make sure it is useful. > > On Thu, Dec 14, 2017 at 8:13 AM, Jeremy Mitchell <mitchell...@gmail.com> &

Re: [VOTE] CHANGELOG.md file (second try)

Why not leverage Github issues/milestones to determine the scope of each release? Per our CONTRIBUTING.md : "If you have improvements (enhancements or bug fixes) for Traffic Control, start by creating an issue

VISION.md

At Comcast, we've discussed the need for a document that outlines the short/long-term goals of TC. Rather than calling this a roadmap which implies time/deadlines, we thought VISION.md might be appropriate. I imagine VISION.md will contain (for now) a simple, bulleted list of goals such as: -

Scoping a release

At the Traffic Control summit, we discussed the need to do a better job scoping releases. What changes can I expect in an upcoming release? What changes went in to a completed release? The only way I can think to do this (without having a release manager that actively manages the scope of a

Re: Delivery Service Properties

I've also created an issue ( https://github.com/apache/incubator-trafficcontrol/issues/1543) and subsequent PR (https://github.com/apache/incubator-trafficcontrol/pull/1548) to address the different requirements of each type of DS. On Wed, Nov 15, 2017 at 3:10 PM, Jeremy Mitchell <mitch

Delivery Service Properties

>From what I can tell, there are 4 flavors of delivery services: 1. DNS* 2. HTTP* 3. STEERING* 4. ANY_MAP And the properties associated with each flavor vary so I put together a spreadsheet to show which properties pertain to each flavor:

Re: Traffic Ops API Semantic Versioning

> >> Heh, I agree on the arguing about API versions, but I just want to > >> hand the task to Semantic Versioning, so we can just ask some simple > >> questions like "did we break backward compatibility" and "did we add > >> something" and figure out

Re: Traffic Ops API Semantic Versioning

st two numbers as "major" and the last as "minor". I'm -1 > on locking it to the version of TC. I'm +1 on providing /version and > /minversion endpoints to allow clients to auto-detect incompatibility. > > On Thu, Oct 19, 2017 at 12:54 PM, Jeremy Mitchell <mitc

Re: Traffic Ops API Semantic Versioning

looks like we would > rev the version every TC minor release, even though it may not contain > breaking changes? > > > > > On Oct 19, 2017, at 2:54 PM, Jeremy Mitchell <mitchell...@gmail.com> > wrote: > > > > With the Golang API rewrite, we were not plannin

Re: Traffic Ops API Semantic Versioning

With the Golang API rewrite, we were not planning to break any APIs but rather simply port them to Golang thus we did not see the need to rev the API version from 1.2. However, maybe this is good opportunity to get our API version inline with the TC version. So, my thought is that our Golang

Re: Traffic Ops Rewrite Golang Dependency - sqlx

@dewayne - you said "performance was +/-5% depending on the cloud resources that were active". How many milliseconds difference (average) are we talking about for ONE call to /api/1.2/servers (using sqlx and not using sqlx)? I'm assuming it is so small that we can rule out performance as a factor

Re: [VOTE] Bugtracking in Github Issues

+1 but the fact that only committers can be assigned to issues is a big problem in my opinion. On Tue, Aug 29, 2017 at 7:16 PM, Eric Friedrich (efriedri) < efrie...@cisco.com> wrote: > Thanks Leif- > I’ll check with the Incubator gurus. We already pulled the trigger, so > at this point its

Global parameters and seeds.sql

IMO there seems to be an inherent flaw with global parameters and that flaw is exposed in via seeds.sql. Let's use an example. There is a global parameter called tm.toolname with a seeded value of 'Traffic Ops' (

Re: Adding support for per-DeliveryService routing names

wer is yes, it's a breaking API change. > > > > So, really the only way around this is to "default" the new field's > value > > and make it optional, otherwise the API needs to rev. > > > > -Dew > > > > On Tue, Aug 15, 2

Re: Adding support for per-DeliveryService routing names

routing name in traffic_router/http.properties which is no longer > going to > be used after the upgrade. The upgrade needs to somehow know about > this > other routing name and use that when it creates the database column and > populates it with the pre-defined defaul

Re: Adding support for per-DeliveryService routing names

Adding a temp parameter would work but I worry that someone won't read the upgrade documentation and forget to create this temporary parameter before running the upgrade. Here's another option. Create 2 global TO parameters (http.routing.name and dns.routing.name )

Re: Data patches during upgrade

This seems to make sense to me but honestly, I'd probably defer to Dewayne. In theory, it would be nice if migrations only included "structural" changes (new tables, columns, changing column types or not null, etc) and seeds focused on the "base" (or the minimum required) static data required of

Re: LDAP Access

> @mitchell852 Actual PostgreSQL users. So, Traffic Ops users would _be_ PostgreSQL users. There wouldn't be a single "trafficops" Postgres user, every TO user would have their own user in Postgres itself. ^^ Sounds like we need a Postgres DBA for that :) Plus, I think that ship has sailed when

Re: LDAP Access

> I also wonder if we shouldn't try to leverage transitioning our user management to Postgres. I don't understand what that means. We do use Postgres for user management...there is a tm_user table in Postgres and a user has a role (which will soon have capabilities). That is how users are managed

Re: Duplicate TO API routes

he same Perl module, I'm ok > as well > > On Tue, Apr 18, 2017 at 4:27 PM, Dave Neuman <neu...@apache.org> wrote: > > > I assume you did a check of the client to make sure it wasn't using those > > routes? > > Other than that, no concerns here. > > >

Re: [VOTE] Move Traffic Control to full GitHub

+1 On Thu, May 18, 2017 at 3:35 PM, Dave Neuman wrote: > +1, thanks for putting the vote up Jan > > On Thu, May 18, 2017 at 4:57 PM, Steve Malenfant > wrote: > > > +1 > > >

Re: API GW route configuration

is unavailable. > > Your assumptions are correct. We need to figure out the easiest topology > for UI routes to bypass the GW. Please reattach the picture so we can get > more specific. > > Thanks > /amiry > > > > On Thu, May 11, 2017, 20:06 Jeremy Mitchell <mi

Re: API GW route configuration

equent as one might hope. It's easy to > implement, though. > > On Thu, May 11, 2017 at 10:12 AM Jeremy Mitchell <mitchell...@gmail.com> > wrote: > > > Regarding the TTL on the JWT token. a 5 minute TTL seems silly. What's > the > > point? Unless we get

Re: API GW route configuration

Regarding the TTL on the JWT token. a 5 minute TTL seems silly. What's the point? Unless we get into refresh tokens but that sounds like oauth...blah. What about this and maybe i'm oversimplifying. the TTL on the jwt token is 24 hours. If we become aware that a token has been compromised,

Re: Removing 'internal' from TO API

I think with that, > we > > don't need these special routes at all anymore, right Amir? > > > > Cheers, > > JvD > > > > > > On Wed, Mar 15, 2017 at 9:24 PM Dewayne Richardson <dewr...@gmail.com> > > wrote: > > > > > I think we sh

Re: Access Control - Limiting Roles / Capabilities Tenant Admins can Assign to Users

Admins to assign > roles to users which they have access. Basically you can’t give anyone > more rights than you have. > 3. Perhaps with this approach we allow non-CDN Admins to build roles from > existing capabilities to which they have access, but not create > capabilities from AP

Re: Proposed changes to xml_id on a delivery service (from the API perspective)

e ds.regex at other position of type > > > HOST_REGEXP is not working for HTTPs. I think the reason is SAN is no > > > supported in currently implementation in “generate_ssl_keys”. Do we > have > > > any plan to support multiple subdomain for HTTPs? > > > > > > If we do

Re: Duplicate TO API routes

yep, not used by TO client, dave. On Tue, Apr 18, 2017 at 4:27 PM, Dave Neuman <neu...@apache.org> wrote: > I assume you did a check of the client to make sure it wasn't using those > routes? > Other than that, no concerns here. > > On Tue, Apr 18, 2017 at 12:37 PM, Jere

Re: Traffic Ops database unique constraints

I created a Jira - https://issues.apache.org/jira/browse/TC-222 I'll submit a PR shortly if there are no objections. On Tue, Apr 4, 2017 at 2:18 PM, Jeremy Mitchell <mitchell...@gmail.com> wrote: > and i forgot one. i'd like to make parameter unique by > name/config_file/value >

Re: 2.0 release?

These all got fixed and backported to 2.0: TC-203: Mojo doesn’t set cachable headers on public files” TC-190: TTL type mismatch in CrConfig TC-189: ssl_multicert.config too slow So Jan and Dave just need to close the issues. On Tue, Apr 4, 2017 at 12:22 PM, Jeffrey Martin

Re: Traffic Ops database unique constraints

configuration.') ON CONFLICT (name) DO NOTHING; and no more duplicate seeds... On Tue, Apr 4, 2017 at 1:12 PM, Jeremy Mitchell <mitchell...@apache.org> wrote: > I have moved all Traffic Ops seed data into ONE place - > https://github.com/apache/incubator-trafficcontrol/blob/ > master/tra

Traffic Ops database unique constraints

I have moved all Traffic Ops seed data into ONE place - https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/db/seeds.sql (there used to be some in seeds.sql and others in traffic_ops/install/data/json) Anyhow, if you run seeds.sql multiple times (i.e. db/admin.pl

Re: Changing Traffic Portal default page

Unfortunately, there isn't a way currently to create custom html pages and override the existing html pages of the traffic portal. There is, however, a way to override styles - https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_portal/app/src/assets/css/custom.css but...that

Re: Removing 'internal' from TO API

@gmail.com> wrote: > At least a few of those (Steering, federations) were put in the "internal" > namespace to work around Comcast specific issues. I don't know that I like > the idea of duplicating routes, if anything we should see what is impacted > by moving them out of the in

Re: Github "Backport" Label

Actually, I'm a bit surprised you were even able to create the 'backport' label - https://github.com/apache/incubator-trafficcontrol/labels how did you do that? please tell. :) On Mon, Mar 13, 2017 at 7:59 PM, Jeremy Mitchell <mitchell...@gmail.com> wrote: > I didn't know we could crea

Re: Github "Backport" Label

I didn't know we could create labels and apply them. If so, I think this would be fantastic...but like Dave, I don't see how to do it. :( On Mon, Mar 13, 2017 at 7:57 AM, Phil Sorber wrote: > You can also search on the branch base. Something like: "is:pr is:open > base:2.0.x"

Re: Access Control Model

gt; > > > LDAP should be avoided as we are now finding that it's not a > preferrable > > > way of logging in based upon Security Concerns. If needed for some > > reason > > > down the road we should consider it as a separate Micro Service that > can >

Re: Access Control Model

thinks is a good idea or not) the requests of that google doc would be satisfied. Jeremy On Wed, Feb 22, 2017 at 10:33 AM, Jeremy Mitchell <mitchell...@gmail.com> wrote: > +1 on Dave's question. ldap is an edge case that we probably have to > account for. so with this new approa

Re: Access Control Model

+1 on Dave's question. ldap is an edge case that we probably have to account for. so with this new approach, 2 things are checked - your role (what you can do) and your tenancy (scope of what you can do). first one - role: we'll need to think how ldap authenticated users (that don't have an

Re: Upcoming TC 2.0 Release Branch

Yeah, we've done a lot of Postgres testing against the master branch. I'm afraid if Jan drops his PR in it will nullify a lot of that testing (as his changes are pretty extensive). So my preference would be to create a 2.0 branch very soon (in a couple of days like Neuman said?) which should give

Re: Github PR suggestion

/ mailing list discussion required for new features and optional for bugs? On Wed, Feb 15, 2017 at 8:07 PM, David Neuman <david.neuma...@gmail.com> wrote: > I am -1 on it being "required" however, I am ok with saying we prefer it. > > > On Wed, Feb 15, 2017 at 20:

Re: Possible bug in traffic ops when sending an e-mail

I'll have to defer to someone else as most of that was way over my head but I do know we have this ticket outstanding: https://issues.apache.org/jira/browse/TC-74 and also, this PR was merged a while back regarding $SIG{CHLD} - https://github.com/apache/incubator-trafficcontrol/pull/155 I'm not

Re: TO - Queue server updates on delivery service servers only?

on that issue. Jeremy On Wed, Feb 1, 2017 at 8:58 PM, Jeremy Mitchell <mitchell...@gmail.com> wrote: > Created this issue. Would like input from more people to ensure this is a > good idea and I'm not overlooking something... > > https://issues.apache.org/jira/browse/TC-129 > > On

Re: TO - Queue server updates on delivery service servers only?

it would be useful to have an API to queue on > just servers relevant to that DS. > > —Eric > > > On Jan 31, 2017, at 12:36 PM, Jeremy Mitchell <mitchell...@apache.org> > wrote: > > > > Currently, you can queue updates: > > > > - for a spec

Re: Invalidate Content Error

I created this issue to account for seed data lost in the transition from 1.8 to 2.0 https://issues.apache.org/jira/browse/TC-126 On Wed, Feb 1, 2017 at 10:26 AM, Jeremy Mitchell <mitchell...@gmail.com> wrote: > hmmm. i think you've stumbled on a larger issue. the move from 1

Re: Invalidate Content Error

to manually manipulate the DB, even if that user is novice and > just did a fresh TC install ;-) > > On Wed, Feb 1, 2017 at 5:47 PM, Jeremy Mitchell <mitchell...@gmail.com> > wrote: > > > It works IF he does a manual insert into the job_agent table and it so > > happe

Re: Invalidate Content Error

In my opinion, the job agent id should have been passed to the newjob() subroutine rather than depending on a hard-coded value...actually, it looks like that was the intent but the $agent variable never got used.

Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)

+1 tested TO UI, TO API and TP (traffic portal). On Fri, Jan 27, 2017 at 9:46 AM, Dan Kirkwood wrote: > +1 > > -- was assuming as release manager I didn't get a vote, but not true? > > I tested: > - signature and checksums good > - build from gitrepo and RC9 tag > -

Re: TC 2.0.x branch

gds, > > JvD > > > >> On Jan 6, 2017, at 4:44 AM, Eric Friedrich (efriedri) < > efrie...@cisco.com> wrote: > >> > >> Will 2.0 still support MySQL or just Postgres? > >> > >> Will the 2.0 release include auto-migration from MySQL to

Re: regex_revalidate.config

ed this email. Seems like close to a second is quite slow. Is the > regex_revalidate.config per server? It seems like it was per CDN before. > > On Tue, Dec 13, 2016 at 1:02 PM, Jeremy Mitchell <mitchell...@gmail.com> > wrote: > > > Obviously, it is going to be slower to p

TC 2.0.x branch

As discussed in the traffic-control-cdn#dev slack channel, the plan is to merge the contents of the postgres branch ( https://github.com/apache/incubator-trafficcontrol/tree/postgres) to the master branch by Friday, 1/6/16 end of day and subsequently cut a 2.0.x branch. Included in 2.0.x will be

Re: cdn table and domain_name parameter?

I agree, it would be great to drop the profile column from the deliveryservice table (and add domain_name to cdn table). In my mind, a profile is really a "server profile" and intended for servers (caches). In addition, by allowing users to select a profile for a deliveryservice, we introduce the

regex_revalidate.config

I've created an issue to solicit some feedback regarding the removal of regex_revalidate.config from the file system. If you are not aware, regex_revalidate.config is the ATS config file used to "invalidate content". Storing regex_revalidate.config on the file system makes it harder to set up a

Re: Proposed change to Deliverservice API

Let's look at an example of using ID's versus names for POSTS (creates) Here is the region table. A region belongs to a division. mysql> desc region; +--+-+--+-+---+-+ | Field| Type| Null | Key | Default

Re: [jira] [Commented] (TC-28) API response structure should be hierarchical instead of flat

owse/TC-28 > > Project: Traffic Control > > Issue Type: Improvement > > Components: Traffic Ops API > >Affects Versions: 1.8.0 > >Reporter: Jeremy Mitchell > >Priority: Minor > >