Deleting an owner should implicitly end their ownerships about marquez HOT 5 CLOSED

@ashulmanWeWork since you're taking over the ownership POC branch, this will be a good change to get in also. This functionality can be part of your ownership PR or in a separate, self-contained PR (which comes after the larger ownership PR).

from marquez.

This is a useful case to consider. Question here - we should probably require every job to have an owner, since ownerless jobs are a scary thing in terms of resource accountability. However, upon deleting the owner, we'd need to then re-assign the job.

Perhaps we can do a lookup and find the team that the owner belongs to and update the job assignment?

from marquez.

Good question -- team name could be baked into the owner name itself, so that can enable notifications to go to the owning team once a job becomes unowned. Alternatively owner deletion could be blocked until the owner's jobs have been re-assigned. IMO, requiring this is a bit of friction which could cause phantom owners to hang around in the system because of the work involved to delete them.

My preference is for allowing jobs to become unowned which then makes it possible to alert on this condition and take action (alert the last owning team, auto-disable the job, etc). That's just one opinion though, not saying that's how we must do it.

@wslulciuc @julienledem thoughts?

from marquez.

I really like your last suggestion, which would be allow for empty ownerships, but only in the case that the job status is 'disabled'. Is there an elegant way to enforce this invariant at the database layer? Or would it have to be at the application level?

from marquez.

Per the latest conversation, owner endpoint is deprioritized. Closing for now.

from marquez.