I'm not too concerned with existing deployments -- if an existing TO has this config, it's exposed to this (what I would call) bug and their system will have the negative impacts this causes.
+1 on the 'sufficiently advanced SQL query'. I could be +1 on using that to drive config. -1 on adding a global option to 'ignore all duplicate origins' -1 on adding a unique constraint for origins as a blanket rule to delivery services Thanks, Mark On Mon, Dec 17, 2018 at 1:11 PM Rawlin Peters <[email protected]> wrote: > That is an interesting idea...detect at TO startup whether or not > there are duplicate origins and operate in a "prevent duplicate > origins" state if no duplicates are found or "prevent conflicting DS > topologies" state if duplicates are found? So once operators have > replaced all the duplicate origins with CNAMEs, TO will essentially > operate in a "prohibit all duplicate origins" state. That would > probably make for a simpler transition, but I'd want to remove that > logic in a following release that strictly prohibits duplicate origins > (assuming that the community agrees we should prohibit duplicate > origins altogether). > > As for DB constraints vs UI, I was thinking those DS-type constraints > I pointed out would live in the API. It would basically be added > validation in the deliveryservices POST/PUT endpoint that checks the > DB for existing DSes that conflict with the requested DS. > > - Rawlin > > On Mon, Dec 17, 2018 at 12:35 PM Gray, Jonathan > <[email protected]> wrote: > > > > These kinds of conditions should be detectable with a sufficiently > advanced SQL query. Is it possible to add the constraint if it passes and > emit a warning during TO startup otherwise? That would let you know the > condition exists at startup but not getting in your way and keep you out of > trouble once you've cleaned up. We made a mistake early on, but this would > acknowledge it was bad and encourage it to be fixed at the speed of > operations teams. Also this puts the constraint in the database rather > than the UI which is really where the contention is for usability. > > > > Jonathan G > > > > > > On 12/17/18, 11:38 AM, "Rawlin Peters" <[email protected]> wrote: > > > > We occasionally discuss this issue but haven't tackled it yet. I > think > > the main issue is just that duplicate origins have been allowed since > > the beginning, and now everyone's Traffic Ops could be littered with > > duplicate origins. Also, depending on the config of the duplicate > > delivery services, the origins might not be in conflict at all (if > > they don't have different topology constraints). I would love for us > > to just add a uniqueness constraint, but there would need to be a > fair > > amount of warning to the community before doing so and might > > invalidate a significant amount of valid use cases. Operators would > > need time to make DNS CNAME records for the duplicate origins and > > update their DSes to use the different CNAMEs. > > > > I think as a good first step to eliminating the use of duplicate > > origins altogether, we should identify which "topology constraints" > > actually cause conflicting config when used with duplicate origins > and > > prevent creating DSes with duplicate origins _if it would cause a > > conflict with an existing DS that uses the same origin_. > > > > For instance, I believe an HTTP and DNS-type DS can live happily > > side-by-side using the same origin (probably need different > > routing_names?), but scenarios like HTTP and HTTP_LIVE, or DNS and > > HTTP_NO_CACHE sharing the same origin will cause conflicts for sure. > > So maybe we can start by making sure the DS types "match" when using > > the same origin: > > HTTP + DNS: possibly good, if they have different routing names? > > HTTP_LIVE + HTTP_LIVE_NATNL: bad > > HTTP_NO_CACHE + [any other type]: bad > > HTTP_LIVE + HTTP: bad > > etc. > > > > There are most likely other conflict scenarios that don't involve the > > DS types, but I think this would be a good start. In the future with > > Delivery Service Topologies (aka Flexible Cachegroups aka Bring Your > > Own Topology), we might be able to prohibit assigning a DS to a > > Topology if the DS's origin is already used by another DS in a > > different Topology. > > > > - Rawlin > > > > On Mon, Dec 17, 2018 at 10:52 AM Fieck, Brennan > > <[email protected]> wrote: > > > > > > As some of you may be aware, `parent.config` files generated by > Traffic Ops can vary wildly when an origin is assigned to multiple Delivery > Services. This results in undefined behavior. I'm told that the conflict > only happens when two Delivery Services with different "topology > requirements" use the same origin, whatever that means (content routing > type?). Regardless, the issue should be addressed. The obvious solution is > to put in place a database constraint that prevents an origin from being > assigned to more that one Delivery Service with API checks in place that > would provide helpful error messages when an attempt is made to violate the > constraint. However, would that mess with things like Multi-Site Origin? Or > is it just not viable for some other reason? If it is a good solution, I'm > prepared to work on a fix that utilizes it. > > > > >
