Immutable DS CDN - resolving Riak/Postgres data coherency

[Nir Sopher <ni...@qwilt.com>]

 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

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

[Nir Sopher <ni...@qwilt.com>]

Jeremy,

As I see it, you are parctically pointing at the problem of DS
configuration mixture: "content delivery" fields (e.g. cache url) and
"operational" fields (e.g. "active", "geo limit", "cdn" and even ssl keys)
sitting in the same table subject to same api.
I believe a DS should be assigned to (multiple) CDNs as an operational
action, and not as part of the DS creation ( that should mainly deal with
the content delivery fields). Followed by ssl keys generation.

Restructuring the DB to make the separation I'm suggesting is a project for
itself.

What would you say if for now, in order to protect the user and system, a
DS with ssl keys generated, cannot change cdn?

Nit

On Feb 19, 2018 7:10 PM, "Jeremy Mitchell" <mi...@gmail.com> wrote:

> 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 <ni...@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 <sm...@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 <ne...@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 <ni...@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
> > > > >
> > > >
> > >
> >
>

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

[Jeremy Mitchell <mi...@gmail.com>]

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 <ni...@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 <sm...@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 <ne...@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 <ni...@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
> > > >
> > >
> >
>

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

[Nir Sopher <ni...@qwilt.com>]

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 <sm...@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 <ne...@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 <ni...@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
> > >
> >
>

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

[Steve Malenfant <sm...@gmail.com>]

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 <ne...@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 <ni...@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
> >
>

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

[Dave Neuman <ne...@apache.org>]

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 <ni...@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
>