Delete Revisions on RevisionTemplate delete about serving

[evankanderson]

If you want to do this, it should be as simple as setting metadata.ownerReference on the Revisions pointing to the Archetype.

We should think about whether we want to do this (and if so, how), since some of the referenced revisions might still be referenced by a Service. Perhaps the Service should also set metadata.ownerReference on the Revision when it starts directing traffic to that Revision (and unset it when it stops sending traffic to the Revision)? If so, that might provide a handy way for the UI to track back-references to Services from the Revision (which was a UX request).

@qelo @jurekPapiorek for the UX suggestion.

[jurekPapiorek]

+1 to the cascading delete of Revisions by RevisionTemplate. When a Service still references one of the Revisions, the delete operation should fail. Will setting metadata.ownerReference on the Revision by the Service have this consequence?

[xoebus]

I've got a prototype of this at #115.

The relationship between revision template and revision is working such that when the template is deleted the revisions are also removed. I experimented with adding a link between services and revisions too but I can't get it to work due to:

1. Only one controller is allowed to be the owner of a resource. If I make both the service and the revision controller owners then I get this error.

2. There doesn't seem to be a way to error if you still have dependent children. This document only mentions variations of cascading deletes and orphaning.

Both of these might be because I'm new to development against the Kubernetes API. Does anyone know if there's a way around them?

[xoebus]

Setting Controller to false on the OwnerReference allows two owners and will cause revisions to not be deleted if they're routable from a Route. I'm looking into the webhook validations to see whether or not we can stop the deletion with an error there.

[xoebus]

I need to step back and work on something else for a while but I don't have permission to un-assign myself from this issue. This should be considered unassigned if anyone else wants to pick it up.

[mattmoor]

thanks for your help @xoebus :)

[mattmoor]

I think that given the 1:N relationships we've landed on, that what we have in place now is adequate for this.