Re: TO jobs_* Table Cleanup

tables @Cox. We use the built-in content > invalidation. > > On Tue, May 1, 2018 at 6:05 PM, Hongfei Zhang (hongfezh) < > hongf...@cisco.com > > wrote: > > > @Dew - we did not touch job_result table. Thanks, -Hongfei > > > > On 5/1/18, 5:03 PM, "De

Re: TO jobs_* Table Cleanup

"Jan van Doorn" <j...@knutsel.com> wrote: > > I think they should be nuked. > > Rgds, > JvD > > > On May 1, 2018, at 2:04 PM, Dewayne Richardson <dewr...@apache.org> > wrote: > > > > I'm beginning to evaluat

TO jobs_* Table Cleanup

I'm beginning to evaluate the Perl cleanup effort and noticed that the *job_agent*, *job_status*, and *job_result* are minimally used (except for the "job" table which has the list of Purge Jobs"). I wanted to get a feel for the usage outside of Comcast and what the sentiment is to those tables

Re: Traffic Ops go client responses

I think at one point there was some effort to expose some of that with the "rawRequest" func, not sure who created a lot of these, I have just been using what was there for the API Tests. I think we do need to do some refactoring to expose more for proper API Testing.

Re: Traffic Server Secondary Streaming IPs Design

I agree with Rob, please explore the Go implementation, we're reaching critical mass (most of the critical foundational routes are complete) with the API endpoints written in Go with the big one /deliveryservices being the biggest and most important to complete. -Dew On Fri, Apr 20, 2018 at 8:37

Re: Updated TO API guidelines

Thank you John for giving us "API Use Cases" to think about with these new TO API Guidelines. The main goal for these changes are to build TO API's that are intuitive. I'm of the opinion that if the API's are intuitive (with easy to understand patterns) that prevents me from wasting time looking

Traffic Control Doc's Proposal

I've been going through the Traffic Ops API doc's and revamping them with Swagger and noticed this trend with our documentation. "Guides" (Howto's, Installs, Developer's) growing because they are easier to maintain (because they are less fancy) as markdown files in the Github project. My

General TC Cleanup

As we get more visibility as we become an Apache project, I've been taking a fresh eye at Github project so that we can tidy up a bit to present ourselves well. I highly recommend that each of you do as well so that we can get more eyeballs on the matter. One nit that I've noticed is the Github

Re: Traffic Ops Change log

IMO, I don't think it's necessary to pollute the Change Log with Delivery 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

Re: Backup Cache Group Selection

As another thought, maybe we should take advantage of https://postgis.net/ and figure out how to flip CZF into it. -Dew On Tue, Mar 13, 2018 at 10:05 AM, David Neuman wrote: > What happens when Geo Limit is set to "CZF Only" with all backup Caches > are unavailable

Re: Backup Cache Group Selection

Eric, I agree with this as well, maybe we build separate API's for "loading" CZF formats (or any other types of external data) into the same area of the data model (however that ultimately looks). If we keep the CZF data centralized it'll be easier to build relationships if needed. -Dew On

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

wrote: > >>> >> > >>> >>> > >>> >>> > >>> >>> > On Jan 9, 2018, at 10:22 AM, Dave Neuman <neu...@apache.org> > wrote: > >>> >>> > > >>> >>> > Looks like this thr

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

in the changelog. And > then > > > the > > > >>> RM > > > >>> >> can build the changelog from the milestones. Easy peasy. > > > >>> >> > > > >>> >> Jeremy > > > >>> >> > > >

Re: Traffic Ops API Swagger Doc

ly...tools (swagger) like > > >> consistency and our api is far from consistent... > > >> > > >> jeremy > > >> > > >> On Wed, Feb 14, 2018 at 10:08 AM, Durfey, Ryan < > ryan_dur...@comcast.com > > >

Re: Traffic Ops API Swagger Doc

Eric: Out of curiosity I was able to generate it with the tooling I mentioned here: https://github.com/dewrich/incubator-trafficcontrol/blob/swagger-demo/traffic_ops/traffic_ops_golang/docs/swagger.rst -Dew On Tue, Feb 20, 2018 at 10:38 AM, Dewayne Richardson <dewr...@gmail.com> wrote:

Re: Traffic Ops API Swagger Doc

