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/12/01 19:05:59 UTC
[GitHub] [trafficcontrol] ocket8888 commented on a change in pull request #6095: Server Layered Profile Blueprint
ocket8888 commented on a change in pull request #6095:
URL: https://github.com/apache/trafficcontrol/pull/6095#discussion_r760481942
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
Review comment:
nit but I don't think this was supposed to be a part of the list
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing servers endpoints.
+
+#### API 5.0 GET
+- JSON **response** with the proposed change will look as follows:
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ }
Review comment:
this doesn't look right to me. Servers don't currently have a `requested` property, and I don't think the name of the property is supposed to be `layeredProfiles` - shouldn't it just be `profiles`? There are no "un-layered" Profiles on servers from which to distinguish them.
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing servers endpoints.
+
+#### API 5.0 GET
+- JSON **response** with the proposed change will look as follows:
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 5.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+`PUT /servers/5`
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+returns a **400** **response** with
+
+```JSON
+{
+ "alerts":[
+ {
+ "text":"cannot associate multiple profiles to a server with current API version but can be done via 5.0+",
+ "level":"error"
+ }
+]}
+```
+
+#### API 6.0 GET
Review comment:
I think this section should be 5.0? And all of my comments above apply in turn to each endpoint here.
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing servers endpoints.
+
+#### API 5.0 GET
+- JSON **response** with the proposed change will look as follows:
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 5.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
Review comment:
Hadn't we settled on using Profile Names instead of IDs? The way they are presented and identified should be the same in responses and requests
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing servers endpoints.
+
+#### API 5.0 GET
+- JSON **response** with the proposed change will look as follows:
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ },
Review comment:
same as above RE: `requested` and `layeredProfiles`
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing servers endpoints.
+
+#### API 5.0 GET
+- JSON **response** with the proposed change will look as follows:
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 5.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+`PUT /servers/5`
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
Review comment:
Same as above RE: names vs IDs and requests and responses matching
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
Review comment:
Also:
- `/deliveryservices/{{ID}}/servers`
- `/deliveryservices/{{ID}}/servers/eligible`
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing servers endpoints.
+
+#### API 5.0 GET
+- JSON **response** with the proposed change will look as follows:
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 5.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+`PUT /servers/5`
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+returns a **400** **response** with
+
+```JSON
+{
+ "alerts":[
+ {
+ "text":"cannot associate multiple profiles to a server with current API version but can be done via 5.0+",
+ "level":"error"
+ }
+]}
+```
+
+#### API 6.0 GET
+- JSON **response** with the proposed change will look as follows:
+ `/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID",
+ "AMIGA_123",
+ "CDN_FOO"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID",
+ "AMIGA_123",
+ "CDN_FOO"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 6.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+`PUT /servers/5`
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+return following **response**
+```JSON
+{ "alerts": [
+ {
+ "text": "Server created/updated",
+ "level": "success"
+ }
+],
+ "response": {
+ "cachegroup": "CDN_in_a_Box_Mid",
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "id": 5,
+ "layeredProfiles": [
+ "MID",
+ "AMIGA_123",
+ "CDN_FOO"
+ ],
+ "profileDesc": "Mid Cache - Apache Traffic Server, Amiga 123 Machine, CDN Foo",
+ "profileIds": [10, 11, 15],
+ ⋮
+ }
+}
+```
+
+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 |
+| layeredProfiles | text | required | the profile names associated with a server |
Review comment:
This is really just the name of a single Profile, right? That's why it has `order`, and why we need a table at all, I thought.
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing servers endpoints.
+
+#### API 5.0 GET
+- JSON **response** with the proposed change will look as follows:
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 5.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+`PUT /servers/5`
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+returns a **400** **response** with
+
+```JSON
+{
+ "alerts":[
+ {
+ "text":"cannot associate multiple profiles to a server with current API version but can be done via 5.0+",
+ "level":"error"
+ }
+]}
+```
+
+#### API 6.0 GET
+- JSON **response** with the proposed change will look as follows:
+ `/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID",
+ "AMIGA_123",
+ "CDN_FOO"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID",
+ "AMIGA_123",
+ "CDN_FOO"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 6.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+`PUT /servers/5`
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+return following **response**
+```JSON
+{ "alerts": [
+ {
+ "text": "Server created/updated",
+ "level": "success"
+ }
+],
+ "response": {
+ "cachegroup": "CDN_in_a_Box_Mid",
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "id": 5,
+ "layeredProfiles": [
+ "MID",
+ "AMIGA_123",
+ "CDN_FOO"
+ ],
+ "profileDesc": "Mid Cache - Apache Traffic Server, Amiga 123 Machine, CDN Foo",
+ "profileIds": [10, 11, 15],
+ ⋮
+ }
+}
+```
+
+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 |
+| layeredProfiles | text | required | the profile names associated with a server |
+| order | bigint | required | the order in which a profile is applied to a server |
+
+**API constraints**
+- In API 5.0, GET /servers object profile and profileId fields to be arrays, but a PUT or POST with multiple values returns a 400 error.
+ The UI may or may not display a list (which can only add 1), the client implements handling multiple, and the API is documented to potentially return multiple and how their Parameters must be applied.
+- In API 6.0 (or possibly 5.0 in the following TC major version wherein API 4.0 is removed), this feature is actually implemented, and multiple profiles can be assigned, are displayed in the UI, etc.
+
+The only disadvantage to splitting it across mulitple version is a little delay to get the feature deployed.
+But the advantage is that it solves both concerns:
+- clients on supported APIs are never given 4xx errors even after the feature is in-use
+- we never return or apply partial data that could produce wrong results in production
+
+- Add `Profiles` key to API endpoints for Server objects (and ProfileNames, ProfileIDs)
+
+#### Client Impact
+- Existing Go client methods will be updated for the `/servers` endpoints in order to write TO API tests for the exising endpoints.
+- All functions which get Parameters on 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:
+```text
+ Table "traffic_ops.server_profiles"
+ Column | Type | Collation | Nullable | Default
+---------------+--------------------------+-----------+----------+--------
+ server | bigint | | not null |
+ profile_names | text | | not null |
+ order | bigint | | not null |
+Indexes:
+ "pk_server_profile" PRIMARY KEY(profile_names, server, order)
+Foreign-key constraints:
+ "fk_server" FOREIGN KEY (server) REFERENCES server(id)
+ "fk_server" FOREIGN KEY (profile_names) REFERENCES profile(name)
+```
+
+All profiles assigned to a given server will have the same values of:
+- type
+- cdn
+- routing_disabled
Review comment:
This one sounds hard to enforce. Imagine I have a server that has a bunch of Profiles that are all `routingDisabled` set to `true`. What if I change one to `false`? Does Profile update validation prevent that? If it doesn't, my cache server cannot be updated unless I revert it. If it does, then I need to remove all Profiles from the server, update them all, and reassign in order to make the change. Both are cumbersome. I would say don't bother.
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing servers endpoints.
+
+#### API 5.0 GET
+- JSON **response** with the proposed change will look as follows:
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 5.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+`PUT /servers/5`
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+returns a **400** **response** with
+
+```JSON
+{
+ "alerts":[
+ {
+ "text":"cannot associate multiple profiles to a server with current API version but can be done via 5.0+",
+ "level":"error"
+ }
+]}
+```
+
+#### API 6.0 GET
+- JSON **response** with the proposed change will look as follows:
+ `/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID",
+ "AMIGA_123",
+ "CDN_FOO"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID",
+ "AMIGA_123",
+ "CDN_FOO"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 6.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+`PUT /servers/5`
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+return following **response**
+```JSON
+{ "alerts": [
+ {
+ "text": "Server created/updated",
+ "level": "success"
+ }
+],
+ "response": {
+ "cachegroup": "CDN_in_a_Box_Mid",
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "id": 5,
+ "layeredProfiles": [
+ "MID",
+ "AMIGA_123",
+ "CDN_FOO"
+ ],
+ "profileDesc": "Mid Cache - Apache Traffic Server, Amiga 123 Machine, CDN Foo",
+ "profileIds": [10, 11, 15],
Review comment:
I don't think we wanted to identify Profiles twice, right? Also, for my money, we can just drop `profileDesc`. Figuring out how to generate it is too difficult, and I don't know what use it could possibly have.
##########
File path: blueprints/layered-profile.md
##########
@@ -0,0 +1,347 @@
+<!--
+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 to 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 server, as well as the profile each parameter came from. A new page, linked from 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 Servers, on the existing Server pages.
+3. Filtering based on Profiles will also need to be updated to take into account the plurality of Profiles.
+
+### 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 server.
+
+- `/servers/ GET, POST`
+- `/servers/{id} PUT, DELETE`
+- `/servers/details`
+
+#### REST API Impact
+
+- No new endpoints are required
+
+**Existing Endpoints**
+
+- Modify JSON request and response for existing servers endpoints.
+
+#### API 5.0 GET
+- JSON **response** with the proposed change will look as follows:
+`/servers?id=5`
+```JSON
+{
+ "id": 5,
+ ⋮
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ }
+}
+```
+
+`/servers`
+```JSON
+{
+ "requested": {
+ "layeredProfiles": [
+ "MID"
+ ],
+ ⋮
+ },
+ ⋮
+}
+```
+
+#### API 5.0 POST/PUT
+JSON **request** with the proposed change will look as follows:
+
+`POST /servers `
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+`PUT /servers/5`
+```JSON
+{
+ "cachegroupId": 6,
+ "cdnId": 2,
+ ⋮
+ "interfaces": [
+ ⋮
+ ],
+ ⋮
+ "profileId": [10, 11, 15],
+ ⋮
+}
+```
+
+returns a **400** **response** with
+
+```JSON
+{
+ "alerts":[
+ {
+ "text":"cannot associate multiple profiles to a server with current API version but can be done via 5.0+",
+ "level":"error"
+ }
+]}
+```
Review comment:
This part confuses me - it's a response to a 5.0 request, but it's saying that the current API version is insufficient and the request should use API v5.0+?
--
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