I think I can get on board with not allowing a user to change the CDN.  If
you want to change the CDN you need to delete your DS and re-create it or
create a new DS with a different XML_ID and a regex that matches the first
DS.

We have gone back and forth several times on deleting the keys from riak
when you delete a DS.  Each time we decide not to make the change for one
reason or another.  The worry is that if you delete a DS and then decide
that it was a mistake you now have to generate a whole new certificate
which could cost real money.  I am not sure that use-case is common enough
to warrant us not deleting the certificates for a DS.  For now I am +1 on
deleting the certificates when a DS is deleted.

Thanks,
Dave

On Tue, Feb 13, 2018 at 12:14 PM, Nir Sopher <n...@qwilt.com> wrote:

>  Hi,
>
> I created a delivery service and later on realized it is in the wrong CDN.
> I then changed the CDN.
> The ssl-keys record in the riak kept referring to the old CDN, even if I
> generated new certificates. Traffic router was therefore unable to pull the
> certificate.
>
> See issue 1847
> <https://github.com/apache/incubator-trafficcontrol/issues/1847>
>
> A fix to this issue can be done by changing the code so the record in the
> Riak is updated along with the DS update.
> However, this does not really make sense - if the CDN has changed, the
> domain usually changes as well and the certificate is no longer valid.
>
> Therefore, I suggest to entirely block DS CDN change [see
> https://github.com/apache/incubator-trafficcontrol/pull/1872]
> .
> Additionally, I added a PR for ssl-keys deletion up-on DS deletion, so
> deleting the DS and recreating it would not cause similar issues.
>
> Would appreciate community input for other alternatives.
>
> Thanks,
> Nir
>

Reply via email to