rob05c commented on a change in pull request #4986: URL: https://github.com/apache/trafficcontrol/pull/4986#discussion_r489812228
########## 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 { Review comment: This is missing a lot of Asset data about the physical server. I've said for years that IMO Traffic Ops shouldn't be used for Asset Management. But it's simply a fact that it's designed and used for that today. A lot of Server fields this removes are cache-specific, but a lot are Asset data. Like the netmask, gateway, ILO fields, physLocation, rack. That's all Asset data people are using to track server machines today, that has to be stored somewhere. Unless there's a concrete proposal that Traffic Control / Traffic Ops move away from Asset Management, and Users (including us) will be required to migrate their data into new Asset Management systems? Is the intention to propose and require that? If not, we need to identify and add the Asset-related fields (the ones I mention aren't exhaustive). Ideally in a shared DB table for normalization. ---------------------------------------------------------------- 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]
