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

checksums and > signature, 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 <r...@apache.org>

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

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

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

Re: Traffic Ops go client responses

awlin > > On Thu, Apr 26, 2018 at 12:27 PM, Robert Butts <robert.o.bu...@gmail.com> > wrote: > >>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 leg

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

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

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

> +1 > I tested 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 <r...@apache.or

Re: Updated TO API guidelines

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 > > > step further and made routes

Re: Updated TO API guidelines

ll conform to SemVer for the same major version, e.g. 1.3. On Wed, Apr 4, 2018 at 4:12 PM, Robert Butts <robert.o.bu...@gmail.com> 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. > &

Re: Updated TO API guidelines

s 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" <robert.o.bu...@gmail.com> wrote: > > >Technically, adding new routes does not break old stuff right so i > don't >

Re: Updated TO API guidelines

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 Wed, Apr 4

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

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

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

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

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

rves 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. > > > > —Eric > > > &

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 <seb...@gmail.com> wrote: > On 19 March 2018 at 19:01, Robert Butts <robert.o.bu...@gmail.com> wrote: >

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

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

gt; - Upgraded Traffic Stats (2.2.0.d7e588 -> 2.2.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 > &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:

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

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

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

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

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

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

t;type". > 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

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

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 <robert.o.bu...@gmail.com> wrote: > >

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

t; astats/stats_over_http, and I am sure there are several other features > > would be nice to have as well, but I don't think we should be muddying > the > > waters with that right now. > > > > > > On Wed, Dec 27, 2017 at 12:24 PM, Robert Butts <robert.o.bu...@gmail.co

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

Re: Remove file with invalid license

AM, Dave Neuman <neu...@apache.org> 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 <robert.o.bu...@gmail.com> > wrote: > > > PR updating the license: > > https://github.com/apache/incubator-traff

Re: Remove file with invalid license

; forever. I encourage you to contribute to the thread on the legal > mailing > >>> list to make your case or at least get an understanding of their > >>> requirements. The ASF does tend to lean toward conservative > interpretations. > >>> >

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

but didn't find it > > with a quick search. Is 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 <robert.o.bu...@gmail.com > <mailto

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

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

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

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,

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

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

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

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

Re: Traffic Ops Golang Migration Proposal

over 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 minimal

Fwd: Traffic Ops Golang Migration Proposal

ving to a non-perl alternative. From an administrator's perspective, anything that helps me avoid perl module dependency tangles is a win. __Jason On Thu, Jul 13, 2017 at 11:11 AM, Robert Butts <robert.o.bu...@gmail.com> wrote: I'd like to propose a plan for rewriting Traffic Ops in Go

Re: LDAP Access

DAP? > 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 th

Re: LDAP Access

rity 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

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

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

Re: API GW route configuration

roxy > > > auth, > > > > and 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 un

Re: Goose installer script

uffer 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 <robert.o.bu...@gmail.com> > wrote: > >> +1 on Vendoring. I d

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_

Re: 2.0 release?

yet > > released, why don't we just remove 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 <robert.

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.

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

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

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