-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!
traffic_ops/testing/api/vendor/golang.org/x/c
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 wrote:
>
>> The changelog exists to answer the question, "Who made things this way
>> and when?"
>>
>> I think we do need ch
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 t
back 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 wrote:
>> So, to continue the conversation, it looks like the list of backup
>> groups is stored as a List.
it's 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 wrote:
>
;: [{"name": "grp1", "order": 1},
{"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,
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 amongst the Apache Traffic Control PPMC, reviewing
Dan Kirkwood wrote:
> Chris,
>
> "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.
>
> -da
endpoint and ensure all
>>> entries in the deliveryservice_regex table are deleted for that delivery
>>> service.
>>>
>>> Does your PR include any of the following?
>>>
>>> - [ ] Tests
>>> - [ ] Documentation
>>> - [X]
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
I just
> wanted to provide 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 wrote:
>
>> If there's a rele
gt;> Thanks,
>> > >> Dave
>> > >>
>> > >> On Wed, Feb 7, 2018 at 4:04 PM, Rawlin Peters <
>> rawlin.pet...@gmail.com>
>> > >> wrote:
>> > >>
>> > >>> Hey all,
>> > >>>
>>
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. A PR template could also help
>> contributors ensure that their PRs are complete. I.e. does this PR includes
>> tests, do
-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 librar
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 U
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 tha
hem from here:
> https://github.com/asaskevich/govalidator#list-of-functions
>
> -Dew
>
> On Thu, Jan 11, 2018 at 9:24 AM, Chris Lemmons wrote:
>
>> I like the output style, but I'm a bit concerned on the performance
>> front. ozzo appears to do all it's magic wit
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 performa
[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
t;>
>> Is there a strong objection to keeping the NOTICE Attribution for them?
>>
>>
>> On Tue, Dec 19, 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 A
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 wrote:
> Excellent, Eric. That neatly cleans up the problem. I do think we
> should merge my PR
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
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 password file earlier tod
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 "medi
is topic?
On Mon, Aug 14, 2017 at 5:31 PM, Chris Lemmons 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 get it
ant 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:
>> >
>> > TC version 2.
As we continue the work of getting Traffic Control to work properly
with ATS 7 and forward, we're having to re-work some of the ways we
manipulate cache keys. The crux of the issue is that cacheurl was
deprecated in 6 and has been removed in 7. Cacheurl was replaced with
cachekey in 6. That unfortu
My 2¢.
Null and empty are different things and should be communicated
properly in the API. It's not the API's responsibility to optimize for
line-count of specific implementations. Dealing with possibly null
values is annoying in Go, but doable.
That said, it's worth thinking carefully about whet
C (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
u, Oct 19, 2017 at 4:01 PM, Jeremy Mitchell 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
>
27;s verbose and unnecessary, bug fixes
> don't make things incompatible and are unlikely to cause confusion.
> +1 on putting the patch in a header, e.g. `X-API-Version: 1.3.deadbeef`.
> Header makes it easy to debug, in the rare event it's necessary, without
> cluttering the UR
s 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. :)
>
>
>
>
>
> On Thu, Oct 19, 2017 at
Interesting idea. I think, though, it's better to keep API versions
separate from TC versions. Many versions of TC won't rev the API at
all. I'd prefer to go all in on Semantic Versioning.
I think it could work like this. For a given route, use the route
defined for the most recent version not lat
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 CONTRIBU
dylan_v...@comcast.com> wrote:
> 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" wrot
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 t
@dan, how do you feel about the middle-ground I proposed: a
reflection-based function that would look like this:
rows.Scan(FieldsOf(&server)...) ?
On Tue, Sep 12, 2017 at 9:05 PM, Dan Kirkwood wrote:
> As one ready to jump in and add more endpoints, I'm a strong +1 on
> using sqlx. I agree tha
nternet. Say what you will
> about Mojolicious but 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 wrote:
>
> > I'm also -1 on sqlx.
> >
> > That sai
I'm also -1 on sqlx.
That said, the "single line" in the `sql` version is 674 characters long. I
think we can agree that it's one heck of a line.
We're focusing on the Scan call vs. the ScanStruct call, which I think is
the right place to look. Here's what `sql` requires:
- One identifier per col
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
What if you did something like this?
Parameter name: "header"
Config file name: "test_file.config"
Value: "none"
And then, if you wanted to explicitly change it, you could use:
Parameter name: "header"
Config file name: "test_file.config"
Value: "default"
The default, ofc, would be "default", s
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 mailto:neum
> a...@apache.org>
The privacy settings on those appear to be configured such that I can't see
them. Can you double-check that they're public?
On Thu, Jun 15, 2017 at 9:31 AM, Durfey, Ryan
wrote:
> These should all be available to anyone in our project.
> Traffic Ops https://issues.apache.org/jira/secure/Dashboard
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 ran
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 ApaceCon, a few of us atte
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, too
+1
On Thu, May 18, 2017 at 2:57 PM Steve Malenfant
wrote:
> +1
>
f,
> maybe we are missing a backport?
> I will have to take a look at that as time allows.
>
> Dan, if the postinstall changes are too much to backport, we should look at
> documenting what needs to be done to get the software installed, that might
> be sufficient.
>
>
>
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
Error
+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 wil
nk 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
> >
> >
> > > O
t
> > > > > > starts with /api gets api gateway treatment, the rest passes
> on
> > > > > > thru...Here's a fancy picture to communicate what I
> envision...
> > > > > >
> > &
hanging 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
> wrote:
>
> > Responding to a few people:
> >
> > > Often times
een
> > service 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
ng full auth queries.
> I believe this should be the approach on the API Gateway roadmap
> Thanks
>
> On 9 May 2017 21:14, "Chris Lemmons" wrote:
>
> > I'll second the principle behind "start with security, optimize when
> > there's a probl
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 p
was 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 wrote:
> Yeah, there're unfortunately good reasons not to have any accounts with
> write permission in the GitHub repo. It can
nreasonable to shift a bit more logic into it.
Another possibility is to see if the infra folks would mind adding python
and docker-compose. I'm not sure adding python to the mix on those boxen is
a good idea, though, even if they're willing.
On Tue, Mar 14, 2017 at 6:03 PM Leif Hedstrom
d need a host, though.
On Tue, Mar 14, 2017 at 5:06 PM Leif Hedstrom wrote:
>
> > On Mar 13, 2017, at 8:44 AM, Chris Lemmons wrote:
> >
> > To me, the key features of CI are that a) it builds each branch
> > automatically, b) notifies affected parties when all is
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 sho
I'm +1 on the backport, though I think there are a few things we might want
to look at before we pull the PR (I commented on the PR). But from a
porting perspective, it's clean and straightforward. It makes it
significantly easier to build, and therefore contribute.
On Thu, Mar 2, 2017 at 4:30 PM
I had the same thought. Dan and I have been running RAT (
https://creadur.apache.org/rat/ ) and it runs clean against 1.8. However,
it gets tricked by things with incorrect apache headers. At one point, we
ran a "fix all" that added apache headers to our files. It was a little
aggressive and caught
62 matches
Mail list logo
