I’m also OK with making xml_id immutable. I’d like us to look at having less restrictions in naming of DS Regexs rather than more. We have many use cases where the existing DS Regex is not sufficient and I think fixing it to xmlID would only worsen the problem.
A specific case: xml_id is unique per Traffic Ops, but ds regex is only unique per CDN. Today I can have tr.sports.cdn1.com<http://sports.cdn1.com> and tr.sports.cdn2.com<http://tr.sports.cdn2.com>. Would I be able to do this if we fixed the DS names to xml_ids? —Eric On Apr 28, 2017, at 3:48 PM, Dave Neuman <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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<http://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<http://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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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<http://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]<mailto:[email protected]>
