mitchell852 commented on a change in pull request #3972: Add Server Capabilities blueprint URL: https://github.com/apache/trafficcontrol/pull/3972#discussion_r334117890
########## File path: blueprints/server-capabilitites.md ########## @@ -0,0 +1,164 @@ +<!-- +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. +--> +# 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. + +- Initially, Server Capability names are limited to `[a-Z]`, `[0-9]`, `_`, and `-`. This allows them to be put in most parts of a URI, as well as being the characters of Base64 URL Encoding. We may decide to allow high unicode later. But for now, since we're not sure yet what usage will look like, it's much easier to add characters later without breaking people, than it is to remove them. + +### Traffic Portal Impact + +- Server Page + - New dropdown to add to a text list: Capabilities Review comment: I would go this route IF the server capabilities were part of the server object but since they are not I will probably create a UI experience similar to how you assign servers to a delivery service. For example, when viewing a server, you click "More > Manage Server Capabilities" which takes you to: `tp.domain.com/#!/servers/4/capabilities` where you can add and remove server capabilities as needed. Sound ok? ---------------------------------------------------------------- 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
