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

-1 :( Removing the x/crypto fixes the previous issue regarding both crypto inclusion and compatibility, but we also have to remove the references from the LICENSE file. Weasel says these are the problems: Error Extra-License!

Re: Traffic Ops Change log

ur change log needs to be more robust imo. Like you > said, what exactly changed on server with id=42? > > On Fri, Mar 23, 2018 at 9:08 AM, Chris Lemmons <alfic...@gmail.com> wrote: > >> The changelog exists to answer the question, "Who made things this way >>

Re: Traffic Ops Change log

The changelog exists to answer the question, "Who made things this way and when?" I think we do need changelog entries on everything change that changes things, but those comments aren't useful unless they tell us what changed and what the old and new values are. So, I'm not in favour of filling

Re: Backup Cache Group Selection API Format

fallback traffic between multiple cachegroups at a time rather than > falling back through them sequentially. > > - Rawlin > > On Mon, Mar 19, 2018 at 2:30 PM, Chris Lemmons <alfic...@gmail.com> wrote: >> So, to continue the conversation, it looks like the list of backup >

Re: Backup Cache Group Selection API Format

unlikely that you'd be able to update the order component to do anything other than "move to an end" without updating about half the rows in the db anyway. It just feels like we're asking more of the API user. On Mon, Mar 19, 2018 at 2:04 PM, Chris Lemmons <alfic...@gmail.com>

Backup Cache Group Selection API Format

ot;name": "grp3", "order: 2},// or 5 or some other positive integer ] }``` Rawlin Peters [9:36 AM] 2nd option would make it easier to extend in the future with weighting for instance, we could just add another key/value in that object Eric Friedrich [9:3

Re: [VOTE] Traffic Control graduation to TLP

The Traffic Control project has grown so much over the last year, it's incredible. +1 On Thu, Mar 1, 2018 at 9:33 AM, Gelinas, Derek wrote: > +1 > >> On Mar 1, 2018, at 10:41 AM, Dave Neuman wrote: >> >> Hey All, >> >> After a great discussion

Re: Github PR/Issues Format Templates

> "Perfect is the enemy of good".The point here is to make the PR > description good enough to work with, not perfect. I appreciate what > you're trying to get to, but from experience, it's not realistic. > > -dan > > On Wed, Feb 28, 2018 at 1:31 PM, Chris Lem

Re: Github PR/Issues Format Templates

> - [ ] Tests >>> - [ ] Documentation >>> - [X] CHANGELOG.md entry >>> >>> ^^ I wasn't trying to imply that those last things were required. I just >>> wanted to provide a checklist that might be helpful for the contributer >>> and >>> the merger. For

Re: Github PR/Issues Format Templates

with this.) - [X] This PR does *not* fix a serious security flaw. (Read more: www.apache.org/security ) - [X] Tests are complete. - [X] Docs are updated. (Docs are unchanged, but still correct. This PR brings actual behaviour in line with the docs.) On Wed, Feb 28, 2018 at 10:30 AM, Chris Lemmons <al

Re: Github PR/Issues Format Templates

ide a checklist that might be helpful for the contributer and > the merger. For example, I always for get to look for a CHANGELOG.md > entry... > > Jeremy > > > On Tue, Feb 27, 2018 at 9:47 PM, Chris Lemmons <alfic...@gmail.com> wrote: > >> If there's a releva

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

gt; If he doesn't have one started, I think you can go ahead and create >> one. >> > >> >> > >> Thanks, >> > >> Dave >> > >> >> > >> On Wed, Feb 7, 2018 at 4:04 PM, Rawlin Peters < >> rawlin.pet...@gmail.com> &g

Re: Github PR/Issues Format Templates

R includes >> tests, documentation, etc. >> >> I'll take a stab at a couple of templates and run them by the group. >> >> Jeremy >> >> On Wed, Jan 31, 2018 at 1:10 PM, Chris Lemmons <alfic...@gmail.com> wrote: >> >>> I'm +1 on Issue Template

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

-1 due to some licensing issues: - traffic_ops/testing/compare/vendor/github.com/kelseyhightower/envconfig is not identified as non-Apache licensed in the LICENSE file. - traffic_ops/testing/compare/vendor/github.com/x/net is not identified as non-Apache licensed in the LICENSE file. These

Re: Delivery Service Self-Service

Thoughts: This is a great analysis! On point 2, I'm in favour of simplifying it to a single name instead of a fancy regex, at least in the user-editable settings. Concerns: "Bad neighbour" behaviour is the trickiest issue. For example, right now, a user could, ignorantly or otherwise, create a

Re: Github PR/Issues Format Templates

I'm +1 on Issue Templates, for sure. I don't know that PR templates are quite as critical, but it might be nice to have a reminder in there about verifying that the changelog is updated if necessary and documentation for new features is present. If the PR Template overwrites the default comment

Re: Golang Proxy Validation Dependencies

