> 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 <[email protected]> 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 <[email protected]> wrote: > > > I love this. +1 > > > > On Wed, Oct 9, 2019 at 12:46 PM Robert Butts <[email protected]> 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? > > > > > >
