I agree, it would be great to drop the profile column from the deliveryservice table (and add domain_name to cdn table). In my mind, a profile is really a "server profile" and intended for servers (caches). In addition, by allowing users to select a profile for a deliveryservice, we introduce the possibility of human-error (they select the wrong CCR profile) which can cause issues for the CDN.
On Mon, Dec 26, 2016 at 9:43 AM, Mark Torluemke <[email protected]> wrote: > > On Mon, Dec 26, 2016 at 9:20 AM, Jan van Doorn <[email protected]> wrote: > >> > or its own table entirely, with a link to the 'cdn' table. >> >> Do you think we should consider supporting multiple domains per CDN in >> the future? Or is there another use case? >> >> > That's the use case. I'd love to hear folks from the community weigh in, > as it's been a topic for discussion many times, but we haven't had an > explicit request for it. > > >> Rgds, >> JvD >> >> > On Dec 26, 2016, at 09:13, Mark Torluemke <[email protected]> >> wrote: >> > >> > Agree, I also believe the CCR profile <> deliveryservice mapping is >> superfluous, now that there is a link from cdn <> deliveryservice. This was >> discussed when the 'cdn' table was being implemented, but perhaps too late >> into the implementation phase. Further, I also agree that the domain_name >> parameter should be moved to the 'cdn' table, or its own table entirely, >> with a link to the 'cdn' table. >> > >> > On Mon, Dec 26, 2016 at 8:14 AM, Jan van Doorn <[email protected] >> <mailto:[email protected]>> wrote: >> > Looking at the ATS 6.2 support for TO which requires a deliveryservice >> to profile mapping, and was wondering why we still have the profile column >> (CCR Profile) in deliveryservice? >> > >> > At first glance it seems to be used for the domain_name parameter only >> (?), and that could (should?) be moved to the cdn table? Not sure if this >> was considered when the cdn table was added and decided against for a good >> reason? >> > >> > Cheers, >> > JvD >> > >> > >> >> >
