jhg03a commented on a change in pull request #4986: URL: https://github.com/apache/trafficcontrol/pull/4986#discussion_r489823763
########## 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 Review comment: This is a functionality reduction from today where we can have TP in custom statuses that match server lifecycle. ---------------------------------------------------------------- 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]
