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" <mitchell...@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 <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