First, I'm +100 on doing a riak clean-up on DS delete but not a partial
cleanup (just latest) but a full cleanup (ALL SSL keys (if applicable), ALL
url sig keys (if applicable), ALL URI signing keys (if applicable)).
Otherwise, when a DS gets created down the road with that same xml-id,
problems may arise.

As far as making the CDN immutable...there has been some discussion around
mapping a tenant to one or more CDNs. This is because of self-service. When
a SS user is creating a DS, is it fair to ask them to choose a CDN? What if
you have 10 CDNs defined? They will have no idea what CDN to choose.
Therefore, it makes more sense to ask them to choose a tenant for their DS.
Tenants in most cases will have a one-to-one mapping to CDN so the CDN will
be selected for them. So, if we make CDN immutable, that means tenant is
now immutable...

Plus, let's face it, mistakes happen. It would suck to create a DS and get
it all setup only to discover you selected the wrong CDN and have to start
over. I think we should explore what it would take to make the system
handle CDN changes more gracefully.

Jeremy



On Wed, Feb 14, 2018 at 8:22 AM, Nir Sopher <n...@qwilt.com> wrote:

> See WIP PR:
> https://github.com/apache/incubator-trafficcontrol/pull/1868/files
> Deleting only the latest
>
> On Wed, Feb 14, 2018 at 4:56 PM, Steve Malenfant <smalenf...@gmail.com>
> wrote:
>
> > Would deleting the certificate only remove the "latest" copy/alias? The
> > certificate and keys should still be retrievable manually.  Yes/No?
> >
> > On Tue, Feb 13, 2018 at 5:40 PM, Dave Neuman <neu...@apache.org> wrote:
> >
> > > 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