It might be possible to create an MSO delivery service with an `orgServerFqdn` that doesn't match the [hostname + domain name] of a server it's assigned to, but I'm not sure it would work as expected. In a bug I recently fixed, I found a bit of code [1] that makes me think that scenario would lead to a bad parent.config. The issue [2] was that having a trailing slash in `orgServerFqdn` led to an empty parent field in parent.config (because before the fix, TO didn't find an origin Server that matched the `orgServerFqdn` of the MSO delivery service.
- Rawlin [1] https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/API/Configs/ApacheTrafficServer.pm#L2407 [2] https://github.com/apache/incubator-trafficcontrol/issues/2062 On Fri, Jun 1, 2018 at 6:57 AM, Vijay Anand <vijayanand.jayaman...@gmail.com> wrote: > Hi Rawlin, > > I thought, we can always create an origin server group (for MSO) which wont > necessarily contain the origin server which we configure while creating a > DS and that is the logic behind adding this conflict. " MSO = true and > go_direct = true". IF that is not the case, we dont need this conflict. > > Thanks, > Vijayanand S > > > > On Thu, May 31, 2018 at 9:08 PM, Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > >> When configuring MSO currently (note this will change soon once I get >> the MSO implementation refactored to use Origins rather than Servers), >> you have to set `orgServerFqdn` to an FQDN that matches at least one >> Server with a combined (hostname, domain_name) matching that >> `orgServerFqdn` used in the Delivery Service. That Delivery Service is >> then assigned to that Server and any other Server acting as an origin. >> So the request flow for an MSO Delivery Service should still flow to >> both the origin Server matching the DS's `orgServerFqdn` and any other >> origin Server that is assigned that DS. >> >> - Rawlin >> >> On Thu, May 31, 2018 at 9:12 AM, Vijay Anand >> <vijayanand.jayaman...@gmail.com> wrote: >> > Hi Rawlin, >> > >> > Adding CNAME Alias for sharing an origin to resolve the conflicts looks >> > good and it should work. So that , if a conflict is detected, the >> operator >> > has to setup up CNAME alias for that particular origin. >> > >> > For MSO, when some one configures an MSO, he would probably meant to use >> an >> > origin server(s) which is different from Delivery service's orgin_fqdn. >> So >> > when go_direct is true and mid cache is offline, Edge will go to Delivery >> > service configured orgin_fqdn which is not an intented behaviour if some >> > one configured MSO. >> > >> > Thanks, >> > Vijayanand S >> > >> > On Thu, May 31, 2018 at 3:17 AM, Rawlin Peters <rawlin.pet...@gmail.com> >> > wrote: >> > >> >> Hi Vijayanand S, >> >> >> >> Generally we've found it's bad practice to have multiple delivery >> >> services sharing the same origin due to the conflicts in configuration >> >> on the caches serving those delivery services like you mentioned. But >> >> this can be fixed by setting up CNAME DNS records for the shared >> >> origin and using a distinct CNAME in each delivery service. In fact >> >> I've discussed duplicate origins here fairly recently due to my effort >> >> to refactor the Origin implementation, and the tentative plan was to >> >> phase-in a uniqueness constraint on Origin FQDN so that there will be >> >> no possibility of conflicts that we experience today with duplicate >> >> Origin FQDNs. >> >> >> >> Would that fix your issue? >> >> >> >> The `go_direct` option isn't hardcoded per se but is determined by the >> >> delivery service type in order to bypass or use the mid tier. So for >> >> HTTP_NO_CACHE, HTTP_LIVE, and DNS_LIVE, we bypass the mid tier because >> >> that's what those types are for. Why do you want to bypass the mid >> >> tier for MSO? >> >> >> >> - Rawlin >> >> >> >> On Wed, May 30, 2018 at 8:58 AM, Vijay Anand >> >> <vijayanand.jayaman...@gmail.com> wrote: >> >> > Hi All, >> >> > >> >> > Planning for a PR on making parent.config's go_direct directive >> >> > configurable via Delivery service. Right now, go_direct is >> >> > being hard coded. >> >> > >> >> > Given below is a brief write up on the implementing the same. >> >> > >> >> > Assumption: >> >> > All DS-es sharing an origin server should have same value for >> go_direct. >> >> > >> >> > Implementation: >> >> > Add a new column 'go_direct' in Deliveryservice table. Its value >> defaults >> >> > to False. >> >> > Delivery service UI (Traffic Ops) and API will be enhanced to support >> >> this >> >> > new column. >> >> > >> >> > Conflicts: >> >> > 1. DS Type HTTP_NO_CACHE and go direct False >> >> > 2. DS Type HTTP_LIVE and go direct False >> >> > 3. DS Type DNS_LIVE and go direct False >> >> > 4. MSO = true and go_direct = true >> >> > >> >> > >> >> > When we have more than 2 DS-es sharing same origin, then updating one >> >> > particular DS's go_direct value will result >> >> > in conflict, since all DS-es sharing an origin should have same value >> for >> >> > go_direct. >> >> > >> >> > Such conflicts should be resolved by deleting and recreating these >> DS-es >> >> > with new value for go_direct. >> >> > >> >> > This method of deleting and recreating DS-es is preferred over >> updating >> >> all >> >> > the affected DS-es implicitly. >> >> > >> >> > would like your comments on this. >> >> > >> >> > Thanks, >> >> > Vijayanand S >> >> >>
