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 >