Re: Immutable DS CDN - resolving Riak/Postgres data coherency

[Jeremy Mitchell]

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  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 
> 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  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  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
> > > > 
> > > >
> > > > 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
> > > >
> > >
> >
>

Re: Immutable DS CDN - resolving Riak/Postgres data coherency

[Nir Sopher]

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 
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  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  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
> > > 
> > >
> > > 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
> > >
> >
>

Re: Immutable DS CDN - resolving Riak/Postgres data coherency

[Dave Neuman]

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  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
> 
>
> 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
>