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

gnature, but the email still mentions md5 and sha1 checksums -- only > sha512 checksum and pgp signature are there. I think the correct files are > provided and the email is incorrect. > > -dan > > On Fri, May 11, 2018 at 12:22 PM Robert Butts wrote: > > > Hello All, >

[VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC6

Hello All, I've prepared a release for v2.2.0-RC6 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 release [ ] -1 Do not release this package because ... Changes since 2.1.0: https://github.com/apache/incubator-trafficcont

Self Service Change Integrity (Snapshot-Queue) Plan

At the summit, I presented a plan for automated change integrity (the "snapshot-queue" problem). The technical spec is on the wiki at: https://cwiki.apache.org/confluence/display/TC/Traffic+Control++Self+Service+Proposal+for+Change+Integrity Solving the "snapshot-queue" problem is just one of man

[VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC5

Hello All, I've prepared a release for v2.2.0-RC5 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 release [ ] -1 Do not release this package because ... Changes since 2.1.0: https://github.com/apache/incubator-trafficcont

Re: Traffic Ops go client responses

ame after 2.2.0-RC1, and assuming > that's true, do we really have an obligation to follow the deprecation > process for unreleased code? > > I might be wrong about the age of some of those files, but I know at > least a handful of them were added after 2.2.0-RC1 for sure. > >

Re: Traffic Ops go client responses

>client methods take the Foo struct as input rather than the FooNullable struct, so it's impossible to create a request with null fields It's a legacy artifact. You're right, it's a serious limitation, it's just never been a priority to fix. The client is a public interface to the API, we can't j

Re: Traffic Server Secondary Streaming IPs Design

@weifensh We're hoping to have most of the API endpoints, not including ATS config files, in the next month or so. I'm currently working on `deliveryservices`, and @dylanvoltz is on `servers`, the two biggest, and they're both mostly done. They should be code-complete by the end of next week, and t

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

the following: > - building with the pkg command > - signatures > - checksums (were we supposed to get rid of md5? I must have missed that) > - installed and started traffic_stats > > > On Wed, Apr 4, 2018 at 11:04 AM, Robert Butts wrote: > > > Hello All, > > >

Re: Updated TO API guidelines

h params. > > > > > > Technically, adding new routes does not break old stuff right so i > don't > > > think that warrants a major version roll. > > > > > > While we're on the subject, what does everyone think if we took this > one > >

Re: Updated TO API guidelines

ill conform to SemVer for the same major version, e.g. 1.3. On Wed, Apr 4, 2018 at 4:12 PM, Robert Butts wrote: > You're right, in our code today, we don't use raw major versions > (/api/1/foo) in our API, and our clients have hard-coded minor versions. > > If we feel lik

Re: Updated TO API guidelines

have this route at all and > would require > new dev work to support, or maybe I am misunderstanding you? > > On 4/4/18, 3:49 PM, "Robert Butts" wrote: > > >Technically, adding new routes does not break old stuff right so i > don't > think that

Re: Updated TO API guidelines

foos to update > DELETE /foos <-- takes in an array of foos to delete > > in this scenario, query params only pertain to the GET. The POST, PUT and > DELETE rely on the contents of the request json... > > Jeremy > > > > > > > > > > > > On We

Re: Updated TO API guidelines

That document doesn't mention versions, 1.2 vs 1.3 vs 2.0. Just to clarify, changing to 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 w

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

Hello All, I've prepared a release for v2.2.0-RC4 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 release [ ] -1 Do not release this package because ... Changes since 2.1.0: https://github.com/apache/incubator-trafficcont

Re: Traffic Server Secondary Streaming IPs Design

@nbaoping > So I suggest the change to the current TM to be like: > 1) Separate the current polling of cache servers into two different pollings, one for the keep alive, the other for the stat query. The Golang Monitor already does this. We call it the "health" and "stat" polls in the code. The s

[VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC3

Hello All, I've prepared a release for v2.2.0-RC3 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 release [ ] -1 Do not release this package because ... Changes since 2.1.0: https://github.com/apache/incubator-trafficcont

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

Ah, sorry, I'd removed them form dist/dev but not dist/release. They have been removed from https://dist.apache.org/repos/dist/release/incubator/ trafficcontrol/2.0.0-incubating/ now. On Fri, Mar 23, 2018 at 7:18 AM, sebb wrote: > On 22 March 2018 at 17:36, Robert Butts wrote: > &

Re: TM: Question about the poll model of the Traffic Monitor

ind this question probably deserves a longer dev@ email. > > > > I will oversimplify: we are extending TC to support multiple IPv4 (or > > multiple IPv6) addresses per edge cache (across 1 or more NICs). > > > > Assume all addresses are reachable from the TM. > > >

Re: TM: Question about the poll model of the Traffic Monitor

When you say different interfaces, do you mean IPv4 versus IPv6? Or something else? If you mean IPv4 vs IPv6, we have a PR for that from Dylan Volz https://github.com/apache/incubator-trafficcontrol/pull/1627 I'm hoping to get to it early next week, just haven't found the time to review and test

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

Ah, thanks for the clarification. Ok, the 2.0.0 RPMs have been removed from dist, and the webpage links updated to archive.apache.org. On Mon, Mar 19, 2018 at 5:48 PM, sebb wrote: > On 19 March 2018 at 19:01, Robert Butts wrote: > > MD5s have been removed. > > > > Henk,

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

7;s no separate branch for version 2 development, just master. Is that ok? Or do we still need to move 2.0.0? On Mon, Mar 19, 2018 at 11:57 AM, Henk P. Penning wrote: > On Mon, 19 Mar 2018, Robert Butts wrote: > > Date: Mon, 19 Mar 2018 18:34:22 +0100 >> From: Robert Butts >&

[VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC2

Hello Incubator PMC, The Apache Traffic Control community has voted on and approved a proposal to release Apache Traffic Control 2.2-incubating. We now kindly request that the Incubator PMC members review and vote on this incubator release. The VOTE RESULT is here: https://lists.apache.org/threa

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

0.6ea850) CentOS 6 > > - Upgraded Traffic Ops ORT > > - mid cache "report" and "badass" mode seem to work correctly > > - edge cache "report" and "badass" mode seem to work correctly > > - Tested DNS DS and works correctly > &g

[VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC2

Hello All, I've prepared a release for v2.2.0-RC2 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 release [ ] -1 Do not release this package because ... Changes since 2.1.0: https://github.com/apache/incubator-trafficcont

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

-1 on "DS requests" long-term, post real Self Service, because there's no need, it's unnecessary complexity. More complexity means more code to maintain, more bugs. More complexity to maintain in the database. It's also more UI complexity, which means more tenants have to learn, more to get wrong,

[VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC1

Hello All, I've prepared a release for v2.2.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 release [ ] -1 Do not release this package because ... Changes since 2.1.0: https://github.com/apache/incubator-trafficcont

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

> > >> > >> On Tue, Feb 13, 2018 at 3:25 PM, Jeff Elsloo wrote: > >> > -1 due to the following PR breaking the Traffic Router build: > >> > https://github.com/apache/incubator-trafficcontrol/pull/1720 > >> > > >> > I'm looking in

[VOTE] Release Apache Traffic Control (incubating) 2.2.0-RC0

Hello All, I've prepared a release for v2.2.0-RC0 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 release [ ] -1 Do not release this package because ... Changes since 2.1.0: https://github.com/apache/incubator-trafficcont

TC 2.2 Release - Outstanding Issues - Update

Just a reminder, the 2.2 Release is scheduled for next Monday, February 12 Open Pull Requests: 1769 Monitor Stats Format Plugin For Delivery Service Names 1768 Add Traffic Monitor Plugin System for Cache Stats Formats 1844 DeepCachingType -- "NEVER" is now default 1825 updated docs to add some mis

TC 2.2 Release - Outstanding Issues

There are no `major` bugs without milestones, now. Many issues without milestones were moved from 2.1 to 2.2, and I moved them to 2.3 indiscriminately. We should verify they're ok to not be in 2.2. Traffic Ops -- 1026 [TC-191] Steering DS API should use standard response codes as defined in API g

Re: Starting the 2.2 Branch for Next Release of TC

on when it makes the most sense to cut the release branch. > Otherwise we might be stuck doing a bunch of back porting of fixes in the > next month or so. > > —Eric > > > On Jan 24, 2018, at 3:47 PM, Robert Butts wrote: > > Hi, > > I'm your friendly neighbou

Starting the 2.2 Branch for Next Release of TC

this from happening? Are there any features that can be wrapped up and go into this version? Any other comments or suggestions? Thanks, Robert Butts

Re: Two different Delivery Services using the same host regexp: A suggested Traffic Monitor code change

https://github.com/apache/incubator-trafficcontrol/pull/1768 https://github.com/apache/incubator-trafficcontrol/pull/1769 @oren Do those solve your use case? On Sun, Jan 7, 2018 at 1:36 AM, Oren Shemesh wrote: > Thank you Robert :-) > > On Thu, Jan 4, 2018 at 5:49 PM, Robert Butts

Re: Two different Delivery Services using the same host regexp: A suggested Traffic Monitor code change

. > So yes, given that the host in the stat is the origin, a single word is a > valid domain, hence it is not possible to auto-detect it. > > I believe that adding a parameter to the server profile is the way to do > this. > > Thanks ! > > Oren. > > On Tue, Jan 2, 20

Re: Two different Delivery Services using the same host regexp: A suggested Traffic Monitor code change

Erm, @neuman beat me to it. On Tue, Jan 2, 2018 at 9:42 AM, Robert Butts wrote: > >can you send a pointer to any documentation/text available regarding > 'Stats over HTTP' ? > > https://docs.trafficserver.apache.org/en/latest/admin-guide/ > plugins/stats_over_http

Re: Two different Delivery Services using the same host regexp: A suggested Traffic Monitor code change

t;System" stats Traffic Control needs. Which we're looking into doing, rather than maintaining a completely separate fork. But, as above, it may be difficult to extend either to have the DS Name. Hopefully I'm wrong. On Tue, Jan 2, 2018 at 9:35 AM, Robert Butts wrote: > >I wou

Re: Two different Delivery Services using the same host regexp: A suggested Traffic Monitor code change

an is to move towards the Stats Over HTTP plugin in the > > future, so we should focus on making Traffic Monitor do what we need it > to > > do now, and add new functionality to Stats over HTTP if it doesn't > > currently exist. I do think it would be nice to have Traffic Mo

Re: Two different Delivery Services using the same host regexp: A suggested Traffic Monitor code change

I'd be +1 if we extend Astats/stats_over_http to have the DS name. It's easy to extend the Monitor to get the name from a field, if it's available. And it should be faster than the current method. But, Astats doesn't currently support it, and in fact, I don't believe ATS has a good way to associat

Re: Remove file with invalid license

2017 at 9:32 AM, Dave Neuman wrote: > I merged it, you need to do a backport to 2.1 as well. > > On Tue, Dec 19, 2017 at 9:16 AM, Robert Butts > wrote: > > > PR updating the license: > > https://github.com/apache/incubator-trafficcontrol/pull/1681 > > > >

Re: Remove file with invalid license

ist to make your case or at least get an understanding of their > >>> requirements. The ASF does tend to lean toward conservative > interpretations. > >>> > >>> Thanks. > >>> > >>> On Mon, Dec 18, 2017 at 12:08 PM Robert Butts < >

Re: License Verification with Weasel

+1 This is immensely valuable, thanks for putting all this work in to fix our Trafficcontrol license pains! Sorry about the slow response, looks like this is a classic case of Lazy Consensus. >a particular emphasis on whether vendoring is a suitable solution for executables instead of libraries.

Re: Remove file with invalid license

it possible it's provided by an rpm we could > > list as a dependency rather than including in our source? > > > > -dan > > > > On Mon, Dec 18, 2017 at 11:11 AM, Robert Butts <mailto:robert.o.bu...@gmail.com>> wrote: > > I'd really like to keep

Re: Remove file with invalid license

I'd really like to keep this, or replace it with a similar file from another source. Which I'd be willing to investigate, if necessary. Having a good blacklist of most-common passwords specifically puts Traffic Ops in compliance with NIST SP 800-63B. I also don't understand the objections, the Ap

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

g label follow this link: > > > > > > https://github.com/apache/incubator-trafficcontrol/ > > > pulls?q=is%3Apr+is%3Aclosed+label%3A%22change+log%22+milestone%3A2.2.0 > > > > > > -Dew > > > > > > On Thu, Dec 14, 2017 at 10:48 AM, Gelinas, Derek &

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

+1 on a "changelog" label. Seems like that would make it a lot easier for the person writing it up. Easier to skip things like code maintenance that have no interface effect. On Thu, Dec 14, 2017 at 10:14 AM, Dewayne Richardson wrote: > Another idea would be to include a new CHANGELOG label that

Re: Changing max_dns_answers default

+1 on 5. IMO we're overthinking this, 5 isn't unreasonably large, it isn't the end of the world if TCP gets triggered, and anyone it matters for will change the default value. On Tue, Dec 5, 2017 at 8:33 AM, Dave Neuman wrote: > Hey Dylan, > I think since we currently default to 0 (all) and we

Re: Traffic Ops go api and null data

#2 pushes the support burden to clients. We'll be requiring clients to check for null everywhere, which in Go requires 4 lines, quadrupling the code. Sometimes clients need to distinguish between null and empty, but when they don't, it's 1/4 the Go code to have non-pointers that won't crash your ap

Re: Delivery Service Properties

If the field only applies to some DS types, it should be in its own table. Then it can be NOT NULL in that table, ideally with a constraint requiring the DS to be a type it applies to. You wanted to reduce the columns in the `deliveryservice` table, right? Here's your chance :) On Wed, Nov 15, 201

Re: Traffic Ops API Semantic Versioning

nted APIs that you might > want > >> to > >> > explore. > >> > 2. it provides the ability to stay on the perl apis by specifying 1.2 > if > >> > that is what you want to do. maybe you are not much of a risk taker... > >> > 3. it does ac

Re: Traffic Ops API Semantic Versioning

I'm fully +1 on Semantic Versioning. We discussed it briefly on the list a long time ago, but we haven't really been doing it. That said, versioning requires a lot of code/work that simply doesn't exist today. That's the reason we haven't been doing it properly. The Go Traffic Ops has Semantic Ve

Re: Removing installation dependencies

Seconded. Definitely +1 if you can do that migration in SQL. I think it's possible, but not easy. CTEs/With should help. But I wouldn't be -1 on (2) if you decide (1) isn't feasible. On Thu, Sep 14, 2017 at 10:20 AM, Jan van Doorn wrote: > The go migration is my fault…. I couldn’t figure out how

Re: Traffic Ops Rewrite Golang Dependency - sqlx

I am a pretty big -1 on sqlx. Those PRs are extremely deceptive. Those lines are entirely unnecessary. I have created an example PR at https://github.com/apache/incu bator-trafficcontrol/pull/1165 The relevant commits are https://github.com/apache/incubator-trafficcontrol/pull/1165 /commits/6fc7

Re: [VOTE] Bugtracking in Github Issues

+1 > 1. Github * Has very little in the way of organizational options I view Github's simplicity as a plus. Jira has a steep learning curve, and is discouraging to potential new committers. Every separate tool we have (issues, wiki, docs) are more obstacles to new people. Github's built-ins a

Re: Adding support for per-DeliveryService routing names

+1 A new requirement is a breaking change, needs to be a new major version, or a default value that doesn't break existing usage. On Tue, Aug 15, 2017 at 8:40 AM, Dewayne Richardson wrote: > This is a tough one because the obvious ways of breaking an API are "URL > format changes", "Request or

Re: Delivery Service based config generation and Cache Manager

think we need to have a utility for removing older > entries if we are to go this route. > > On Jul 27, 2017, at 10:12 AM, Robert Butts mailto:robert.o.bu...@gmail.com>> wrote: > > Can I propose an adjustment? > > If we add a timestamp to every table, we can generate the J

Re: Delivery Service based config generation and Cache Manager

Can I propose an adjustment? If we add a timestamp to every table, we can generate the JSON on-the-fly. Then, the snapshot becomes a timestamp field, `snapshot_time`, and all the data `select` queries add `where timestamp <= snapshot_time limit 1`. Instead of updating rows, we only ever insert new

Re: Traffic Ops Golang Migration Proposal

time the extreme pain of Carton will disappear as well, as for >> "downloadwebdeps" will also disappear because of Jeremy's new TO UI v2. >> So, really it'll be a small postinstall wrapper that basically sets up the >> database (with a default admin user) and mi

Re: Traffic Ops Golang Migration Proposal

are required > to run the golang component no matter what. We might as well just > build that into the existing RPM build process for traffic_ops. > > Do we really need to ask the user for the port to move mojo to? > Obviously we can ask them to provide a port, but we could also just

Re: Traffic Ops Golang Migration Proposal

should be moving away from any manual run of any script > after an installation or upgrade, including postinstall, if that work > can be done within the RPM. > -- > Thanks, > Jeff > > > On Wed, Jul 19, 2017 at 9:08 AM, Robert Butts > wrote: > > It sounds like th

Re: Traffic Ops Golang Migration Proposal

2017 at 1:00 PM, Robert Butts wrote: > @dewrich It's not that putting both services in the same Service and RPM > is a good long-term solution; it's that it's easier to configure and > deploy. A separate RPM and service is another step to install, and another > step to

Re: Promote Golang Traffic Monitor to Default

+1 > it results in a race condition between the two, as the resulting RPMs have the same filename That used to happen, but it was fixed in 556ccf. But still, +1 on renaming and making the Golang TM the default. On Fri, Jul 14, 2017 at 11:00 AM, Jeff Elsloo wrote: > Hi all, > > We currently ha

Re: Traffic Ops Golang Migration Proposal

ilt in golang which effect GUI components, what does > this mean for the perl GUI? Will we continue updating the perl GUI to > interact with updated golang APIs? (until we cut over to Jeremy’s Angular > UI) > > —Eric > > > > > On Jul 13, 2017, at 12:39 PM, Eric Covener

Fwd: Traffic Ops Golang Migration Proposal

rl module dependency tangles is a win. __Jason On Thu, Jul 13, 2017 at 11:11 AM, Robert Butts wrote: I'd like to propose a plan for rewriting Traffic Ops in Golang. It's been a goal of Traffic Control for years now to rewrite the aging Perl Traffic Ops app. We've made nu

Re: Obsolete Traffic Ops API endpoint removal

This isn't obsolete, so much as a prototype. It was intended to be "better" than the CRConfig and replace it for TR. Much the same way `configs/monitoring.json` is the "next generation" endpoint for Traffic Monitor (and which is now used in the Golang TM). That said, as you say, it's incomplete an

Re: LDAP Access

derstanding 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 > > > it would alleviat

Re: LDAP Access

ecurity issue entirely. > > > > I also wonder if we shouldn't try to leverage transitioning our user > > management to Postgres. Postgres has many options for authentication > (as I > > mentioned at the Summit), which would allow for more flexibility at TO > > inst

Re: LDAP Access

> Is there an option to entirely block someone from even basic TO access despite authenticating with LDAP? Other than disabling LDAP? No. I wouldn't object to adding a config, but I don't know when I'd be able to find the time. The current version allows entire read-only access, so this PR isn't a

LDAP Access

We have a PR https://github.com/apache/incubator-trafficcontrol/pull/627 to change Traffic Ops to only allow LDAP users _not_ in the Traffic Ops database to view non-sensitive information, like graphs and total CDN bandwidth. To be clear, users will still be able to authenticate with LDAP, as long

Re: Moving Traffic Control the "full" github

+1 IMO Github issues, wiki, etc are much, much easier to use than Atlassian tools. On Wed, May 17, 2017 at 8:51 AM, Dave Neuman wrote: > While at ApaceCon, a few of us attended a talk about navigating the > incubator where we were informed that "full" Github is now available for > podlings. Th

Re: API GW route configuration

ce. On Tue, May 9, 2017 at 6:56 AM, Dewayne Richardson wrote: > 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

Re: API GW route configuration

d make things better than today, where we have the same problem > that > > if > > > > the TO mojo app is compromised, everything is compromised. > > > > > > > > If we always route to TO, we don't untangle the mess of being > dependent > >

Re: API GW route configuration

What are the advantages of these config files, over an existing reverse proxy, like Nginx or httpd? It's just as much work as configuring and deploying an existing product, but more code we have to write and maintain. I'm having trouble seeing the advantage. -1 on auth rules as a part of the proxy

Re: Goose installer script

not suffer from the same > issues. > > > > I suggest we sit down together at the Summit and decide where to go with > this.. > > > > -dan > > > > On Mon, May 1, 2017 at 10:37 AM, Robert Butts > wrote: > >> +1 on Vendoring. I don't see

Re: Goose installer script

+1 on Vendoring. I don't see a difference if it's 375,000 lines or 10,000,000 lines. What does it matter if it's 375k lines in someone else's repo or our own? It does matter from a security standpoint. It means we're now vulnerable if their repo is compromised. We shouldn't be pulling _anything_ fr

Re: Recent changes to ATS config file generation

> Edge and mid servers can use other reverse proxies as their connection to Traffic Ops. This is configured in the GLOBAL parameter profile using the parameter tm.rev_proxy_url. When this is set, the metadata for the server will show a toRevProxyUrl entry under the info section of the JSON > The

Re: Proposal for CDN definition file based configuration management

I'd propose: * Instead of storing the JSON as blob, use https://www.postgresql.org/doc s/9.2/static/datatype-json.html * Instead of version-then-file request, use a "latest" endpoint with `If-Modified-Since` (https://tools.ietf.org/html/rfc7232#section-3.3). We can also serve each version at endpoi

Re: 2.0 release?

ove the `ResumeSession` method all > together > > and eliminate the dependency? Otherwise we are deprecating something > that > > we never formally released. > > > > On Tue, Apr 4, 2017 at 2:30 PM, Robert Butts > > wrote: > > > >> Regarding `TC-119:

Re: 2.0 release?

Regarding `TC-119: traffic_ops/client dependency license issue`: It looks like the persistent cookie jar is only needed by Traffic Ops Client `ResumeSession(toURL string, insecure bool) (*Session, error)`. Nothing in Traffic Control uses `ResumeSession`, and I doubt anyone else is using it. Becaus

Re: TO API Versioning

+1 on Semantic Versioning. -1 on breaking the existing API again. There's no point versioning if we make breaking changes without changing the version. On Fri, Mar 31, 2017 at 2:42 PM, Amir Yeshurun wrote: > +1 for choosing a versioning philosophy > > On Mon, Mar 27, 2017 at 5:15 PM Dewayne Ri

Re: Github PR suggestion

Also -1 on requiring, +1 on recommending. I've worked in environments where every commit or PR required a case, and it sounds good, but in practice it often discourages things like code maintenance and fixing technical debt. > Maybe issue / mailing list discussion required for new features and opt

Traffic Monitor Roadmap

As some of you know, we've been rewriting Traffic Monitor in Go. The rewrite adds non-lockstep polling, as well as generally giving us more flexibility and making it easier to add other big features in the future. The rewrite is currently at https://github.com/apache/incubator-trafficcontrol/tree/m

Re: Server's sarameters - adding some logic

> I think that we should not attempt to invent a scripting language for this purpose. > > My guess is that Lua is a good candidate for the job. +1 on both counts. Though I'm not convinced we need a scripting language in parameters yet. > Separating into 2 profile

Re: Question regarding TC integration

Ok, I don't know how much you know, so, sorry if I'm telling you things you already know, but here goes. > currently trying to connect a non ATS cache to Traffic Control. So, Traffic Control involves configuring caches, polling those caches to determine if they're 'healthy', and routing requests

[GitHub] incubator-trafficcontrol pull request #21: Fix Traffic Monitor 2.0 to get co...

GitHub user robert-butts opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/21 Fix Traffic Monitor 2.0 to get config options from Traffic Ops health endpoint You can merge this pull request into a Git repository by running: $ git pull https

[GitHub] incubator-trafficcontrol pull request #10: Traffic Monitor 2.0 Improvements

GitHub user robert-butts opened a pull request: https://github.com/apache/incubator-trafficcontrol/pull/10 Traffic Monitor 2.0 Improvements Adds config for server read and write timeouts. Removes duplicate common API data. Fixes numerous Linter issues. You can