; > An alternative implementation could be for the TrafficOps client
> to
> > > be
> > > > > able to specify the backend, on a per request basis (via HTTP
> header,
> > > > > params, or some other mechanism), instead of a whitelist in
> > > TrafficOp
> > > > able to specify the backend, on a per request basis (via HTTP header,
> > > > params, or some other mechanism), instead of a whitelist in
> > TrafficOps. In
> > > > this case, TrafficOps would still ultimately decide if a route could be
> >
> be
> > > > able to specify the backend, on a per request basis (via HTTP header,
> > > > params, or some other mechanism), instead of a whitelist in
> > TrafficOps. In
> > > > this case, TrafficOps would still ultimately decide if a route could
&g
ould easily
> > > compare behavior from multiple backends. For example, a test case in
> the
> > > traffic_ops/testing/api/v14 directory could use the same logic to test
> both
> > > the Perl and Go implementations.
> > > >
> > > > From: ocket
> >
mpare behavior from multiple backends. For example, a test case in the
> > traffic_ops/testing/api/v14 directory could use the same logic to test both
> > the Perl and Go implementations.
> > >
> > > From: ocket
> > > Reply-To: "dev@trafficcontrol.apache.org" >
14 directory could use the same logic to test both
> the Perl and Go implementations.
> >
> > From: ocket
> > Reply-To: "dev@trafficcontrol.apache.org" >
> > Date: Wednesday, November 20, 2019 at 15:25
> > To: "dev@trafficcontrol.apache.org"
>
0, 2019 at 15:25
> To: "dev@trafficcontrol.apache.org"
> Subject: Re: [EXTERNAL] TO API routing blacklist
>
> I think documenting all of those is going to be more work than using the
> actual paths. I'm also not a fan of numeric IDs in most cases because it
> mea
rated sequentially and we need to insert a route in the middle so
> > that
> > > a later rule that would match it doesn't override the route then
> suddenly
> > > everyone's configuration file is broken. Well, either that or we need
> to
Reply-To: "dev@trafficcontrol.apache.org"
Date: Wednesday, November 20, 2019 at 15:25
To: "dev@trafficcontrol.apache.org"
Subject: Re: [EXTERNAL] TO API routing blacklist
I think documenting all of those is going to be more work than using the
actual paths. I'm
> > a later rule that would match it doesn't override the route then
suddenly
> > everyone's configuration file is broken. Well, either that or we need to
> > statically maintain and document a magic number for every API route.
> >
> > Idk
it doesn't override the route then suddenly
> > > everyone's configuration file is broken. Well, either that or we need to
> > > statically maintain and document a magic number for every API route.
> > >
> > > Idk if this helps at all, but as has been point
y maintain and document a magic number for every API route.
> >
> > Idk if this helps at all, but as has been pointed out before the routes
> > don't actually need to be regular expressions.
> >
> > On Wed, Nov 20, 2019 at 2:55 PM Rawlin Peters wrote:
> >
>
n file is broken. Well, either that or we need to
> statically maintain and document a magic number for every API route.
>
> Idk if this helps at all, but as has been pointed out before the routes
> don't actually need to be regular expressions.
>
> On Wed, Nov 20, 2019
19 at 2:55 PM Rawlin Peters wrote:
> Hey folks,
>
> I'm currently working on this TO API routing blacklist feature, and
> while I've identified which routes should be on the whitelist of
> "routes that have been rewritten to Go but that are still safe to fall
>
Hey folks,
I'm currently working on this TO API routing blacklist feature, and
while I've identified which routes should be on the whitelist of
"routes that have been rewritten to Go but that are still safe to fall
back to Perl for", the tediousness of copying route regular
whoops, my previous reply was to the wrong email thread (meant for the
Release Process thread instead). I'll re-reply to the correct thread
:)
- Rawlin
On Mon, Nov 4, 2019 at 2:40 PM Rawlin Peters wrote:
>
> > I'm +1 on this final summary. It infers that we are going to soon be adding
> > a job
> I'm +1 on this final summary. It infers that we are going to soon be adding a
> job that runs CI checks on Master. This is good. That's probably a subject
> for another thread. I do have one question about this approach. I think there
> is probably a scenario where we need to fix an issue on t
I largely don't care about the blacklisted routes for this purpose. I really
care about a conclusive list of whitelisted routes (for which the example json
payload could be expanded to carry). It seems like we're solving the exact
same issue from two directions. It permits each native client
; > > The available routes and what associated backend they go to are
> > operator+
> > > > sensitive information. I'd also lean towards a stronger degree of
> > safety
> > > > and only make it read-only.
> > > >
> > > > Jonathan G
> Not trying to sideswipe, but could we expose that as an endpoint with a
> Golang list as well to solve:
> https://github.com/apache/trafficcontrol/issues/2872
While I do agree with the request for an API endpoint that tells the
client what API versions are supported, I wouldn't want to
overcom
e routes and what associated backend they go to are
> operator+
> > > sensitive information. I'd also lean towards a stronger degree of
> safety
> > > and only make it read-only.
> > >
> > > Jonathan G
> > >
> > > On 11/1/19, 8:41 AM,
information. I'd also lean towards a stronger degree of safety
> > and only make it read-only.
> >
> > Jonathan G
> >
> > On 11/1/19, 8:41 AM, "Hoppal, Michael"
> > wrote:
> >
> > I would be +1 on TO API routing blacklist.
> >
> On 11/1/19, 8:41 AM, "Hoppal, Michael"
> wrote:
>
> I would be +1 on TO API routing blacklist.
>
> I think it is a great idea to allow us to continue to move fast while
> minimizing risk.
>
> I do agree we should expose the current state of the
The available routes and what associated backend they go to are operator+
sensitive information. I'd also lean towards a stronger degree of safety and
only make it read-only.
Jonathan G
On 11/1/19, 8:41 AM, "Hoppal, Michael" wrote:
I would be +1 on TO API routing bl
I would be +1 on TO API routing blacklist.
I think it is a great idea to allow us to continue to move fast while
minimizing risk.
I do agree we should expose the current state of the blacklist as an API
endpoint as to easily get insight into the current configuration. We could even
make the
Not trying to sideswipe, but could we expose that as an endpoint with a Golang
list as well to solve: https://github.com/apache/trafficcontrol/issues/2872
Jonathan G
On 10/31/19, 3:51 PM, "Rawlin Peters" wrote:
Hey all,
We've been picking up momentum in the TO Perl -> Go rewrite rece
Hey all,
We've been picking up momentum in the TO Perl -> Go rewrite recently,
which has gotten me thinking of ways to reduce the risk of possible
regressions in the rewritten APIs. I'd like to propose that we
implement a sort of "routing blacklist" for the TO API routes.
At a high level, this bl
27 matches
Mail list logo
