You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Jeremy Mitchell <mi...@apache.org> on 2017/03/15 19:30:16 UTC
Removing 'internal' from TO API
Currently, we have a number of API routes scoped as "internal". Here are a
few examples:
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
I believe this is going to make it more difficult as we try to implement
more granular roles / capabilities coupled with tenancy.
So I'm proposing that we create a duplicate non-internal route like this,
for example:
$r->get("/api/$version/steering")->over( authenticated => 1 )->to(
'Steering#index', namespace => 'API::DeliveryService' );
that way we can slowly move away from the "internal" routes and eventually
deprecate them.
I think with our upcoming more robust role / tenancy model, there is no
longer a need for "internal".
Thoughts?
Jeremy
Re: Removing 'internal' from TO API
Posted by Amir Yeshurun <am...@qwilt.com>.
I believe this use case should be solved with rewrite rules.
You don't always have the privileged to be able to mess with the service
API (consider a 3rd party service, e.g. Graphana)
The API layer is responsible to translate any customer facing route to the
backend location of the endpoint.
I would consider an API layer with 2 reverse proxies. The front end is an
industry standard GW (nginx, varnish, HAProxy) that is able to do such
translations.
The backend is our "disputable" API GW that handles authentication and
dispatch (forward) the request th the service
On Thu, May 11, 2017 at 5:33 PM Jeremy Mitchell <mi...@gmail.com>
wrote:
> I'm not 100% familiar with how the API gateway will work but I always
> assumed that it was a microservice that handled everything /api/*. For
> example, if you made a request to traffic-ops.domain.com/foo.jpg, the api
> gateway would not kick in....but if you made a request to
> traffic-ops.domain.com/api/whatever, the api gateway would kick in and do
> it's thing (check roles, capabilities, token, etc).
>
> If that is true, it seems like we need to get these "internal" routes under
> the api namespace.
>
> We have 8 "internal" routes:
>
> 4 authenticated (you have to be logged in) steering routes that are locked
> down by role (admin or steering):
>
> $r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to(
> 'Steering#index', namespace => 'API::DeliveryService' );
> $r->get("/internal/api/$version/steering/:xml_id")->over( authenticated =>
> 1 )->to( 'Steering#index', namespace => 'API::DeliveryService' );
> $r->post("/internal/api/$version/steering")->over( authenticated => 1
> )->to( 'Steering#add', namespace => 'API::DeliveryService' );
> $r->put("/internal/api/$version/steering/:xml_id")->over( authenticated =>
> 1 )->to( 'Steering#update', namespace => 'API::DeliveryService' );
>
> 1 authenticated federation route locked down by role (admin):
>
> $r->get("/internal/api/$version/federations")->over( authenticated => 1
> )->to( 'Federation#index', namespace => $namespace );
>
> ^^ imo those are all authenticated and locked down by role so there should
> be no harm losing the "internal". (as long as any place is the code base
> that uses these routes are adjusted)
>
> 1 unauthenticated (you don't have to be logged in) dnsseckeys route:
>
> $r->get("/internal/api/$version/cdns/dnsseckeys/refresh")->to(
> 'Cdn#dnssec_keys_refresh', namespace => $namespace );
>
> 2 unauthenticated traffic stats routes:
>
> $r->get("internal/api/$version/daily_summary")->to(
> 'CacheStats#daily_summary', namespace => $namespace );
> $r->get("internal/api/$version/current_stats")->to(
> 'CacheStats#current_stats', namespace => $namespace );
>
> At the very least, the first 5 routes should be "fixed" imo. Not sure what
> to do about the other 3.
>
> Jeremy
>
>
>
>
> On Fri, Mar 17, 2017 at 5:40 AM, Amir Yeshurun <am...@qwilt.com> wrote:
>
> > With the API GW, such duplications, or modifications can be defined in
> the
> > GW, if required, instead of in TO
> >
> > On Thu, Mar 16, 2017, 5:52 PM Jan van Doorn <jv...@knutsel.com> wrote:
> >
> > > We should also think about the API gateway future.... I think with
> that,
> > we
> > > don't need these special routes at all anymore, right Amir?
> > >
> > > Cheers,
> > > JvD
> > >
> > >
> > > On Wed, Mar 15, 2017 at 9:24 PM Dewayne Richardson <de...@gmail.com>
> > > wrote:
> > >
> > > > I think we should do as Dave mentioned, assess and rename.
> > > >
> > > > > On Mar 15, 2017, at 2:18 PM, Jeremy Mitchell <
> mitchell852@gmail.com>
> > > > wrote:
> > > > >
> > > > > I don't like duplicating routes either but I thought it would ease
> > the
> > > > > transition rather than just changing the route. So no code
> > duplication,
> > > > > just 2 routes that go to the same place:
> > > > >
> > > > > $r->get("/internal/api/$version/steering")->over( authenticated =>
> 1
> > > > )->to(
> > > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > > > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > > >
> > > > > And then we circle back and delete
> > > > >
> > > > > $r->get("/internal/api/$version/steering")->over( authenticated =>
> 1
> > > > )->to(
> > > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > > >
> > > > > at some point.
> > > > >
> > > > > And yes, this internal namespace was introduced for
> comcast-specific
> > > > > reasons that I believe no longer exist.
> > > > >
> > > > > Jeremy
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Mar 15, 2017 at 2:13 PM, David Neuman
> > > > > wrote:
> > > > >
> > > > > > At least a few of those (Steering, federations) were put in the
> > > > "internal"
> > > > > > namespace to work around Comcast specific issues. I don't know
> > that I
> > > > like
> > > > > > the idea of duplicating routes, if anything we should see what is
> > > > impacted
> > > > > > by moving them out of the internal namespace.
> > > > > >
> > > > > > On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell
> > > > > > wrote:
> > > > > >
> > > > > > > Currently, we have a number of API routes scoped as "internal".
> > > Here
> > > > are
> > > > > > a
> > > > > > > few examples:
> > > > > > >
> > > > > > > https://github.com/apache/incubator-trafficcontrol/blob/
> > > > > > > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
> > > > > > >
> > > > > > > I believe this is going to make it more difficult as we try to
> > > > implement
> > > > > > > more granular roles / capabilities coupled with tenancy.
> > > > > > >
> > > > > > > So I'm proposing that we create a duplicate non-internal route
> > like
> > > > this,
> > > > > > > for example:
> > > > > > >
> > > > > > > $r->get("/api/$version/steering")->over( authenticated => 1
> > )->to(
> > > > > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > > > > >
> > > > > > > that way we can slowly move away from the "internal" routes and
> > > > > > eventually
> > > > > > > deprecate them.
> > > > > > >
> > > > > > > I think with our upcoming more robust role / tenancy model,
> there
> > > is
> > > > no
> > > > > > > longer a need for "internal".
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > > Jeremy
> > > > > > >
> > > > > >
> > >
> >
>
Re: Removing 'internal' from TO API
Posted by Jeremy Mitchell <mi...@gmail.com>.
I'm not 100% familiar with how the API gateway will work but I always
assumed that it was a microservice that handled everything /api/*. For
example, if you made a request to traffic-ops.domain.com/foo.jpg, the api
gateway would not kick in....but if you made a request to
traffic-ops.domain.com/api/whatever, the api gateway would kick in and do
it's thing (check roles, capabilities, token, etc).
If that is true, it seems like we need to get these "internal" routes under
the api namespace.
We have 8 "internal" routes:
4 authenticated (you have to be logged in) steering routes that are locked
down by role (admin or steering):
$r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to(
'Steering#index', namespace => 'API::DeliveryService' );
$r->get("/internal/api/$version/steering/:xml_id")->over( authenticated =>
1 )->to( 'Steering#index', namespace => 'API::DeliveryService' );
$r->post("/internal/api/$version/steering")->over( authenticated => 1
)->to( 'Steering#add', namespace => 'API::DeliveryService' );
$r->put("/internal/api/$version/steering/:xml_id")->over( authenticated =>
1 )->to( 'Steering#update', namespace => 'API::DeliveryService' );
1 authenticated federation route locked down by role (admin):
$r->get("/internal/api/$version/federations")->over( authenticated => 1
)->to( 'Federation#index', namespace => $namespace );
^^ imo those are all authenticated and locked down by role so there should
be no harm losing the "internal". (as long as any place is the code base
that uses these routes are adjusted)
1 unauthenticated (you don't have to be logged in) dnsseckeys route:
$r->get("/internal/api/$version/cdns/dnsseckeys/refresh")->to(
'Cdn#dnssec_keys_refresh', namespace => $namespace );
2 unauthenticated traffic stats routes:
$r->get("internal/api/$version/daily_summary")->to(
'CacheStats#daily_summary', namespace => $namespace );
$r->get("internal/api/$version/current_stats")->to(
'CacheStats#current_stats', namespace => $namespace );
At the very least, the first 5 routes should be "fixed" imo. Not sure what
to do about the other 3.
Jeremy
On Fri, Mar 17, 2017 at 5:40 AM, Amir Yeshurun <am...@qwilt.com> wrote:
> With the API GW, such duplications, or modifications can be defined in the
> GW, if required, instead of in TO
>
> On Thu, Mar 16, 2017, 5:52 PM Jan van Doorn <jv...@knutsel.com> wrote:
>
> > We should also think about the API gateway future.... I think with that,
> we
> > don't need these special routes at all anymore, right Amir?
> >
> > Cheers,
> > JvD
> >
> >
> > On Wed, Mar 15, 2017 at 9:24 PM Dewayne Richardson <de...@gmail.com>
> > wrote:
> >
> > > I think we should do as Dave mentioned, assess and rename.
> > >
> > > > On Mar 15, 2017, at 2:18 PM, Jeremy Mitchell <mi...@gmail.com>
> > > wrote:
> > > >
> > > > I don't like duplicating routes either but I thought it would ease
> the
> > > > transition rather than just changing the route. So no code
> duplication,
> > > > just 2 routes that go to the same place:
> > > >
> > > > $r->get("/internal/api/$version/steering")->over( authenticated => 1
> > > )->to(
> > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > >
> > > > And then we circle back and delete
> > > >
> > > > $r->get("/internal/api/$version/steering")->over( authenticated => 1
> > > )->to(
> > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > >
> > > > at some point.
> > > >
> > > > And yes, this internal namespace was introduced for comcast-specific
> > > > reasons that I believe no longer exist.
> > > >
> > > > Jeremy
> > > >
> > > >
> > > >
> > > > On Wed, Mar 15, 2017 at 2:13 PM, David Neuman
> > > > wrote:
> > > >
> > > > > At least a few of those (Steering, federations) were put in the
> > > "internal"
> > > > > namespace to work around Comcast specific issues. I don't know
> that I
> > > like
> > > > > the idea of duplicating routes, if anything we should see what is
> > > impacted
> > > > > by moving them out of the internal namespace.
> > > > >
> > > > > On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell
> > > > > wrote:
> > > > >
> > > > > > Currently, we have a number of API routes scoped as "internal".
> > Here
> > > are
> > > > > a
> > > > > > few examples:
> > > > > >
> > > > > > https://github.com/apache/incubator-trafficcontrol/blob/
> > > > > > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
> > > > > >
> > > > > > I believe this is going to make it more difficult as we try to
> > > implement
> > > > > > more granular roles / capabilities coupled with tenancy.
> > > > > >
> > > > > > So I'm proposing that we create a duplicate non-internal route
> like
> > > this,
> > > > > > for example:
> > > > > >
> > > > > > $r->get("/api/$version/steering")->over( authenticated => 1
> )->to(
> > > > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > > > >
> > > > > > that way we can slowly move away from the "internal" routes and
> > > > > eventually
> > > > > > deprecate them.
> > > > > >
> > > > > > I think with our upcoming more robust role / tenancy model, there
> > is
> > > no
> > > > > > longer a need for "internal".
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > > > Jeremy
> > > > > >
> > > > >
> >
>
Re: Removing 'internal' from TO API
Posted by Amir Yeshurun <am...@qwilt.com>.
With the API GW, such duplications, or modifications can be defined in the
GW, if required, instead of in TO
On Thu, Mar 16, 2017, 5:52 PM Jan van Doorn <jv...@knutsel.com> wrote:
> We should also think about the API gateway future.... I think with that, we
> don't need these special routes at all anymore, right Amir?
>
> Cheers,
> JvD
>
>
> On Wed, Mar 15, 2017 at 9:24 PM Dewayne Richardson <de...@gmail.com>
> wrote:
>
> > I think we should do as Dave mentioned, assess and rename.
> >
> > > On Mar 15, 2017, at 2:18 PM, Jeremy Mitchell <mi...@gmail.com>
> > wrote:
> > >
> > > I don't like duplicating routes either but I thought it would ease the
> > > transition rather than just changing the route. So no code duplication,
> > > just 2 routes that go to the same place:
> > >
> > > $r->get("/internal/api/$version/steering")->over( authenticated => 1
> > )->to(
> > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > > 'Steering#index', namespace => 'API::DeliveryService' );
> > >
> > > And then we circle back and delete
> > >
> > > $r->get("/internal/api/$version/steering")->over( authenticated => 1
> > )->to(
> > > 'Steering#index', namespace => 'API::DeliveryService' );
> > >
> > > at some point.
> > >
> > > And yes, this internal namespace was introduced for comcast-specific
> > > reasons that I believe no longer exist.
> > >
> > > Jeremy
> > >
> > >
> > >
> > > On Wed, Mar 15, 2017 at 2:13 PM, David Neuman
> > > wrote:
> > >
> > > > At least a few of those (Steering, federations) were put in the
> > "internal"
> > > > namespace to work around Comcast specific issues. I don't know that I
> > like
> > > > the idea of duplicating routes, if anything we should see what is
> > impacted
> > > > by moving them out of the internal namespace.
> > > >
> > > > On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell
> > > > wrote:
> > > >
> > > > > Currently, we have a number of API routes scoped as "internal".
> Here
> > are
> > > > a
> > > > > few examples:
> > > > >
> > > > > https://github.com/apache/incubator-trafficcontrol/blob/
> > > > > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
> > > > >
> > > > > I believe this is going to make it more difficult as we try to
> > implement
> > > > > more granular roles / capabilities coupled with tenancy.
> > > > >
> > > > > So I'm proposing that we create a duplicate non-internal route like
> > this,
> > > > > for example:
> > > > >
> > > > > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > > >
> > > > > that way we can slowly move away from the "internal" routes and
> > > > eventually
> > > > > deprecate them.
> > > > >
> > > > > I think with our upcoming more robust role / tenancy model, there
> is
> > no
> > > > > longer a need for "internal".
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > Jeremy
> > > > >
> > > >
>
Re: Removing 'internal' from TO API
Posted by Jan van Doorn <jv...@knutsel.com>.
We should also think about the API gateway future.... I think with that, we
don't need these special routes at all anymore, right Amir?
Cheers,
JvD
On Wed, Mar 15, 2017 at 9:24 PM Dewayne Richardson <de...@gmail.com>
wrote:
> I think we should do as Dave mentioned, assess and rename.
>
> > On Mar 15, 2017, at 2:18 PM, Jeremy Mitchell <mi...@gmail.com>
> wrote:
> >
> > I don't like duplicating routes either but I thought it would ease the
> > transition rather than just changing the route. So no code duplication,
> > just 2 routes that go to the same place:
> >
> > $r->get("/internal/api/$version/steering")->over( authenticated => 1
> )->to(
> > 'Steering#index', namespace => 'API::DeliveryService' );
> > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > 'Steering#index', namespace => 'API::DeliveryService' );
> >
> > And then we circle back and delete
> >
> > $r->get("/internal/api/$version/steering")->over( authenticated => 1
> )->to(
> > 'Steering#index', namespace => 'API::DeliveryService' );
> >
> > at some point.
> >
> > And yes, this internal namespace was introduced for comcast-specific
> > reasons that I believe no longer exist.
> >
> > Jeremy
> >
> >
> >
> > On Wed, Mar 15, 2017 at 2:13 PM, David Neuman
> > wrote:
> >
> > > At least a few of those (Steering, federations) were put in the
> "internal"
> > > namespace to work around Comcast specific issues. I don't know that I
> like
> > > the idea of duplicating routes, if anything we should see what is
> impacted
> > > by moving them out of the internal namespace.
> > >
> > > On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell
> > > wrote:
> > >
> > > > Currently, we have a number of API routes scoped as "internal". Here
> are
> > > a
> > > > few examples:
> > > >
> > > > https://github.com/apache/incubator-trafficcontrol/blob/
> > > > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
> > > >
> > > > I believe this is going to make it more difficult as we try to
> implement
> > > > more granular roles / capabilities coupled with tenancy.
> > > >
> > > > So I'm proposing that we create a duplicate non-internal route like
> this,
> > > > for example:
> > > >
> > > > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > > > 'Steering#index', namespace => 'API::DeliveryService' );
> > > >
> > > > that way we can slowly move away from the "internal" routes and
> > > eventually
> > > > deprecate them.
> > > >
> > > > I think with our upcoming more robust role / tenancy model, there is
> no
> > > > longer a need for "internal".
> > > >
> > > > Thoughts?
> > > >
> > > > Jeremy
> > > >
> > >
Re: Removing 'internal' from TO API
Posted by Dewayne Richardson <de...@gmail.com>.
I think we should do as Dave mentioned, assess and rename.
> On Mar 15, 2017, at 2:18 PM, Jeremy Mitchell <mi...@gmail.com> wrote:
>
> I don't like duplicating routes either but I thought it would ease the
> transition rather than just changing the route. So no code duplication,
> just 2 routes that go to the same place:
>
> $r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to(
> 'Steering#index', namespace => 'API::DeliveryService' );
> $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> 'Steering#index', namespace => 'API::DeliveryService' );
>
> And then we circle back and delete
>
> $r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to(
> 'Steering#index', namespace => 'API::DeliveryService' );
>
> at some point.
>
> And yes, this internal namespace was introduced for comcast-specific
> reasons that I believe no longer exist.
>
> Jeremy
>
>
>
> On Wed, Mar 15, 2017 at 2:13 PM, David Neuman
> wrote:
>
> > At least a few of those (Steering, federations) were put in the "internal"
> > namespace to work around Comcast specific issues. I don't know that I like
> > the idea of duplicating routes, if anything we should see what is impacted
> > by moving them out of the internal namespace.
> >
> > On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell
> > wrote:
> >
> > > Currently, we have a number of API routes scoped as "internal". Here are
> > a
> > > few examples:
> > >
> > > https://github.com/apache/incubator-trafficcontrol/blob/
> > > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
> > >
> > > I believe this is going to make it more difficult as we try to implement
> > > more granular roles / capabilities coupled with tenancy.
> > >
> > > So I'm proposing that we create a duplicate non-internal route like this,
> > > for example:
> > >
> > > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > > 'Steering#index', namespace => 'API::DeliveryService' );
> > >
> > > that way we can slowly move away from the "internal" routes and
> > eventually
> > > deprecate them.
> > >
> > > I think with our upcoming more robust role / tenancy model, there is no
> > > longer a need for "internal".
> > >
> > > Thoughts?
> > >
> > > Jeremy
> > >
> >
Re: Removing 'internal' from TO API
Posted by Jeremy Mitchell <mi...@gmail.com>.
I don't like duplicating routes either but I thought it would ease the
transition rather than just changing the route. So no code duplication,
just 2 routes that go to the same place:
$r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to(
'Steering#index', namespace => 'API::DeliveryService' );
$r->get("/api/$version/steering")->over( authenticated => 1 )->to(
'Steering#index', namespace => 'API::DeliveryService' );
And then we circle back and delete
$r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to(
'Steering#index', namespace => 'API::DeliveryService' );
at some point.
And yes, this internal namespace was introduced for comcast-specific
reasons that I believe no longer exist.
Jeremy
On Wed, Mar 15, 2017 at 2:13 PM, David Neuman <da...@gmail.com>
wrote:
> At least a few of those (Steering, federations) were put in the "internal"
> namespace to work around Comcast specific issues. I don't know that I like
> the idea of duplicating routes, if anything we should see what is impacted
> by moving them out of the internal namespace.
>
> On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell <mi...@apache.org>
> wrote:
>
> > Currently, we have a number of API routes scoped as "internal". Here are
> a
> > few examples:
> >
> > https://github.com/apache/incubator-trafficcontrol/blob/
> > master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
> >
> > I believe this is going to make it more difficult as we try to implement
> > more granular roles / capabilities coupled with tenancy.
> >
> > So I'm proposing that we create a duplicate non-internal route like this,
> > for example:
> >
> > $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> > 'Steering#index', namespace => 'API::DeliveryService' );
> >
> > that way we can slowly move away from the "internal" routes and
> eventually
> > deprecate them.
> >
> > I think with our upcoming more robust role / tenancy model, there is no
> > longer a need for "internal".
> >
> > Thoughts?
> >
> > Jeremy
> >
>
Re: Removing 'internal' from TO API
Posted by David Neuman <da...@gmail.com>.
At least a few of those (Steering, federations) were put in the "internal"
namespace to work around Comcast specific issues. I don't know that I like
the idea of duplicating routes, if anything we should see what is impacted
by moving them out of the internal namespace.
On Wed, Mar 15, 2017 at 1:30 PM, Jeremy Mitchell <mi...@apache.org>
wrote:
> Currently, we have a number of API routes scoped as "internal". Here are a
> few examples:
>
> https://github.com/apache/incubator-trafficcontrol/blob/
> master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L516
>
> I believe this is going to make it more difficult as we try to implement
> more granular roles / capabilities coupled with tenancy.
>
> So I'm proposing that we create a duplicate non-internal route like this,
> for example:
>
> $r->get("/api/$version/steering")->over( authenticated => 1 )->to(
> 'Steering#index', namespace => 'API::DeliveryService' );
>
> that way we can slowly move away from the "internal" routes and eventually
> deprecate them.
>
> I think with our upcoming more robust role / tenancy model, there is no
> longer a need for "internal".
>
> Thoughts?
>
> Jeremy
>