[GitHub] [trafficcontrol] rob05c commented on a change in pull request #3972: Add Server Capabilities blueprint
rob05c commented on a change in pull request #3972: Add Server Capabilities blueprint URL: https://github.com/apache/trafficcontrol/pull/3972#discussion_r333616321 ## File path: blueprints/server-capabilitites.md ## @@ -0,0 +1,162 @@ + +# Server Capabilities + +## Problem Description + +Suppose a Traffic Control operator has servers of a particular type. For example, servers with only Memory and no Disk cache. It's possible today to only route to those Edges, via manual Delivery Service Server assignments. But suppose you have a Mid server with only Memory and no Disk. Then suppose you have a certain class of traffic you need to route to this Mid, but not other traffic. For example, Delivery Services with small images; but not DSes with large binary files, which would destroy the cache. Right now, this isn't possible in Traffic Control. + +We propose a feature, called "Server Capabilitites" to solve this problem. Servers will have "capabilitites" and Delivery Services will have "Required Capabilitites," and if a server does not have a required capability, then it should not be manually assignable as an Edge, and a Mid must not be added as a parent for that DS in the Edge ATS config. + +Initially, this is completely backwards-compatible on upgrade, because initially no Delivery Service will have any Required Capabilities. + +This feature will be completely optional. TC operators who don't need Server Capabilities will simply not create them. + +Server Capabilities will be arbitrary strings. The ATS project will not "seed" any, and impose as little direction as possible. For example, Server Capabilitites could be Cache types, Server types, Hardware types, ATS versions, Lua support, other ATS plugin support, or any other features an operator needs to route (or not route) on. + + +## Proposed Change + +- Servers have Capabilities (i.e.: CACHE_MEMORY, CACHE_DISK ) + +- Delivery Services have Required Capabilities (i.e.: CACHE_MEMORY, CACHE_DISK) + +- When generating Configuration (e.g. ATS parent.config): + - If a Mid Server which is otherwise parented to an Edge does not have all Required Capabilities of a Delivery Service, that Mid will not be inserted as a parent for that Delivery Service’s remap and parent rules. + - Backward Compatibility is automatic: +- Initially, no Delivery Services have Required Capabilities. Hence, everything behaves like it does today. +- If an EDGE server does not have all capabilities required by a DS, that server SHOULD NOT be assignable to that DS. +- If an EDGE server is assigned to a DS which requires capabilities that server has, it SHOULD NOT be possible to remove those capabilities from that server. + +### Traffic Portal Impact + +- Server Page + - New dropdown to add to a text list: Capabilities + - List elements have a button to remove the capability + - Dropdown/List is just one option - other GUI components may be used + - Component should consider that there could be many Capabilities + +- Delivery Service Page + - New dropdown to add to a text list: Required Capabilities + - List elements have a button to remove a capability + - Dropdown/List is one option - other GUI components may be used + - Component should consider that there could be many Capabilities + +- New page for Server Capability Types + - Ability to add, delete Server Capability Types + - May be a text input, which adds to a list, with list element buttons to remove from the list + + +### Traffic Ops Impact + +`/server_server_capabilities` + - List all server capabilities assigned to a server + - GET+POST+DELETE + - PUT doesn't make sense. To remove one and add another, DELETE and POST. + +`/deliveryservices_required_capabilities` + - List all DS Required Capabilities + - GET+POST+DELETE + - PUT doesn't make sense. To remove one and add another, DELETE and POST. + +`/server_capabilities` Review comment: Ops rather than Admin, I'd think. I wasn't sure how much detail was necessary in a blueprint. I figured the PR Review could handle things like that, unless there's a big disagreement, and then I'd think it'd only go here after consensus on the list. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [trafficcontrol] rob05c commented on a change in pull request #3972: Add Server Capabilities blueprint
rob05c commented on a change in pull request #3972: Add Server Capabilities blueprint URL: https://github.com/apache/trafficcontrol/pull/3972#discussion_r333094054 ## File path: blueprints/server-capabilitites.md ## @@ -0,0 +1,162 @@ + +# Server Capabilities Review comment: Ehh. We discussed this quite a bit. Yeah, it's awkward that "capabilities" already exist (though those are really "permissions"). But there's not a good synonym that means exactly the same thing. There are similar things, but they all imply or omit what this actually is. It really is a "capability" of the server, something it's capable of doing. We were hoping by calling the entire feature "Server Capabilitites," e.g. the assignments are "server_server_capabilities," it would be clearer that they're not the same. It's hard to imagine anyone being confused anyway, users and servers are totally different things. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [trafficcontrol] rob05c commented on a change in pull request #3972: Add Server Capabilities blueprint
rob05c commented on a change in pull request #3972: Add Server Capabilities blueprint URL: https://github.com/apache/trafficcontrol/pull/3972#discussion_r333092037 ## File path: blueprints/server-capabilitites.md ## @@ -0,0 +1,162 @@ + +# Server Capabilities + +## Problem Description + +Suppose a Traffic Control operator has servers of a particular type. For example, servers with only Memory and no Disk cache. It's possible today to only route to those Edges, via manual Delivery Service Server assignments. But suppose you have a Mid server with only Memory and no Disk. Then suppose you have a certain class of traffic you need to route to this Mid, but not other traffic. For example, Delivery Services with small images; but not DSes with large binary files, which would destroy the cache. Right now, this isn't possible in Traffic Control. + +We propose a feature, called "Server Capabilitites" to solve this problem. Servers will have "capabilitites" and Delivery Services will have "Required Capabilitites," and if a server does not have a required capability, then it should not be manually assignable as an Edge, and a Mid must not be added as a parent for that DS in the Edge ATS config. + +Initially, this is completely backwards-compatible on upgrade, because initially no Delivery Service will have any Required Capabilities. + +This feature will be completely optional. TC operators who don't need Server Capabilities will simply not create them. + +Server Capabilities will be arbitrary strings. The ATS project will not "seed" any, and impose as little direction as possible. For example, Server Capabilitites could be Cache types, Server types, Hardware types, ATS versions, Lua support, other ATS plugin support, or any other features an operator needs to route (or not route) on. + + +## Proposed Change + +- Servers have Capabilities (i.e.: CACHE_MEMORY, CACHE_DISK ) + +- Delivery Services have Required Capabilities (i.e.: CACHE_MEMORY, CACHE_DISK) + +- When generating Configuration (e.g. ATS parent.config): + - If a Mid Server which is otherwise parented to an Edge does not have all Required Capabilities of a Delivery Service, that Mid will not be inserted as a parent for that Delivery Service’s remap and parent rules. + - Backward Compatibility is automatic: +- Initially, no Delivery Services have Required Capabilities. Hence, everything behaves like it does today. +- If an EDGE server does not have all capabilities required by a DS, that server SHOULD NOT be assignable to that DS. +- If an EDGE server is assigned to a DS which requires capabilities that server has, it SHOULD NOT be possible to remove those capabilities from that server. + +### Traffic Portal Impact + +- Server Page + - New dropdown to add to a text list: Capabilities + - List elements have a button to remove the capability + - Dropdown/List is just one option - other GUI components may be used + - Component should consider that there could be many Capabilities + +- Delivery Service Page + - New dropdown to add to a text list: Required Capabilities + - List elements have a button to remove a capability + - Dropdown/List is one option - other GUI components may be used + - Component should consider that there could be many Capabilities + +- New page for Server Capability Types + - Ability to add, delete Server Capability Types + - May be a text input, which adds to a list, with list element buttons to remove from the list + + +### Traffic Ops Impact + +`/server_server_capabilities` + - List all Server capabilities + - GET+POST+DELETE + - PUT doesn't make sense. To remove one and add another, DELETE and POST. + +`/deliveryservices_required_capabilities` + - List all DS Required Capabilities + - GET+POST+DELETE + - PUT doesn't make sense. To remove one and add another, DELETE and POST. + +`/server_capabilities` + - List, create, and delete Server Capabilities. + - POST+GET+DELETE + - PUT doesn’t make sense, Capabilities are strings, if one is misspelled it should be removed and re-added. Simpler, less error-prone than cascading changes. + +Additionally, ATS config generation (which is currently in Traffic Ops, but in the process of being moved to its own library/app) will require changes. Primarily `parent.config`, as in the description, to prevent Mids being assigned as Parents for DSes for which they lack the capabilitites. + + REST API Impact + +See Traffic Ops Impact + + Client Impact + +See Traffic Ops Impact - client functions for each endpoint. + + Data Model / Database Impact + +New tables for Capabilitites: `server_capability`, `server_server_capability`, `delivery_service_required_server_capability`. + +### ORT Impact + +n/a + +### Traffic Monitor Impact + +n/a + +### Traffic Router Impact + +n/a + +### Traffic Stats Impact + +n/a + +### Traffic Vault Impact + +n/a + +### Documentation Impact + +The new UI and API endpoints will be
[GitHub] [trafficcontrol] rob05c commented on a change in pull request #3972: Add Server Capabilities blueprint
rob05c commented on a change in pull request #3972: Add Server Capabilities blueprint URL: https://github.com/apache/trafficcontrol/pull/3972#discussion_r333089204 ## File path: blueprints/server-capabilitites.md ## @@ -0,0 +1,162 @@ + +# Server Capabilities + +## Problem Description + +Suppose a Traffic Control operator has servers of a particular type. For example, servers with only Memory and no Disk cache. It's possible today to only route to those Edges, via manual Delivery Service Server assignments. But suppose you have a Mid server with only Memory and no Disk. Then suppose you have a certain class of traffic you need to route to this Mid, but not other traffic. For example, Delivery Services with small images; but not DSes with large binary files, which would destroy the cache. Right now, this isn't possible in Traffic Control. + +We propose a feature, called "Server Capabilitites" to solve this problem. Servers will have "capabilitites" and Delivery Services will have "Required Capabilitites," and if a server does not have a required capability, then it should not be manually assignable as an Edge, and a Mid must not be added as a parent for that DS in the Edge ATS config. + +Initially, this is completely backwards-compatible on upgrade, because initially no Delivery Service will have any Required Capabilities. + +This feature will be completely optional. TC operators who don't need Server Capabilities will simply not create them. + +Server Capabilities will be arbitrary strings. The ATS project will not "seed" any, and impose as little direction as possible. For example, Server Capabilitites could be Cache types, Server types, Hardware types, ATS versions, Lua support, other ATS plugin support, or any other features an operator needs to route (or not route) on. + + +## Proposed Change + +- Servers have Capabilities (i.e.: CACHE_MEMORY, CACHE_DISK ) + +- Delivery Services have Required Capabilities (i.e.: CACHE_MEMORY, CACHE_DISK) + +- When generating Configuration (e.g. ATS parent.config): + - If a Mid Server which is otherwise parented to an Edge does not have all Required Capabilities of a Delivery Service, that Mid will not be inserted as a parent for that Delivery Service’s remap and parent rules. + - Backward Compatibility is automatic: +- Initially, no Delivery Services have Required Capabilities. Hence, everything behaves like it does today. +- If an EDGE server does not have all capabilities required by a DS, that server SHOULD NOT be assignable to that DS. +- If an EDGE server is assigned to a DS which requires capabilities that server has, it SHOULD NOT be possible to remove those capabilities from that server. + +### Traffic Portal Impact + +- Server Page + - New dropdown to add to a text list: Capabilities + - List elements have a button to remove the capability + - Dropdown/List is just one option - other GUI components may be used + - Component should consider that there could be many Capabilities + +- Delivery Service Page + - New dropdown to add to a text list: Required Capabilities + - List elements have a button to remove a capability + - Dropdown/List is one option - other GUI components may be used + - Component should consider that there could be many Capabilities + +- New page for Server Capability Types + - Ability to add, delete Server Capability Types + - May be a text input, which adds to a list, with list element buttons to remove from the list + + +### Traffic Ops Impact + +`/server_server_capabilities` + - List all Server capabilities Review comment: Changed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
