Implement tk delete functionality.
#313
Conversation
This can be used to tear down a tanka environment. When doing `tk delete`, tanka will generate all manifests for an environment and remove them from kubernetes cluster. This is a safer variant of the one-liner mentioned at #155 Signed-off-by: Milan Plzik <[email protected]>
mplzik
force-pushed
the
mplzik/tanka-delete
branch
from
06629ab to
56191be
Compare
Signed-off-by: Milan Plzik <[email protected]>
In order to avoid cascading objects deletions on server side, we need to sort the object in an order reverse to the one used fpr Apply(). This is best done directly in kube.Delete(), making the rest of tanka codebase agnostic to generated object ordering. Signed-off-by: Milan Plzik <[email protected]>
| for i := 0; i < len(state)/2; i++ { | ||
| t := state[i] | ||
| state[i] = state[len(state)-1-i] | ||
| state[len(state)-1-i] = t | ||
| } |
There was a problem hiding this comment.
While this is recommended in SliceTricks, I just discovered there is sort.Reverse which can be used as long as the type implements sort.Interface.
We could consider whether it's worth moving most of the sort logic from process to manifest, and have manifest.List implement the interface, so that you could sort.Sort(manifest.List{}) and also sort.Reverse
There was a problem hiding this comment.
I had a look at sort.Reverse and it looked like a lot of bureaucracy. If we migrated from sort.SliceStable, it might be a bit more worthwhile, but I'm not sure if it's that intuitive in this case; e.g. the sorting criterion is non-trivial. I'd give it a go in a separate PR, since this is an internal cleanup, not a user-visible feature.
There was a problem hiding this comment.
Yeah thought about doing that. The slice would then know how to sort itself, allowing us to use sort.Stable and sort.Reverse on it
There was a problem hiding this comment.
We can do that, but I agree it's minor internal cleanup
- check `err` for diff - remove DeleteOpts - fix documentation for `--force` Signed-off-by: Milan Plzik <[email protected]>
| for i := 0; i < len(state)/2; i++ { | ||
| t := state[i] | ||
| state[i] = state[len(state)-1-i] | ||
| state[len(state)-1-i] = t | ||
| } |
There was a problem hiding this comment.
Yeah thought about doing that. The slice would then know how to sort itself, allowing us to use sort.Stable and sort.Reverse on it
| for i := 0; i < len(state)/2; i++ { | ||
| t := state[i] | ||
| state[i] = state[len(state)-1-i] | ||
| state[len(state)-1-i] = t | ||
| } |
There was a problem hiding this comment.
We can do that, but I agree it's minor internal cleanup
This can be used to tear down a tanka environment. When doing
tk delete, tanka will generate all manifests for an environment and removethem from kubernetes cluster.
This is a safer variant of the one-liner mentioned at #155