I believe we should allow users to create a host regex at create time if they want to, otherwise we will create it for them. This reduces issues with DNSSEC keys, SSL keys, etc. We also need to be cognizant that if the host regex is edited, the DNSSEC keys and SSL keys will need to be updated as well.
On Fri, Apr 28, 2017 at 12:37 PM, Jeremy Mitchell <[email protected]> wrote: > Great feedback. It sounds like people are OK with making xml_id immutable > on a delivery service... but not so much about making the host header regex > at position 0 immutable (the regex that requires this format - > .*\xml-id\..*). > > Just to revisit: > > You create a delivery service with xml_id=foo-bar and by default you get a > host header regex in this format at position 0 - .*\xml-id\..* so you end > up with URL=edge|tr.foo-bar.cdn.domain.com > > Maybe you're happy with that and life is good. > > Maybe you decide you want your URL to be edge| > tr.something-else.cdn.domain.com instead.....so you need the ability to > edit the host header regex at position 0 to .*\something-else\..* > > What about this? You can attach Static DNS entries to a delivery service. > Can Static DNS entries be used to accomplish this use case while leaving > .*\xml-id\..* alone? (Elsloo keyed me into that possibility) > > Jeremy > > > On Fri, Apr 28, 2017 at 9:44 AM, Dave Neuman <[email protected]> wrote: > > > I don't think we should be forcing users into using their xml_id as the > > host_regex used to create the delivery URL. I think we can offer to > create > > it for them, but we should also let users have the ability to define what > > their regex needs to be when they create their delivery service. We have > > instances in our environment where the host regex does not match the > xml_id > > a delivery service and I don't think we should take that functionality > > away. > > You are correct, changing an xml_id or a host_regex could have unintended > > consequences in the system, but I agree with Ori that not letting users > > change it can cause other problems. I think we should allow users to > > change it but maybe we need to figure out a way to only allow "super > > special advanced" users to do it. > > > > --Dave > > > > On Thu, Apr 27, 2017 at 6:40 AM, Ori Finkelman <[email protected]> wrote: > > > > > Hi Jeremy, > > > > > > I would like to refer to bullet 2 in your proposal. > > > Coupling between the xml_id and the host regexp, making the host regexp > > > immutable may create undesired limitations. > > > For example, if, for any reason, the content provider has to change the > > > host regexp, she will have to create a new DS. This limitation prevents > > > long term reports on DS volume, running long term analytics and other > > > operations that you may want to run over long periods of time. > > > In general, the host regexp is an attribute of the DS and therefore, > > unlike > > > the id which should be immutable, I think it should be mutable, like > any > > > other attribute. > > > > > > A side issue is that we would like to suggest promoting TC-55 > > > <https://issues.apache.org/jira/browse/TC-55> > > > <https://issues.apache.org/jira/browse/TC-55>in order to allow DS to > be > > > matched by a combination of host regexp and path regexp. TC-55 > > > <https://issues.apache.org/jira/browse/TC-55> requires it should be > > > allowed > > > to have the same host regexp for different DS, using the path regexp as > > > differentiator. This option has the benefit of using a single > certificate > > > for multiple DSs, it also reduces the complexity of delegating traffic > > > between CDNs, like the use cases of CDNi and Open Caching. > > > Unless I misunderstand the proposal, binding the first host regexp with > > the > > > xml_id makes it impossible to have the same host for different DS, as > > > required by TC-55 <https://issues.apache.org/jira/browse/TC-55>. > > > > > > Thanks, > > > Ori > > > > > > On Thu, Apr 27, 2017 at 6:37 AM, Zhilin Huang (zhilhuan) < > > > [email protected] > > > > wrote: > > > > > > > Hi Jeremy, > > > > > > > > I like the idea that make xml_id and ds.regex at position 0 > immutable. > > > > Actually we have suffered some issues on HTTPs delivery services, > and I > > > had > > > > ever created issue TC-187 with PR #360. > > > > > > > > Besides ds.regex at position 0, the ds.regex at other position of > type > > > > HOST_REGEXP is not working for HTTPs. I think the reason is SAN is no > > > > supported in currently implementation in “generate_ssl_keys”. Do we > > have > > > > any plan to support multiple subdomain for HTTPs? > > > > > > > > If we do plan to support SAN, I think we need also consider the > > > > modification for ds.regex at position other than 0. > > > > > > > > > > > > Thanks, > > > > Zhilin > > > > > > > > > > > > > > > > On 4/27/17, 1:41 AM, "Jeremy Mitchell" <[email protected]> > wrote: > > > > > > > > As we port functionality from the existing TO UI to the TO API, I > > am > > > > always > > > > looking for ways to simplify things. I can't lie. I like simple. > > > Plus, > > > > simple == less user error. I would like to discuss the > possibility > > of > > > > making changes to how xml_id works (at least thru the API). > Here's > > > > what I > > > > propose. Feel free to poke holes in it. > > > > > > > > 1. make delivery service xml_id immutable. If you create a > delivery > > > > service > > > > with xml_id = foo-bar, that is it. no changing it....ever... > > > > 2. the ds.regex in position 0 must always be of type HOST_REGEXP > > and > > > in > > > > this format - .*\.xml_id\..* - this can be created for you when a > > > > delivery > > > > service is created and again, no changing this...ever...plus you > > > don't > > > > have > > > > to fumble around with regex... > > > > > > > > I'm not 100% sure of all the problems associated with changing > > xml_id > > > > on a > > > > ds but I think there are a few. It can be done but I think you > need > > > to > > > > know > > > > what you're doing. And with self service coming down the pike? > > pipe? > > > I > > > > would be afraid to let users change xml_id... > > > > > > > > Regarding the ds.regex in position 0, this I know: > > > > > > > > A - it has to be in the format .*\.xml_id\..* (otherwise traffic > > > router > > > > barfs?) > > > > B - it drives the dnssec keys for the ds (if the ds is in a > dnssec > > > > enabled > > > > cdn) so changing it requires a deletion of existing dnssec keys > and > > > > creation of new ones > > > > C - if you change it, you better generate new ssl certs if your > ds > > is > > > > https > > > > > > > > A and B can be done programattically but C cannot be. > > > > > > > > So back to my point. Why not simplify the whole process and make > > > > ds.xml_id > > > > and ds.regex at position 0 immutable and reduce the chance of > users > > > > shooting themself in the foot? > > > > > > > > One drawback I can think of: If xml_id=foo-bar, they are locked > > into > > > > edge.foo-bar.cdn.domain.com which seems like an acceptable > > tradeoff > > > > to me > > > > as they can always add cnames if they don't like that URL. > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > -- > > > > > > *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 > | > > > [email protected] > > > > > >
