Location and Origin columns were listed out in my more detailed initial proposal [1]. In there I proposed having either a DeliveryService FK in the Origin table or a new deliveryservice_origin table to support many-to-many. But I think keeping the DS FK in the Origin table is the right thing to do, because we could temporarily allow duplicate origins (as we do today), give everyone a few releases to make sure they've fixed all their existing DSes with duplicate origins, then slap a unique constraint on the Origin fqdn. That would prevent the erroneous config that occurs from having duplicate origins like you described.
- Rawlin [1] https://lists.apache.org/thread.html/ed09765621271250893ae3ac1f5b1e984eae0071eab46057b8264c00@%3Cdev.trafficcontrol.apache.org%3E On Thu, Mar 22, 2018 at 1:31 PM, Eric Friedrich (efriedri) <efrie...@cisco.com> wrote: > >> On Mar 22, 2018, at 12:27 PM, Rawlin Peters <rawlin.pet...@gmail.com> wrote: >> >> This Origin Refactor proposal was probably too much to parse at once. >> Here's a slightly shorter version: >> 1. Split Locations out of the Cachegroup table into their own table > EF> Location is latitude/longitude? > > >> 2. Split Origins out of the Server and Delivery Service tables into >> their own table (Origin would have a FK to DeliveryService, supporting >> a one-to-many relationship between DSes and Origins) > EF> What are the properties of an Origin? > > EF> Also, having a separate origin object might let us prevent for the > messiness that comes when adding the same origin as both a Live DS and a VOD > DS on the same cache (today hosting.config stores both DS’ on disk) > >> >> In order to make the transition smoother, I'd like to try to keep the >> existing Delivery Service and Cachegroup API request/response formats >> in place, but their implementations would change to populate the new >> DB tables. For instance, if I create a DS with the Origin >> http://www.example.com, the DS API backend would now parse that URL >> and create a new row in the Origin table with a foreign key to that >> DS. >> >> For the Cachegroup API, if I create a new Cachegroup with the >> coordinates [1, 2], the backend would then create a new row in the >> Location table using those coordinates (probably name it generically >> using the Cachegroup name), and the cachegroup row would contain a >> foreign key to that Location. >> >> Of course there would also be new API endpoints to CRUD Locations and >> Origins by themselves. >> >> Initially, the current MSO implementation would continue to use >> origins created using the Server table, but we would transition the >> MSO implementation over to using the new Origin table eventually. >> >> Questions/thoughts/concerns about any of this? All feedback is welcome. >> >> Thanks, >> Rawlin >> >> On Mon, Mar 12, 2018 at 1:46 PM, Rawlin Peters <rawlin.pet...@gmail.com> >> wrote: >>> Hey folks, >>> >>> As promised, this email thread will be to discuss how to best >>> associate an Origin Latitude/Longitude with a Delivery Service, >>> primarily so that steering targets can be ordered/sent to the client >>> based upon the location of those targets (i.e. the Origin), a.k.a. >>> Steering Target Geo-Ordering. This is potentially going to be a pretty >>> large change, so all your feedback/questions/concerns are appreciated. >>> >>> Here were a handful of bad ideas I had in order to accomplish this DS >>> Origin Lat/Long association (feel free to skip to PROPOSED SOLUTION >>> below): >>> >>> 1. Reuse the current MSO (multisite origin) backend (i.e. add the >>> origin into the servers table, give it a lat/long from its cachegroup, >>> assign the origin server to the DS) >>> Pros: >>> - reuse of existing db schema, probably wouldn't have to add any new >>> tables/columns >>> Cons: >>> - MSO configuration is already very complex >>> - for the simple case of just wanting to give an Origin a lat/long you >>> have to create a server (of which only a few fields make sense for an >>> Origin), add it to a cachegroup (only name and lat/long make sense, >>> won't use parent relationships, isn't really a "group" of origins), >>> assign it to a server profile (have to create one first, no parameters >>> are needed), and finally assign that Origin server to the delivery >>> service (did I miss anything?) >>> >>> 2. Add Origin lat/long columns to the deliveryservice table >>> Pros: >>> - probably the most straightforward solution for Steering Target >>> Geo-Ordering given that Origin FQDN is currently a DS field. >>> Cons: >>> - doesn't work well with MSO >>> - could be confused with Default Miss Lat/Long >>> - if two different delivery services use colocated origins, the same >>> lat/long needs entered twice >>> - adds yet another column to the crowded deliveryservice table >>> >>> 3. Add origin lat/long parameters to a Delivery Service Profile >>> Pros: >>> - Delivery Services using colocated origins could share the same profile >>> - no DB schema updates needed >>> Cons: >>> - profile parameters lack validation >>> - still doesn't support lat/long for multiple origins associated with a DS >>> >>> 4. Add the lat/long to the steering target itself (i.e. where you >>> choose weight/order, you'd also enter lat/long) >>> Pros: >>> - probably the easiest/quickest solution in terms of development >>> Cons: >>> - only applies lat/long to a steering target >>> - using the same target in multiple Steering DSes means having to keep >>> the lat/long synced between them all >>> - lat/long not easily reused by other areas that may need it in the future >>> >>> >>> >>> PROPOSED SOLUTION: >>> >>> All of those ideas were suboptimal, which is why I think we need to: >>> 1. Split Locations out of the cachegroup table into their own table >>> with the following columns (cachegroup would have a foreign key to >>> Location): >>> - name >>> - latitude >>> - longitude >>> >>> 2. Split Origins out of the server and deliveryservice tables into >>> their own table with the following columns: >>> - fqdn >>> - protocol (http or https) >>> - port (optional, can be inferred from protocol) >>> - location (optional FK to Location table) >>> - deliveryservice FK (if an Origin can only be associated with a >>> single DS. Might need step 3 below for many-to-many) >>> - ip_address (optional, necessary to support `use_ip_address` profile >>> parameter for using the origin's IP address rather than fqdn in >>> parent.config) >>> - ip6_address (optional, necessary because we'd have an ip_address >>> column for the same reasons) >>> - profile (optional, primarily for MSO-specific parameters - rank and >>> weight - but I could be convinced that this is unnecessary) >>> - cachegroup (optional, necessary to maintain primary/secondary >>> relationship between MID_LOC and ORG_LOC cachegroups for MSO) >>> >>> 3. If many-to-many DSes to Origins will still be possible, create a >>> new deliveryservice_origin table to support a many-to-many >>> relationship between DSes and origins >>> - the rank/weight fields for MSO could be added here possibly, maybe >>> other things as well? >>> >>> 4. Consider constraints in the origin and deliveryservice_origin table >>> - must fqdn alone be unique? fqdn, protocol, and port combined? >>> >>> The process for creating a Delivery Service would change in that >>> Origins would have to be created separately and added to the delivery >>> service. However, to aid migration to the new way of doing things, our >>> UIs could keep the "Origin FQDN" field but the API backend would then >>> create a new row in the Origin table and add it to the DS. More >>> Origins could then be added (for MSO purposes) to the DS via a new API >>> endpoint. MSO configuration would change at least in how Origins are >>> assigned to a DS ("server assignments" would then just be for >>> EDGE-type servers). >>> >>> Cachegroup creation also changes in that Locations need to be created >>> before associating them to a Cachegroup. However, our UIs could also >>> stay the same with the backend API updated to create a Location from >>> the Cachegroup request and tie it to the Cachegroup. >>> >>> >>> >>> I know there are a lot of backend and frontend implications with these >>> changes that would still need to be worked out, but in general does >>> this proposal sound good? Questions/concerns/feedback welcome and >>> appreciated! >>> >>> - Rawlin >