just use them from here: > https://github.com/asaskevich/govalidator#list-of-functions > > -Dew > > On Thu, Jan 11, 2018 at 9:24 AM, Chris Lemmons <alfic...@gmail.com> wrote: > >> I like the output style, but I'm a bit concerned on the performance >> f

Re: Golang Proxy Validation Dependencies

I like the output style, but I'm a bit concerned on the performance front. ozzo appears to do all it's magic with heavy use of reflection, which is often a slow spot in go. Most places, it wouldn't matter much, but this will be called on every element of every API function, so a nod toward

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

[X] +1 to adding a changelog.MD file [] -1 to adding a changelog.MD file That said, I'm only in favour of it if we're fastidious about requiring changelog updates on every single PR. A PR should either provide a reasonable changelog entry, or, in the body of the PR, justify it's absence. A simple

Re: Remove file with invalid license

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-trafficcontrol/pull/1681 >>> > &

Re: Remove file with invalid license

https://github.com/danielmiessler/SecLists is now licensed MIT. Thanks, Eric, for talking to Daniel Miessler for us and getting this taken care of! On Mon, Dec 18, 2017 at 1:56 PM, Chris Lemmons <alfic...@gmail.com> wrote: > Excellent, Eric. That neatly cleans up the problem. I do

Re: License Verification with Weasel

e last year, that RAT didn't > catch, that Weasel would. IMO we should merge this ASAP, and get it into > the Build system, so we can break builds when PRs violate licenses. It will > save a great deal of time and headache. > > > > On Fri, Dec 8, 2017 at 8:10 PM, Chris Lemmons

Re: Remove file with invalid license

Excellent, Eric. That neatly cleans up the problem. I do think we should merge my PR (1677), regardless, if for no other reason than to honour the authors' attribution request. On Mon, Dec 18, 2017 at 1:47 PM, Eric Friedrich (efriedri) wrote: > I emailed the owner of the

Re: Remove file with invalid license

Hrm, automatically downloading a blacklist at install should probably be a non-starter. It's a security issue waiting to happen, I think. (Automatically downloading code is the same, and Rob is right, we should be moving away, not toward that.) The question really hinges on the definition of

Re: License Verification with Weasel

, 2017 at 5:31 PM, Chris Lemmons <alfic...@gmail.com> wrote: > A few months ago, we spent some time cleaning up our licenses for Apache. In > order to find the problem licenses, I wrote a semi-general–purpose tool for > validating the repo for Apache. I put in a PR in February to

Re: Traffic Control with ATS 7+

and if we ever want to implement >> any >> > type of self-service, we need to simplify TC rather than complicate it. >> > >> > Not sure how realistic this is but I'd like to see something like this: >> > >> > Examples: >> > >> >

Re: Traffic Ops API Semantic Versioning

TC (or soon > will be) and like other TC components, it's version should follow along. > > Just my 2 cents. I know others feel like this could simplify a lot of > things across components but I'll let them speak for themselves. > > Jeremy > > On Thu, Oct 19, 2017 at 5:03

Re: Traffic Ops API Semantic Versioning

om> wrote: > Actually, we haven't broken (on purpose) the API in a long time. Let's make > sure we're clear on what "breaking" changes are NOT. > > They are NOT: > > >- Adding new endpoints to the API >- Adding new attributes to the response of an existing end

Re: Traffic Ops API Semantic Versioning

t; postgres (TC 2.0) and strings became ints, for example, so the api should > really be 2.x anyhow imo. > > Anyhow, the real reason i like syncing the api version to the TC version is > for simplicity and we don't have to argue all day about api versions. :) > > > > &

Re: Apache Traffic Control Code of Conduct

I'm +1 on creating a CODE_OF_CONDUCT.md (or whatever the standard name for the file is) and putting in a link to Apache's CoC. I'm, as I mentioned, -1 on creating one unique to us or adopting a non-Apache CoC. Creating CODE_OF_CONDUCT.md (or appropriate) and adding it to the bottom of our

Re: Traffic Ops Rewrite Golang Dependency - sqlx

> Yes Select, or the SliceScan is one of the reasons I would use sqlx, I am > pulling out sets using IN and left outer joins to avoid the tight looping > issues in some endpoints in the perl. > > On 9/13/17, 8:42 AM, "Chris Lemmons" <alfic...@gmail.com> wrote: >

Re: Traffic Ops Rewrite Golang Dependency - sqlx

I see that there's a significant preference to not list the members of the struct in the Scan function. That works. I'm still not certain I understand why we'd prefer to bring in all of `sqlx` instead of writing a single, fairly simple function to return the columns for the scan. Are there plans

Re: Traffic Ops Rewrite Golang Dependency - sqlx

at least you could do some Googling to figure out how > to use it. > > +1 on sqlx > > jeremy > > On Tue, Sep 12, 2017 at 8:37 PM, Chris Lemmons <alfic...@gmail.com> wrote: > > > I'm also -1 on sqlx. > > > > That said, the "single line&

License Verification with Weasel

A few months ago, we spent some time cleaning up our licenses for Apache. In order to find the problem licenses, I wrote a semi-general–purpose tool for validating the repo for Apache. I put in a PR in February to get it running automatically in the CI, but the TC repo isn't really the place for a

