[GitHub] [trafficcontrol] rob05c commented on a change in pull request #6095: Layered Profile Blueprint

[GitBox <gi...@apache.org>]

rob05c commented on a change in pull request #6095:
URL: https://github.com/apache/trafficcontrol/pull/6095#discussion_r688214599



##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,274 @@
+<!--
+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.
+-->
+# Layered Profile
+
+## Problem Description
+
+Profiles are unwieldy and dangerous for Operations.
+
+Currently, we have countless Profiles, in broad categories. For example, "EDGE_123_FOO_ABC_ATS_714-RC0-42" might represent servers which are
+1. Edges
+2. Amiga 123 machines
+3. In the Foo CDN
+4. In the ABC datacenter
+5. Running ATS 7.14 RC0
+6. Who knows what 42 means?
+
+Suppose we have Amiga 456 machines, at DEF datacenters, and a Bar CDN, and some servers are running ATS 7.15, 8.0, and 8.1. We make profiles for each server we have fitting all those categories:
+
+EDGE_123_FOO_ABC_ATS_714-RC0-27, EDGE_456_FOO_ABC_ATS_714-RC0-27, EDGE_123_BAR_ABC_ATS_714-RC0-42, EDGE_456_FOO_DEF_ATS_714-RC1-27, EDGE_123_FOO_DEF_ATS_800-RC4-29
+
+- The number of Profiles quickly becomes a combinatorial explosion
+- It's nearly impossible for Ops engineers to figure out what Parameters are assigned to all Profiles of a given CDN, machine, or datacenter.
+- What about that one random Parameter on a Cloned profile that was changed a year ago? Is it still in place? Should it be? Did it need to be applied to all new Profiles cloned from this one?
+
+## Proposed Change
+
+Layered Profiles allow assigning multiple profiles, in order, to both Delivery Services and Servers. If multiple profiles have a parameter with the same name and config File, the parameter from the last profile in the ordering is applied.
+
+Layered Profiles is exactly as powerful as the existing profiles, it doesn't enable any new things. It makes profiles much easier to manage.
+
+With Layered Profiles, hundreds of profiles become a few dozen, each representing a logical group. For example, a server might have the profiles, in order:
+1. EDGE
+2. AMIGA_123
+3. CDN_FOO
+4. DATACENTER_ABC
+5. ATS_714
+6. Custom_Hack_42
+
+### Traffic Portal Impact
+
+1. A UI to view all parameters currently applied to a delivery service/server, as well as the profile each parameter came from. A new page, linked from DS and Server pages. For eg:
+
+| Name                                             |Config File               | Value                                | Profile   |
+|--------------------------------------------------|--------------------------|--------------------------------------|-----------|
+| location                                         | url_sig_myds.config      | /opt/trafficserver/etc/trafficserver | EDGE      |
+| Drive_Prefix                                     | storage.config           | /dev/sd                              | AMIGA_123 |
+| error_url                                        | url_sig_myotherds.config | 403                                  | EDGE      |
+| CONFIG proxy.config.exec_thread.autoconfig.scale | records.config           | FLOAT 1.5                            | ATS_714   |
+
+2. A UI change to add, remove, and reorder (sortable list) profiles for both Delivery Services and Servers, on the existing DS and Server pages.
+
+### Traffic Ops Impact
+
+- Traffic Ops will need to add the logic to the below-mentioned existing API endpoints, in order to show/create/update/delete a sorted list of profiles for delivery services and server.
+- `/deliveryservices/ GET, POST`
+- `/deliveryservices/{id} PUT, DELETE`
+- `/server/  GET, POST`
+- `/servers/{id} PUT, DELETE`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing delivery services and servers endpoints.
+- JSON **response** with the proposed change will look as follows:
+
+`/deliveryservices?id=100`
+```JSON
+{ 
+  "id": 100,
+  ⋮
+  "requested": {
+    "profileIds": [
+      1234,
+      5678,
+      9012
+    ],
+    "profileNames": [
+      "EDGE",
+      "ATS8",
+      "TOP"
+    ]

Review comment:
       +1 on names. We might need to make sure the DB field cascades if the name changes, but otherwise it should be fine.
    
   IMO the advantages almost always significantly outweigh the disadvantages for using a real candidate key (which may be compound) instead of an artificial ID.




-- 
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.

To unsubscribe, e-mail: issues-unsubscribe@trafficcontrol.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org