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" <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > 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 <[email protected]> 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 > > > > > > > > > > > > > > >