Re: Component Naming Standards - Project Management

I concur, as long as the github switch is happening in the fairly near future. The team has consensus on the switch, but have we let Apache Infrastructure know? On Mon, Jun 12, 2017 at 7:55 AM, Gelinas, Derek wrote: > +1 > > On Jun 12, 2017, at 9:54 AM, Dave Neuman

Re: Traffic Ops - Reorganize the client directory

Ok, if we're going to bite the bullet and break all the traffic ops client imports, here's my vote: traffic_ops/clients/go-to/*.go traffic_ops/clients/py-to/*.py This is because the last part of the name of the end directory is, by convention, the name of the library in go. I'll skip the long

Re: Moving Traffic Control the "full" github

This vote has now been open for the requisite 72 hours with basically universal consensus in favour of the move. Dave, I believe your motion carries. :) On Wed, May 17, 2017 at 10:57 AM Hank Beatty wrote: > +1 > > On 05/17/2017 10:51 AM, Dave Neuman wrote: > > While at

Re: [VOTE] Move Traffic Control to full GitHub

Aye, and we can't call the vote until Sunday at the earliest, to give everyone time to contribute. We seem to be pretty +1 on the change, but it's important to give everyone a chance. Also, I think the +1s here are for Issues, PRs, and Tags in GitHub. I do believe we'll get access to the Wiki,

Re: [VOTE] Move Traffic Control to full GitHub

+1 On Thu, May 18, 2017 at 2:57 PM Steve Malenfant wrote: > +1 >

Re: 2.0 release?

> > > On Wed, May 17, 2017 at 12:03 PM, Chris Lemmons <alfic...@gmail.com> > wrote: > > > Dave, I haven't run RAT, but I did just run the custom license tool for > TC > > and this is what it says: > > > > Error

Re: 2.0 release?

Dave, I haven't run RAT, but I did just run the custom license tool for TC and this is what it says: ErrorUnknown-Text! traffic_monitor_golang/common/util/num.go ErrorUnknown-Text! traffic_monitor_golang/traffic_monitor/crconfig/data.go

Re: Moving Traffic Control the "full" github

+1. Potential contributors will be much more likely to find issues and submit fixes with just a GitHub interface and one set of credentials. I actually prefer Jira to GitHub Issues, but I significantly prefer a single tool, and GitHub issues will work fine. Plus, the ability to tag PRs and such

Re: API GW route configuration

certainly validate, but I don’t think it is sufficient in > all > > cases. An endpoint in the underlying “API Namespace” might need to > perform > > an additional token auth. We should make sure to allow that option (but > not > > make it mandatory) > > > > —Eric &

Re: API GW route configuration

t; > > > > To me, the simplest approach is to key off request URL. > > anything that > > > > > > starts with /api gets api gateway treatment, the rest passes > on > > > > > > thru...Here's a fancy picture t

Re: API GW route configuration

nging the token signing key. maybe this is a good idea or > maybe this is a terrible idea. I have no idea. just a thought.. > > jeremy > > On Wed, May 10, 2017 at 12:23 PM, Chris Lemmons <alfic...@gmail.com> > wrote: > > > Responding to a few people: > > &g

Re: API GW route configuration

ice endpoints. I’d hate to see us have to reimplement these functions > > later. > > > > - I’d also like to see us give some consideration to how an API gateway > is > > deployed. We raised the bar for new users by unbundling Traffic Ops from > > the database and it coul

Re: API GW route configuration

OS) than doing full auth queries. > I believe this should be the approach on the API Gateway roadmap > Thanks > > On 9 May 2017 21:14, "Chris Lemmons" <alfic...@gmail.com> wrote: > > > I'll second the principle behind "start with security, optimize when > &

Re: API GW route configuration

I'll second the principle behind "start with security, optimize when there's a problem". It seems to me that in order to maintain security, basically everyone would need to dial the revalidate time so close to zero that it does very little good as a cache on the credentials. Otherwise, as Rob as

Re: Public CI Builds for Traffic Control

s able to use the build script to successfully build all components from master yesterday. -- Thanks, Jeff On Tue, Mar 14, 2017 at 8:27 PM, Chris Lemmons <alfic...@gmail.com> wrote: > Yeah, there're unfortunately good reasons not to have any accounts with > write permission in the GitHub

Re: Public CI Builds for Traffic Control

n Tue, Mar 14, 2017 at 5:06 PM Leif Hedstrom <zw...@apache.org> wrote: > > > On Mar 13, 2017, at 8:44 AM, Chris Lemmons <alfic...@gmail.com> wrote: > > > > To me, the key features of CI are that a) it builds each branch > > automatically, b) notifies affected

Re: Public CI Builds for Traffic Control

To me, the key features of CI are that a) it builds each branch automatically, b) notifies affected parties when all is not well, and c) manages the artefacts in a reasonable way. Additionally, we're a lot more useful when we're writing neat software and not spending out time managing CI, so it