have to rev the api version to > >> 2.0 to make the api more swagger friendly...tools (swagger) like > >> consistency and our api is far from consistent... > >> > >> jeremy > >> > >> On Wed, Feb 14, 2018 at 10:08 AM, Durfey, Ryan <ryan_dur..

Traffic Ops API Swagger Doc

We've been working diligently on the TO Golang Rewrite project to obviously rewrite the Perl into Go, but also to improve our Testing and Documentation efforts. I presented the idea of using Swagger several summits (years) ago about

Github PR/Issues Format Templates

I was working through the go-swagger repo and found a bug. I submitted a new issue and found this interesting approach I think the TC github should adopt, "Issue and PR Templates". I think the main value here is consistency in our PRs/Issues and user friendly prompts to say "these are the data

Re: Golang Proxy Validation Dependencies

POST/PUT which are a > >>> small minority of calls. It also need not be used in every case. > >>> That, to me, makes the reflection argument much less of a concern. > >>> > >>> I would like to see it g

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

Awesome, great work! On Fri, Jan 19, 2018 at 6:47 AM, Hank Beatty wrote: > Hello, > > It would appear RC3 has passed the IPMC vote. I'll do the release today. > > Regards, > Hank > > On 2018-01-17 17:01, Phil Sorber wrote: > > +1 (binding). After having

Re: Move Docs to readthedocs.io ?

+1for anything that will help us streamline doc, -Dew On Tue, Jan 2, 2018 at 12:23 PM, Jan van Doorn wrote: > I propose we move our docs to readthedocs - like : > http://incubator-trafficcontrol.readthedocs.io/en/latest/ (this is setup > w my clone). > > This will allow us to

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

gt; that > > have no interface effect. > > > > On Thu, Dec 14, 2017 at 10:14 AM, Dewayne Richardson <dewr...@gmail.com> > > wrote: > > > >> Another idea would be to include a new CHANGELOG label that you could > tack > >> onto specific P

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

Another idea would be to include 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 Github issues because to me those

Traffic OPS API Test Tool

I've been working on a PR to introduce a new Traffic Ops API tool based on the existing traffic_ops/client_tests area (if approved this area will be deprecated). The hope is to use this tool to build up more

Re: Traffic Ops Golang Unit Tests Pattern

Hi Kevin, Thanks for your question. I'm not sure we want to change the method signature that won't be used by the running Golang, but haven't said that I'd like to see an example of what you are describing. (Maybe a github gist?) -Dew On Tue, Nov 7, 2017 at 2:34 PM, Kevin Mackenzie

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

Nice work 72 hours on a Friday! On Fri, Nov 10, 2017 at 11:21 AM, Hank Beatty wrote: > Hello All, > > I've prepared a release for v2.1.0-RC1 > > The vote is open for at least 72 hours and passes if a majority of at > least 3 +1 PPMC votes are cast. > > [ ] +1 Approve the

TC Golang structs refactor

FYI: There's been an ongoing need to refactor the Golang structs to an area of the code base that affect Traffic Monitor, Traffic Stats, Traffic Ops Client, and the Golang Proxy. We've moved all common structs to this area https://github.com/apache/incubator-trafficcontrol/tree/master/lib/go-tc

Re: Traffic Ops Rewrite Golang Dependency - sqlx

The deadline of Friday 09-15 at noon has passed, sqlx as a TO Golang Dependency has been accepted. The vote tally is 6 Aye to 2 Nay's Have a good weekend, -Dew Results: Dan Kirkwood: +1 Derek Gelina: +1 Dewayne Richardson: +1 Dylan Volz: +1 Jan Van Doorn: +1 Jeremy Mitchell: +1 Chris Lemmons

Re: Traffic Ops Rewrite Golang Dependency - sqlx

ection and tag introspection so it isn’t the > > simplest go code but it does seem to be well commented. > > > > On 9/12/17, 6:36 PM, "Gelinas, Derek" <derek_geli...@comcast.com> wrote: > > > > After looking at the code, and given the work I've been d

Re: Traffic Ops Rewrite Golang Dependency - sqlx

an unknowable and potentially enormous > > > future cost. > > > > > > > > > On Tue, Sep 12, 2017 at 6:54 PM, Volz, Dylan (Contractor) < > > > dylan_v...@comcast.com> wrote: > > > > > >> It would be maintaining about a 1500 line codeba

