Re: Proposed changes to xml_id on a delivery service (from the API perspective)

["Eric Friedrich (efriedri)" <ef...@cisco.com>]

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 <ne...@apache.org>> 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 <mi...@gmail.com>>
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 <ne...@apache.org>> 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 <or...@qwilt.com>> 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) <
zhilhuan@cisco.com<ma...@cisco.com>
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" <mi...@apache.org>>
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
|
orif@qwilt.com<ma...@qwilt.com>