Return a flag in disk GET to denote if deletion is allow

[zephraph]

Currently clients have to replicate this logic to deduce whether a disk can be deleted. It'd easy downstream implementation if we just encoded this into the disk response.

[david-crespo]

I'm ambivalent. Even if you get this on a response, it's only true at the time of the request. If you're using it to determine what the UI should look like, you are still immediately at risk of it becoming wrong. Of course, that is equally true of what we're currently doing — looking at the disk state and applying our own (potentially wrong) copy of the API logic to determine whether it's deletable. So I can see the value here being that we at least eliminate one potential source of error.

Even so, this feels wrong to me, like it's encoding too much frontend logic into the API. The obvious counterpoint: deletability is clearly API logic, it just happens to be highly relevant to the frontend. Surely that relevance is an argument in favor of including it, not against it.

Maybe my bad feeling is more about what happens when you take this reasoning to its logical conclusion: we would end up filling the whole API up with a lot of noise. For disks, we don't just need deleteable, we need attachable and detachable. And on instances we'd need the whole state machine for when stop, start, and delete are allowed (see console logic for this). That seems like too much.

[zephraph]

Fair point.