A server is a server. We were bad and put non-server, or special server type data on everything. Server should remain server, but you can take all the ancillary columns off into one or more separate tables joined on the PK of a server row. For now, that would be everything. As TO adjusts to no longer need the extra concepts, those joined nonsense rows for other types can be dropped. That said, significant changes to TODB are complicated and risky so we would want to move with care and foresight into other things of significant effort so there's not a conflict by accident or instability delivered until it's complete.
Jonathan G On 8/25/20, 3:57 PM, "Jeremy Mitchell" <[email protected]> wrote: Oh, this would help us get rid of the "ALL" cdn as well which has kind of been a pain. Lots of "if cdn != ALL, then do something..." in the codebase..which eventually leads to bugs like this: https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/issues/4324__;!!CQl3mcHX2A!S8EeyRyjEHQ4cqwQ1ZGzR3tX4StRhNk2mtP19puNOM6EeXzXN8hgwCpKGRG2HqIvzrYc$ On Tue, Aug 25, 2020 at 3:42 PM Zach Hoffman <[email protected]> wrote: > +1 for splitting cache servers and infra servers. Currently, each server > must be associated with a CDN and cache group. > > While that part may seem logical by itself, when updates are queued on a > CDN, it sets the upd_pending column on *all* of that CDN's servers, > including servers of RASCAL type, servers of CCR type, etc. Although this > doesn't hurt anything, as Jeremy has said, side effects like these make > database-level validation difficult, so a table split of some kind seems > like a step in the right direction. > > -Zach > > On Tue, Aug 25, 2020 at 2:22 PM Jeremy Mitchell <[email protected]> > wrote: > > > If you look at the columns of the servers table, you'll see that most are > > specific to "cache servers", so I definitely think that should be > > addressed. Overloaded tables make it hard (impossible?) to do any > > database-level validation and I thought we wanted to move in that > direction > > where possible. > > > > At the very least I think we should have these tables to capture all our > > "server objects": > > > > - cache_servers (formerly known as servers) > > - infra_servers > > - origins > > > > Now whether the API mirrors the tables is another discussion. I don't > think > > we strive for that but sometimes GET /api/cache_servers just seems to > make > > sense. > > > > Jeremy > > > > > > > > > > > > On Tue, Aug 25, 2020 at 12:19 PM Gray, Jonathan < > [email protected] > > > > > wrote: > > > > > I agree with Dave here. Instead of trying to make our database and API > > > identical, we should focus on doing better relational data modeling > > inside > > > the database and letting that roll upward into TO with more specific > > > queries and stronger data integrity inside the database. > > > > > > Jonathan G > > > > > > On 8/25/20, 11:20 AM, "Dave Neuman" <[email protected]> wrote: > > > > > > This feels extremely heavy handed to me. I don't think we should > try > > > to > > > build out a new table for different server types which will mostly > > > have all > > > the same columns. I could maybe see a total of 3 tables for > caches, > > > origins (which already exists), and other things, but even then I > > > would be > > > hesitant to think it was a great idea. Even if we have a caches > > > table, we > > > still have to put some sort of typing in place to distinguish edges > > and > > > mids and with the addition of flexible topologies, even that is > > muddy; > > > it > > > might be better to call them forward and reverse proxies instead, > but > > > that > > > is a different conversation. I think while it may seem like this > > > solves a > > > lot of problems on the surface, I still think some of the things > you > > > are > > > trying to address will remain and we will have new problems on top > of > > > that. > > > > > > I think we should think about addressing this problem with a better > > > way of > > > identifying server types that can be accounted for in code instead > of > > > searching for strings, adding some validation to our API based on > the > > > server types (e.g. only require some fields for caches), and also > by > > > thinking about the way we do our API and maybe trying to get away > > from > > > "based on database tables" to be "based on use cases". > > > > > > --Dave > > > > > > On Tue, Aug 25, 2020 at 10:49 AM ocket 8888 <[email protected]> > > > wrote: > > > > > > > Hello everyone, I'd like to discuss something that the Traffic > Ops > > > Working > > > > Group > > > > has been working on: splitting servers apart. > > > > > > > > Servers have a lot of properties, and most are specifically > > > important to > > > > Cache > > > > Servers - made all the more clear by the recent addition of > > multiple > > > > network > > > > interfaces. We propose they be split up into different objects > > based > > > on > > > > type - > > > > which will also help reduce (if not totally eliminate) the use of > > > custom > > > > Types > > > > for servers. This will also eliminate the need for hacky ways of > > > searching > > > > for > > > > certain kinds of servers - e.g. checking for a profile name that > > > matches > > > > "ATS_.*" to determine if something is a cache server and > searching > > > for a > > > > Type > > > > that matches ".*EDGE.*" to determine if something is an edge-tier > > or > > > > mid-tier > > > > Cache Server (both of which are real checks in place today). > > > > > > > > The new objects would be: > > > > > > > > - Cache Servers - exactly what it sounds like > > > > - Infrastructure Servers - catch-all for anything that doesn't > fit > > > in a > > > > different category, e.g. Grafana > > > > - Origins - This should ideally eat the concept of "ORG"-type > > > servers so > > > > that we ONLY have Origins to express the concept of an Origin > > server. > > > > - Traffic Monitors - exactly what it sounds like > > > > - Traffic Ops Servers - exactly what it sounds like > > > > - Traffic Portals - exactly what it sounds like > > > > - Traffic Routers - exactly what it sounds like > > > > - Traffic Stats Servers - exactly what it sounds like - but > > InfluxDB > > > > servers would be Infrastructure Servers; this is just whatever > > > machine is > > > > running the actual Traffic Stats program. > > > > - Traffic Vaults - exactly what it sounds like > > > > > > > > I have a Draft PR ( > > > > > > https://urldefense.com/v3/__https://github.com/apache/trafficcontrol/pull/4986__;!!CQl3mcHX2A!SSbbYaDqtrWYwoO2tJM5Q1FjEiah5oVxE2I8kUagnUPqF3nKfj3k9miwq8px91-RjQAG$ > > > ) > > > > ready for > > > > a blueprint to split out Traffic Portals already, to give you a > > sort > > > of > > > > idea of > > > > what that would look like. I don't want to get too bogged down in > > > what > > > > properties each one will have exactly, since that's best decided > > on a > > > > case-by-case basis and each should have its own blueprint, but > I'm > > > more > > > > looking > > > > for feedback on the concept of splitting apart servers in > general. > > > > > > > > If you do have questions about what properties each is > semi-planned > > > to > > > > have, > > > > though, I can answer it or point you at the current draft of the > > API > > > design > > > > document which contains all those answers. > > > > > > > > > > > > >
