jhg03a commented on a change in pull request #4986: URL: https://github.com/apache/trafficcontrol/pull/4986#discussion_r489805812
########## File path: blueprints/traffic.portal.objects.md ########## @@ -0,0 +1,562 @@ +<!-- +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. +--> + +# Traffic Portals as API objects + +## Problem Description +Traffic Portals are, today, configured in Traffic Ops as regular servers, with +all the details that entails. A Traffic Portal can have updates and +revalidations pending, has a physical location, is associated with a CDN +despite being primarily for operating arbitrary numbers of CDNs, belongs to a +Cache Group despite not being a Cache Server, has a Type with no semantic +meaning beyond identifying it as a Traffic Portal instance, has a Profile with +no meaningful Parameters, has a HashID despite not being hashed for routing by +Traffic Router, and can have multiple network interfaces with their own +bandwidth limits - despite that Traffic Monitor does not monitor Traffic Portals +at all. + +## Proposed Change +All of these properties are superfluous with no real meaning for Traffic +Portals, and for that reason alone they'd be better off as their own object. +The new Traffic Portal object would be compact, containing only the properties +that are needed by and make sense on Traffic Portal instances. Doing this would +also be a step toward avoiding complex filtering on servers for processes that +are looking for specific kinds of servers (though as far as this writer knows, +there aren't any that look specifically for Traffic Portal servers). Review comment: They exist. ########## File path: blueprints/traffic.portal.objects.md ########## @@ -0,0 +1,562 @@ +<!-- +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. +--> + +# Traffic Portals as API objects + +## Problem Description +Traffic Portals are, today, configured in Traffic Ops as regular servers, with +all the details that entails. A Traffic Portal can have updates and +revalidations pending, has a physical location, is associated with a CDN +despite being primarily for operating arbitrary numbers of CDNs, belongs to a +Cache Group despite not being a Cache Server, has a Type with no semantic +meaning beyond identifying it as a Traffic Portal instance, has a Profile with +no meaningful Parameters, has a HashID despite not being hashed for routing by +Traffic Router, and can have multiple network interfaces with their own +bandwidth limits - despite that Traffic Monitor does not monitor Traffic Portals +at all. + +## Proposed Change +All of these properties are superfluous with no real meaning for Traffic +Portals, and for that reason alone they'd be better off as their own object. +The new Traffic Portal object would be compact, containing only the properties +that are needed by and make sense on Traffic Portal instances. Doing this would +also be a step toward avoiding complex filtering on servers for processes that +are looking for specific kinds of servers (though as far as this writer knows, +there aren't any that look specifically for Traffic Portal servers). + +## Data Model Impact +The proposed new object type is expressed below as a TypeScript interface. + +```typescript +interface TrafficPortal { + ipv4Address: string | null; + ipv6Address: string | null; + notes: string; + online: boolean; + tags: Set<string>; + url: URL; +} +``` + +Each property is further described in the following subsections. + +### IPv4 Address +This string contains a valid IPv4 Address at which the UI is served. If it is +`null`, then it is assumed that there is no static IPv4 Address at which +the Traffic Portal instance may be reached - or it does not communicate over +IPv4 at all. + +### IPv6 Address +This string contains a valid IPv6 Address at which the UI is served. If it is +`null`, then it is assumed that there is no static IPv6 Address at which +the Traffic Portal instance may be reached - or it does not communicate over +IPv6 at all. + +### Notes +This string contains arbitrary text for containing miscellaneous information. + +### Online +This boolean value indicates whether or not this Traffic Portal is online and +serving its user interface. + +### Tags +The Tags associated with a Traffic Portal are represented by a set of strings +that are Tag Names. + +(Note that this property should only be added if the implementation is done +after #4819 is merged - if ever.) + +### URL +This string is a full URL at which the UI is served, including scheme (e.g. +`http://`) and optionally port (e.g. `80`), e.g. +`https://trafficportal.infra.ciab.test:443`. + +If the port is omitted, it will be guessed based on the protocol indicated by +the schema, e.g. `80` for `http://`, which indicates the HTTP protocol. The only +valid schemes are `https://` and `http://`. + +This property uniquely identifies a Traffic Portal, and must therefore Review comment: Are you also attempting to cover the use case of a LB sitting in front of multiple TP instances? ########## File path: blueprints/traffic.portal.objects.md ########## @@ -0,0 +1,562 @@ +<!-- +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. +--> + +# Traffic Portals as API objects + +## Problem Description +Traffic Portals are, today, configured in Traffic Ops as regular servers, with +all the details that entails. A Traffic Portal can have updates and +revalidations pending, has a physical location, is associated with a CDN +despite being primarily for operating arbitrary numbers of CDNs, belongs to a +Cache Group despite not being a Cache Server, has a Type with no semantic +meaning beyond identifying it as a Traffic Portal instance, has a Profile with +no meaningful Parameters, has a HashID despite not being hashed for routing by +Traffic Router, and can have multiple network interfaces with their own +bandwidth limits - despite that Traffic Monitor does not monitor Traffic Portals +at all. + +## Proposed Change +All of these properties are superfluous with no real meaning for Traffic +Portals, and for that reason alone they'd be better off as their own object. +The new Traffic Portal object would be compact, containing only the properties +that are needed by and make sense on Traffic Portal instances. Doing this would +also be a step toward avoiding complex filtering on servers for processes that +are looking for specific kinds of servers (though as far as this writer knows, +there aren't any that look specifically for Traffic Portal servers). + +## Data Model Impact +The proposed new object type is expressed below as a TypeScript interface. + +```typescript +interface TrafficPortal { + ipv4Address: string | null; + ipv6Address: string | null; + notes: string; + online: boolean; + tags: Set<string>; + url: URL; +} +``` + +Each property is further described in the following subsections. + +### IPv4 Address +This string contains a valid IPv4 Address at which the UI is served. If it is +`null`, then it is assumed that there is no static IPv4 Address at which +the Traffic Portal instance may be reached - or it does not communicate over +IPv4 at all. + +### IPv6 Address +This string contains a valid IPv6 Address at which the UI is served. If it is +`null`, then it is assumed that there is no static IPv6 Address at which +the Traffic Portal instance may be reached - or it does not communicate over +IPv6 at all. + +### Notes +This string contains arbitrary text for containing miscellaneous information. + +### Online +This boolean value indicates whether or not this Traffic Portal is online and +serving its user interface. + +### Tags +The Tags associated with a Traffic Portal are represented by a set of strings +that are Tag Names. + +(Note that this property should only be added if the implementation is done +after #4819 is merged - if ever.) + +### URL +This string is a full URL at which the UI is served, including scheme (e.g. +`http://`) and optionally port (e.g. `80`), e.g. +`https://trafficportal.infra.ciab.test:443`. + +If the port is omitted, it will be guessed based on the protocol indicated by +the schema, e.g. `80` for `http://`, which indicates the HTTP protocol. The only +valid schemes are `https://` and `http://`. + +This property uniquely identifies a Traffic Portal, and must therefore +obviously be unique (this allows multiple Traffic Portals - or other +services - to be running at the same static IP address(es) as long as they +are not literally the same network location; port, host, or protocol could +differ). + +## Impacted Components +Since Traffic Portals are intended only as a UI, and need not even exist for an +ATC system to function normally, the impact should be quite limited. + +### Traffic Ops Impact + +#### Database Impact +A new table must be created to store Traffic Portal information. It can be +populated trivially from the information of servers with Type IDs that identify +Types which have the exact Name "TRAFFIC_PORTAL". Removal of existing data in +the generic `servers` table should be left up to operators' discretion. The Review comment: The existing server object must not be removed or more of its functions must be added to this new object. TO is the system of record for all infrastructure in ATC. All the concepts of how operators can access it such as OOB login info or management IPs must be preserved. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
