When multiple users working on the same environment, one user may edit (or delete) other’s stack by mistake.
I wonder if it is possible to lock or make a app stack read only when finished deploying a stack.
1 Like
Currently, there is no way to lock or make a read only stack.
I could see some issues with this concept as it would be another level of membership (on top of access control level, environment level) and something else to maintain.
I don’t see this as anything complex. In my case all I’d like is a ‘read-only’ marker on a stack to stop accidental deletion. I know that if we do Rancher properly then accidentally deleting a stack isn’t the end of the world but it does still cause disruption.
This has already happened twice at our site and is likely to happen again. There’s only so many times I can hand out punitive beatings 
May be simply add a switcher when we want to mark one stack read-only just turn it on, then others must switch off explicitly in order to modify it.
After you make it read only, who has the power to make it “editable” again? We would need to have that ability to edit (stop/start/delete/etc) again.
If you want to specify that User A who made it read only is the only one with that power, then that’s an additional level of permissions that Rancher would need to add.
If we allowed anyone to make it editable again, that doesn’t prevent the users who keep accidentally deleting your stacks from deleting it. There is a confirmation page for deleting the stack, so it’s clear that they are just saying “Yes”, even if they shouldn’t’ be. 
I don’t think this is a bad idea for some of the higher-level resources (maybe Stack, Environment, and Host).
It would just be the digital equivalent of the write protect hole on a floppy (or for the young people, the little switch on the side of SD cards that makes your camera not want to take pictures). Sure you can cover it with tape, but you hopefully think twice before doing it (and can’t just ignore it like a delete confirm).
If we were to implement this it would be like “protect” and “unprotect” actions on the resource. Any user who otherwise has access can call them, but edit and other actions are disabled when protected.
I’ve added an enhancement request for Vince’s suggestion of how Rancher could handle it. If there is enough user interest, we could prioritize it.
1 Like