You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by Robert Butts <ro...@apache.org> on 2019/10/09 16:46:42 UTC
Feature Proposal: Server Capabilities
Hi all! We have a proposal for a new feature for TC: Server Capabilities.
Blueprint is here: https://github.com/apache/trafficcontrol/pull/3972
In a nutshell, the problem we're solving is that it's impossible to only
use certain Mids for certain Delivery Services. You can manually assign
whatever Edges you want, but all Edge get all Mids in their parent
Cachegroup.
With "Server Capabilities," Servers will have any number of "Capabilities,"
and Delivery Services will have "Required Capabilities," and when
parenting, if a Mid doesn't have a Required Capability, it will not be
inserted as a parent for that DS.
Example 1: You have Mids with only Ram, and you have Delivery Services
serving small images, and DSes serving large binaries. This feature lets
you assign the Capability "DISK" to your other servers that have disk, and
the Required Capability "DISK" to the large binary DSes, and then the
Ram-only Mids won't have those DSes sent to them (which would destroy the
cache) because they don't have the "DISK" Server Capability.
Example 2: You have some ATS servers with the Lua plugin installed, and
some without. You have some DSes that require a Lua script, which executes
on Mids as well as Edges. You can then assign a Server Capability and DS
Required Capability "LUA," to not route Lua DSes through servers without
the Lua plugin.
We have a very specific use case we need this for, and it fundamentally
lets you do parentage/routing in ATC that isn't possible today. But we're
hoping it's generic enough to solve a lot of similar problems in the future.
Some notes:
- The feature is 100% backwards-compatible. When you upgrade, no DSes have
"Required Capabilities," so routing continues how it always did, until some
Server Capabilities are created.
- The feature is entirely optional. If you don't need Server Capabilities
in your CDN, just don't create them, and everything works how it always did.
- The feature also applies to Edge assignments, but since that's all
manual, that's really just an extra/safety, it doesn't make any new things
possible.
Thoughts?
Re: Feature Proposal: Server Capabilities
Posted by Robert Butts <ro...@apache.org>.
> dealing with API versions is so much of a hassle now that we're writing
new endpoints rather than deal with how hard it could be to add a field to
an existing endpoint.
It's not that much of a hassle. We could put it in existing endpoints. It
just gives us more flexibility this way.
You don't do versioning because it's easy. You do it to not break users.
On Wed, Oct 9, 2019 at 4:06 PM ocket 8888 <oc...@gmail.com> wrote:
> +1 seems like a good idea
>
> I hate to bring up something with so much potential for derailing an email
> thread, but I just wanna point out that dealing with API versions is so
> much of a hassle now that we're writing new endpoints rather than deal with
> how hard it could be to add a field to an existing endpoint.
>
> Down with versioned API
>
> .----.-----.-----.-----.
> / \ \ \ \
> | \/ | | __L_____L__
> | | | | ( \
> | \___/ / \______/ |
> | \___/\___/\___/ |
> \ \ / /
> | __/
> \_ __/
> | | |
> | |
> | |
>
>
> On Wed, Oct 9, 2019 at 2:38 PM Derek Gelinas <mr...@gmail.com> wrote:
>
> > I love this. +1
> >
> > On Wed, Oct 9, 2019 at 12:46 PM Robert Butts <ro...@apache.org> wrote:
> >
> > > Hi all! We have a proposal for a new feature for TC: Server
> Capabilities.
> > >
> > > Blueprint is here: https://github.com/apache/trafficcontrol/pull/3972
> > >
> > > In a nutshell, the problem we're solving is that it's impossible to
> only
> > > use certain Mids for certain Delivery Services. You can manually assign
> > > whatever Edges you want, but all Edge get all Mids in their parent
> > > Cachegroup.
> > >
> > > With "Server Capabilities," Servers will have any number of
> > "Capabilities,"
> > > and Delivery Services will have "Required Capabilities," and when
> > > parenting, if a Mid doesn't have a Required Capability, it will not be
> > > inserted as a parent for that DS.
> > >
> > > Example 1: You have Mids with only Ram, and you have Delivery Services
> > > serving small images, and DSes serving large binaries. This feature
> lets
> > > you assign the Capability "DISK" to your other servers that have disk,
> > and
> > > the Required Capability "DISK" to the large binary DSes, and then the
> > > Ram-only Mids won't have those DSes sent to them (which would destroy
> the
> > > cache) because they don't have the "DISK" Server Capability.
> > >
> > > Example 2: You have some ATS servers with the Lua plugin installed, and
> > > some without. You have some DSes that require a Lua script, which
> > executes
> > > on Mids as well as Edges. You can then assign a Server Capability and
> DS
> > > Required Capability "LUA," to not route Lua DSes through servers
> without
> > > the Lua plugin.
> > >
> > > We have a very specific use case we need this for, and it fundamentally
> > > lets you do parentage/routing in ATC that isn't possible today. But
> we're
> > > hoping it's generic enough to solve a lot of similar problems in the
> > > future.
> > >
> > > Some notes:
> > > - The feature is 100% backwards-compatible. When you upgrade, no DSes
> > have
> > > "Required Capabilities," so routing continues how it always did, until
> > some
> > > Server Capabilities are created.
> > > - The feature is entirely optional. If you don't need Server
> Capabilities
> > > in your CDN, just don't create them, and everything works how it always
> > > did.
> > > - The feature also applies to Edge assignments, but since that's all
> > > manual, that's really just an extra/safety, it doesn't make any new
> > things
> > > possible.
> > >
> > > Thoughts?
> > >
> >
>
Re: Feature Proposal: Server Capabilities
Posted by ocket 8888 <oc...@gmail.com>.
+1 seems like a good idea
I hate to bring up something with so much potential for derailing an email
thread, but I just wanna point out that dealing with API versions is so
much of a hassle now that we're writing new endpoints rather than deal with
how hard it could be to add a field to an existing endpoint.
Down with versioned API
.----.-----.-----.-----.
/ \ \ \ \
| \/ | | __L_____L__
| | | | ( \
| \___/ / \______/ |
| \___/\___/\___/ |
\ \ / /
| __/
\_ __/
| | |
| |
| |
On Wed, Oct 9, 2019 at 2:38 PM Derek Gelinas <mr...@gmail.com> wrote:
> I love this. +1
>
> On Wed, Oct 9, 2019 at 12:46 PM Robert Butts <ro...@apache.org> wrote:
>
> > Hi all! We have a proposal for a new feature for TC: Server Capabilities.
> >
> > Blueprint is here: https://github.com/apache/trafficcontrol/pull/3972
> >
> > In a nutshell, the problem we're solving is that it's impossible to only
> > use certain Mids for certain Delivery Services. You can manually assign
> > whatever Edges you want, but all Edge get all Mids in their parent
> > Cachegroup.
> >
> > With "Server Capabilities," Servers will have any number of
> "Capabilities,"
> > and Delivery Services will have "Required Capabilities," and when
> > parenting, if a Mid doesn't have a Required Capability, it will not be
> > inserted as a parent for that DS.
> >
> > Example 1: You have Mids with only Ram, and you have Delivery Services
> > serving small images, and DSes serving large binaries. This feature lets
> > you assign the Capability "DISK" to your other servers that have disk,
> and
> > the Required Capability "DISK" to the large binary DSes, and then the
> > Ram-only Mids won't have those DSes sent to them (which would destroy the
> > cache) because they don't have the "DISK" Server Capability.
> >
> > Example 2: You have some ATS servers with the Lua plugin installed, and
> > some without. You have some DSes that require a Lua script, which
> executes
> > on Mids as well as Edges. You can then assign a Server Capability and DS
> > Required Capability "LUA," to not route Lua DSes through servers without
> > the Lua plugin.
> >
> > We have a very specific use case we need this for, and it fundamentally
> > lets you do parentage/routing in ATC that isn't possible today. But we're
> > hoping it's generic enough to solve a lot of similar problems in the
> > future.
> >
> > Some notes:
> > - The feature is 100% backwards-compatible. When you upgrade, no DSes
> have
> > "Required Capabilities," so routing continues how it always did, until
> some
> > Server Capabilities are created.
> > - The feature is entirely optional. If you don't need Server Capabilities
> > in your CDN, just don't create them, and everything works how it always
> > did.
> > - The feature also applies to Edge assignments, but since that's all
> > manual, that's really just an extra/safety, it doesn't make any new
> things
> > possible.
> >
> > Thoughts?
> >
>
Re: Feature Proposal: Server Capabilities
Posted by Derek Gelinas <mr...@gmail.com>.
I love this. +1
On Wed, Oct 9, 2019 at 12:46 PM Robert Butts <ro...@apache.org> wrote:
> Hi all! We have a proposal for a new feature for TC: Server Capabilities.
>
> Blueprint is here: https://github.com/apache/trafficcontrol/pull/3972
>
> In a nutshell, the problem we're solving is that it's impossible to only
> use certain Mids for certain Delivery Services. You can manually assign
> whatever Edges you want, but all Edge get all Mids in their parent
> Cachegroup.
>
> With "Server Capabilities," Servers will have any number of "Capabilities,"
> and Delivery Services will have "Required Capabilities," and when
> parenting, if a Mid doesn't have a Required Capability, it will not be
> inserted as a parent for that DS.
>
> Example 1: You have Mids with only Ram, and you have Delivery Services
> serving small images, and DSes serving large binaries. This feature lets
> you assign the Capability "DISK" to your other servers that have disk, and
> the Required Capability "DISK" to the large binary DSes, and then the
> Ram-only Mids won't have those DSes sent to them (which would destroy the
> cache) because they don't have the "DISK" Server Capability.
>
> Example 2: You have some ATS servers with the Lua plugin installed, and
> some without. You have some DSes that require a Lua script, which executes
> on Mids as well as Edges. You can then assign a Server Capability and DS
> Required Capability "LUA," to not route Lua DSes through servers without
> the Lua plugin.
>
> We have a very specific use case we need this for, and it fundamentally
> lets you do parentage/routing in ATC that isn't possible today. But we're
> hoping it's generic enough to solve a lot of similar problems in the
> future.
>
> Some notes:
> - The feature is 100% backwards-compatible. When you upgrade, no DSes have
> "Required Capabilities," so routing continues how it always did, until some
> Server Capabilities are created.
> - The feature is entirely optional. If you don't need Server Capabilities
> in your CDN, just don't create them, and everything works how it always
> did.
> - The feature also applies to Edge assignments, but since that's all
> manual, that's really just an extra/safety, it doesn't make any new things
> possible.
>
> Thoughts?
>