Re: [VOTE] Bugtracking in Github Issues

+1 On Mon, Aug 28, 2017 at 10:44 AM, Dave Neuman wrote: > I thought we already had a vote on this? Maybe I am thinking of the "move > to github" vote which I assumed to be all-encompassing. > Anyway, +1 > > On Mon, Aug 28, 2017 at 10:43 AM, Dan Kirkwood

Re: Adding support for per-DeliveryService routing names

This is a tough one because the obvious ways of breaking an API are "URL format changes", "Request or Response format changes", etc. But I think the more obvious way to think about the API is, do the clients have to change their code? If the answer is yes, it's a breaking API change. So, really

Re: Traffic Ops Golang Rewrite

re+Proxy > > > > Ryan DurfeyM | 303-524-5099 > > CDN Support (24x7): 866-405-2993 or cdn_supp...@comcast.com > cdn_supp...@comcast.com> > > > > > > From: Dewayne Richardson <dewr...@gmail.com> > > Reply-To: "dev@trafficcontrol.incu

Re: Open Issues against 2.1

ld also go through the bugs without a version and either close them > or mark them into the 2.1 release > > —Eric > > > On Aug 9, 2017, at 11:59 AM, Dewayne Richardson <dewr...@gmail.com> > wrote: > > > > Technically only 20 (at the moment) Jeremy didn't filt

Re: Open Issues against 2.1

Technically only 20 (at the moment) Jeremy didn't filter out for Bugs only:

Re: Delivery Service based config generation and Cache Manager

When: Read · Fri, Jul 28. [image: Timyo expectation line] If Postgres performance becomes a concern, we can make ORT send it's "Update" to a different endpoint than the Read, we can also take advantage of Postgres HA to have

Re: Traffic Ops Golang Migration Proposal

When: Read · Wed, Jul 19. If Cc: read [image: Timyo expectation line] I had a knee jerk reaction to separate the RPMs because of the potential for a "new" approach, but I've now been convinced otherwise based upon the "Strangler

Re: 2.1 RM

When: Read · Mon, Jul 17. [image: Timyo expectation line] Yes, Hank thank you! On Mon, Jul 17, 2017 at 1:28 PM, Eric Friedrich (efriedri) < efrie...@cisco.com> wrote: > Hey Hank- > Many Thanks. Your RM baseball cap will be in the

Re: [VOTE] Release Apache Traffic Control 2.0.0-incubating (RC6)

+1 - gpg sig is good - checksums match source tarball - tarball has correct name and structure - rpms build from tarball using 'pkg' command - installed using those rpms and ran postinstall on a clean Centos7 VM - imported default profiles from here:

Re: Traffic Ops Default Profile Management

this to make the default look for ".json" (not a show stopper, but not a good experience). On Mon, Jun 12, 2017 at 12:33 PM, Dewayne Richardson <dewr...@gmail.com> wrote: > I actually had the thought of a new tab at the same level as Downloads > called "Profiles"

Re: Traffic Ops Default Profile Management

ll doc to reflect > that default profiles can be downloaded from the website; assuming Jan's PR > doesn't do this already. > I am +1 on having ATS in the EDGE and MID profile names to reflect that > they are for Traffic Server. > > > On Mon, Jun 12, 2017 at 12:00 PM, Dewayne Ric

Re: Traffic Ops Default Profile Management

we include an ORIGIN profile? > > > > Does TRAFFIC_PORTAL need a profile too? (I’ve never set it up) > > > > —Eric > > > > > On Jun 12, 2017, at 1:14 PM, Dewayne Richardson <dewr...@gmail.com> > > wrote: > > > > > > Based

Re: Traffic Ops Default Profile Management

i) < efrie...@cisco.com> wrote: > Can we include an ORIGIN profile? > > Does TRAFFIC_PORTAL need a profile too? (I’ve never set it up) > > —Eric > > > On Jun 12, 2017, at 1:14 PM, Dewayne Richardson <dewr...@gmail.com> > wrote: > > > > Based

Traffic Ops Default Profile Management

Based upon the discussion around how we manage the default profiles Traffic Ops profiles for 2.0 and 2.1, I propose we add instructions that under the TC Website documentation "Downloads" http://trafficcontrol.incubator.apache.org/downloads/index.html. The profiles will be in the format that

Re: Data patches during upgrade

