You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2021/08/12 16:08:41 UTC
[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #6095: Layered Profile Blueprint
ocket8888 commented on a change in pull request #6095:
URL: https://github.com/apache/trafficcontrol/pull/6095#discussion_r687871971
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
+Indexes:
+"pk_deliveryservice_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+"fk_deliveryservice" FOREIGN KEY (deliveryservice) REFERENCES deliveryservice(id)
Review comment:
`profile` should probably also be a foreign key into `profile`, right?
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
+Indexes:
+"pk_deliveryservice_profile" PRIMARY KEY(profile)
Review comment:
This should probably use a Primary Key containing not just profile, or two delivery services would not be able to share any single Profile. Seems like it needs `PRIMARY KEY (profile, deliveryservice, order)`, so that no single Delivery Service may have the same Profile in the same position.
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
+Indexes:
+"pk_deliveryservice_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+"fk_deliveryservice" FOREIGN KEY (deliveryservice) REFERENCES deliveryservice(id)
+```
+
+```text
+ Table "traffic_ops.server_profiles"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ server | bigint | | not null |
+ profile | bigint | | not null |
+ order | bigint | | not null |
+ last_updated | timestamp with time zone | | not null | now()
+Indexes:
+ "pk_server_profile" PRIMARY KEY(profile)
Review comment:
Same as above RE: Primary Key
##########
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`
Review comment:
Also
- `/deliveryservice_requests`
- `/deliveryservice_requests/{{ID}}/assign`
- `/deliveryservice_requests/{{ID}}/status`
- `/deliveryservices/{{ID}}/safe`
- `/deliveryservices/{{ID}}/servers`
- `/deliveryservices/{{ID}}/servers/eligible`
- `/deliveryservices/{{XMLID}}/servers`
- `/servers/details`
- `/servers/{{ID}}/deliveryservices`
##########
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:
Is it necessary to specify both the IDs and the Names? Seems like that will cause a bunch of annoying edge case checking that could be skipped if they're only identified once (and I would vote that it be by name).
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
Review comment:
Does this actually need a `last_updated`? When would that be used or displayed? Could we instead just include a trigger to change the `last_updated` of affected Delivery Services when changes are made in this table?
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
+Indexes:
+"pk_deliveryservice_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+"fk_deliveryservice" FOREIGN KEY (deliveryservice) REFERENCES deliveryservice(id)
+```
+
+```text
+ Table "traffic_ops.server_profiles"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ server | bigint | | not null |
+ profile | bigint | | not null |
+ order | bigint | | not null |
+ last_updated | timestamp with time zone | | not null | now()
+Indexes:
+ "pk_server_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+ "fk_server" FOREIGN KEY (server) REFERENCES server(id)
+```
+
+### ORT Impact
+New set of profiles will be created and the profile-parameter relationship will change.
+
+### Traffic Monitor Impact
+No impact
+
+### Traffic Router Impact
+No impact
+
+### Traffic Stats Impact
+No impact
+
+### Traffic Vault Impact
+No impact
+
+### Documentation Impact
+All existing endpoints will need to be updated, along with the documentation explaining `layered_profile`.
+
+### Testing Impact
+Client/API integration tests should be updated to verify the `layered_profile` functionality on existing API `/deliveryservices`, `/servers` endpoints.
+
+### Performance Impact
+We do not anticipate any performance impact with layered_profile approach.
+
+### Security Impact
+We do not anticipate any impact on security.
+
+### Upgrade Impact
+- A Database Migration to:
+ - drop profile column in existing deliveryservice and server table
+ - insert existing server and DS profiles along with their order into the new tables(deliveryservice_profiles, server_profiles)
+- The new capability can just be added to the `seeds.sql` file.
Review comment:
What new ~~Permission~~ capability?
##########
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.
+
Review comment:
Changes to DSR views will also be necessary to properly display changes proposed for swapping around Profiles - it may be necessary to make explicit note of the changes rather than just showing current vs proposed, because if the lists get long enough it could get very difficult to manually figure out the actual difference.
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
+Indexes:
+"pk_deliveryservice_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+"fk_deliveryservice" FOREIGN KEY (deliveryservice) REFERENCES deliveryservice(id)
+```
+
+```text
+ Table "traffic_ops.server_profiles"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ server | bigint | | not null |
+ profile | bigint | | not null |
+ order | bigint | | not null |
+ last_updated | timestamp with time zone | | not null | now()
+Indexes:
+ "pk_server_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+ "fk_server" FOREIGN KEY (server) REFERENCES server(id)
Review comment:
same as above RE: `profile` foreign key
##########
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:
Review comment:
Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles. Should it allow specifying multiple Profiles in the filter?
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
+Indexes:
+"pk_deliveryservice_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+"fk_deliveryservice" FOREIGN KEY (deliveryservice) REFERENCES deliveryservice(id)
+```
+
+```text
+ Table "traffic_ops.server_profiles"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ server | bigint | | not null |
+ profile | bigint | | not null |
+ order | bigint | | not null |
+ last_updated | timestamp with time zone | | not null | now()
+Indexes:
+ "pk_server_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+ "fk_server" FOREIGN KEY (server) REFERENCES server(id)
+```
+
+### ORT Impact
+New set of profiles will be created and the profile-parameter relationship will change.
+
+### Traffic Monitor Impact
+No impact
+
+### Traffic Router Impact
+No impact
Review comment:
These will probably be affected because the Snapshots and Monitoring Configurations for a CDN include Profile and Parameter information for the servers, Traffic Monitors, and Traffic Routers that they contain.
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
+Indexes:
+"pk_deliveryservice_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+"fk_deliveryservice" FOREIGN KEY (deliveryservice) REFERENCES deliveryservice(id)
+```
+
+```text
+ Table "traffic_ops.server_profiles"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ server | bigint | | not null |
+ profile | bigint | | not null |
+ order | bigint | | not null |
+ last_updated | timestamp with time zone | | not null | now()
Review comment:
Same as above RE: `last_updated`
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
+Indexes:
+"pk_deliveryservice_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+"fk_deliveryservice" FOREIGN KEY (deliveryservice) REFERENCES deliveryservice(id)
+```
+
+```text
+ Table "traffic_ops.server_profiles"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ server | bigint | | not null |
+ profile | bigint | | not null |
+ order | bigint | | not null |
+ last_updated | timestamp with time zone | | not null | now()
+Indexes:
+ "pk_server_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+ "fk_server" FOREIGN KEY (server) REFERENCES server(id)
+```
+
+### ORT Impact
+New set of profiles will be created and the profile-parameter relationship will change.
+
+### Traffic Monitor Impact
+No impact
+
+### Traffic Router Impact
+No impact
+
+### Traffic Stats Impact
+No impact
+
+### Traffic Vault Impact
+No impact
+
+### Documentation Impact
+All existing endpoints will need to be updated, along with the documentation explaining `layered_profile`.
Review comment:
> ... along with the documentation explaining `layered_profile`.
That can probably go in the Profiles and Parameters overview section
##########
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"
+ ]
+ ⋮
+ }
+}
+```
+
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ }
+}
+```
+
+JSON **request** with the proposed change will look as follows:
+
+`/deliveryservices`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1234,
+ 5678,
+ 9012
+ ],
+ "profileNames": [
+ "EDGE",
+ "ATS8",
+ "TOP"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "profileIds": [
+ 1357,
+ 2468,
+ 2356
+ ],
+ "profileNames": [
+ "MID",
+ "TOP",
+ "PRIMARY"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+The following table describes the top level `layered_profile` object for delivery services:
+
+| field | type | optionality | description |
+| ------------------ | --------------| ----------- | ---------------------------------------------------------------|
+| deliveryservice | bigint | required | the delivery service id associated with a given profile |
+| profile | bigint | required | the profile id associated with a delivery service |
+| order | bigint | required | the order in which a profile is applied to a delivery service |
+| lastUpdated | bigint | required | the last time this delivery service was updated |
+
+The following table describes the top level `layered_profile` object for servers:
+
+| field | type | optionality | description |
+| ----------- | ---------------------| ----------- | ---------------------------------------------------------------|
+| server | bigint | required | the server id associated with a given profile |
+| profile | bigint | required | the profile id associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+| lastUpdated | bigint | required | the last time this server was updated |
+
+**API constraints**
+- TO REST APIs will not be backward compatibility and this feature will be a major version (v5.0) change.
+- Add `Profiles` key to API endpoints for Server and DeliveryService objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/deliveryservices` and `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on Delivery Services or Servers must be changed to get the Parameters of all assigned Profiles in order.
+
+#### Data Model / Database Impact
+
+- A new Database Table `server_profiles` as described below, will be created:
+- A new Database Table `deliveryservice_profiles` as described below, will be created:
+```text
+ Table "traffic_ops.deliveryservice_profiles"
+ Column | Type | Collation | Nullable | Default
+----------------+--------------------------+-----------+----------+--------
+deliveryservice | bigint | | not null |
+profile | bigint | | not null |
+order | bigint | | not null |
+last_updated | timestamp with time zone | | not null | now()
+Indexes:
+"pk_deliveryservice_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+"fk_deliveryservice" FOREIGN KEY (deliveryservice) REFERENCES deliveryservice(id)
+```
+
+```text
+ Table "traffic_ops.server_profiles"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ server | bigint | | not null |
+ profile | bigint | | not null |
+ order | bigint | | not null |
+ last_updated | timestamp with time zone | | not null | now()
+Indexes:
+ "pk_server_profile" PRIMARY KEY(profile)
+Foreign-key constraints:
+ "fk_server" FOREIGN KEY (server) REFERENCES server(id)
+```
+
+### ORT Impact
+New set of profiles will be created and the profile-parameter relationship will change.
+
+### Traffic Monitor Impact
+No impact
+
+### Traffic Router Impact
+No impact
+
+### Traffic Stats Impact
+No impact
+
+### Traffic Vault Impact
+No impact
+
+### Documentation Impact
+All existing endpoints will need to be updated, along with the documentation explaining `layered_profile`.
+
+### Testing Impact
+Client/API integration tests should be updated to verify the `layered_profile` functionality on existing API `/deliveryservices`, `/servers` endpoints.
Review comment:
and DSRs
--
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