Yea, it's just a new feature to admin.pl to support data conversions, to keep the migrations clean. Derek and I have been working through it. -Dew On Thu, Jun 8, 2017 at 7:40 AM, Jeremy Mitchell wrote: > This seems to make sense to me but honestly, I'd probably defer to

Re: LDAP Access

I have a question in a similar vein, how often do we really use LDAP? My understanding is we created LDAP access to allow external users in to see our TO Graphs. Now that graphs are in Graphana is the need for LDAP still needed? If we require anyone using TO or the TO API to be in the database

Re: TC Contributers to Publish list of Planned/WIP Items for Better Community Sync

+1 on tracking the Roadmap on Github, the "Labels" in github will make it easier to track than a wiki (and even JIRA) On Thu, May 25, 2017 at 12:39 PM, Shmulik Asafi wrote: > I think JIRA/Github are suitable candidates. > It will require to decide on some way to tag these

Re: 2.0 release?

s Rob! > > - Postinstall script is broken, Jeff and Dan are looking at it. > > > > Once post install is fixed, I will cut an RC > > > > —Eric > > > > > > > > > On Apr 6, 2017, at 2:35 PM, Dewayne Richardson <dewr...@gmail.com> > > wrote: &

Re: [VOTE] Move Traffic Control to full GitHub

Move to full github On Thu, May 18, 2017 at 2:32 PM Jan van Doorn wrote: > In > > https://lists.apache.org/thread.html/5bdb9b073343f49c1d5b85147eb9d260bf7ad15d61384929993c7e1d@%3Cdev.trafficcontrol.apache.org%3E > Dave > mentioned that we can now move to "full" GitHub. Some

Re: API GW route configuration

If only the API GW authenticates/authorizes we also have a single point of entry to test for security instead of having it sprinkled across services in different ways. It also simplifies the code on the service side and makes them easier to test with automation. -Dew On Mon, May 8, 2017 at 8:42

Re: Goose installer script

o.com> wrote: > > > Hey Dew- > > What calls this script? > > > > If its called from the Traffic Ops Spec file, then this will cause some > > pain for those of us that need to install without internet access. > > > > —Eric > > > > > On Ap

Re: Goose installer script

that need to install without internet access. > > —Eric > > > On Apr 28, 2017, at 12:41 PM, Dewayne Richardson <dewr...@gmail.com> > wrote: > > > > I'm working toward a more streamlined installation process for Traffic > Ops > > (internally) and publicly.

Goose installer script

I'm working toward a more streamlined installation process for Traffic Ops (internally) and publicly. Of course, the same hiccups that everyone else runs into I am as well. Installation of Golang (proper version) and installation of Goose. Goose has been the most challenging for several reasons.

Re: Proposal for CDN definition file based configuration management

+1 I was just about to formulate that response. The "dev" list is our discussion forum. On Tue, Apr 11, 2017 at 9:35 AM, Dave Neuman wrote: > @Ryan, I think its better to have conversations on the dev list than a wiki > page... > > On Tue, Apr 11, 2017 at 9:01 AM, Durfey,

Re: Traffic-Control Official PostgreSQL Version

We have started with 9.6.x, so I'd say we should assume > 9.6.x at the moment. On Tue, Apr 4, 2017 at 2:09 PM, Nir Sopher wrote: > Hi, > > Is there an official required PostgreSQL version? > > One reason it may be important is that supported syntax is added in newer > versions.

Re: TO API Versioning

Yes, the versioning wasn't consistent because we switched out the database to Postgres which had several impacts to the API. The issue with API routes being too granular in the versioning is tricky because the consumers of the API will need to change as the versions of Traffic Ops moves forward.

Re: Removing 'internal' from TO API

I think we should do as Dave mentioned, assess and rename. > On Mar 15, 2017, at 2:18 PM, Jeremy Mitchell wrote: > > I don't like duplicating routes either but I thought it would ease the > transition rather than just changing the route. So no code duplication, > just 2

Re: Proposed change to Deliverservice API

Right sorry, 3.0 On Wed, Nov 30, 2016 at 8:40 AM, Jan van Doorn <j...@knutsel.com> wrote: > > ... requirements on the list for 2.1. > > For 3.0, you mean? No API breaking changes on a minor rev, I thought? > > > > On Nov 30, 2016, at 08:35, Dewayne Richardson <de