tk diff/prune not respecting spec.namespace ?

[strowi]

Hi,

i noticed this rather unexpected behaviour with tk diff (tk prune same issue):

1. deploying a resource in one namespace (e.g. secret)
2. copying this resource it to another namespace (in our case with kubernetes-replicator)
3. running tk diff as below it
4. shows removal of the resouce in the other namespace, not defined in spec.namespace

~> tk --version
2024/08/08 22:56:45 tk version 0.28.0

~> tk env add --inject-labels --diff-strategy native --context-name cluster --namespace testing environments/test
~> cat > environments/test/main.jsonnet << EOF
{
  apiVersion: 'v1',
  kind: 'Secret',
  type: 'Opaque',
  metadata: {
    name: 'test',
  },
  data: {
    foo: 'YmFyCg=='
  },
}
EOF

~> kubectl create namespace testing
~> tk apply environments/test
...

~> kubectl get -n testing secret test -o json \
  |jq 'del(.metadata.annotations, .metadata.creationTimestamp, .metadata.resourceVersion, .metadata.uid)' \
  | jq '.metadata.namespace = "default"' \
  | kubectl apply -f - 

# diff wants to remove the secret in namespace "default"
~> tk diff --diff-strategy validate --with-prune --exit-zero --log-level warn environments/test

diff -u -N /tmp/diff4225968230/LIVE-v1.Secret.default.test /tmp/diff4225968230/MERGED-v1.Secret.default.test
--- /tmp/diff4225968230/LIVE-v1.Secret.default.test     2024-08-08 22:55:01.530504804 +0200
+++ /tmp/diff4225968230/MERGED-v1.Secret.default.test   2024-08-08 22:55:01.530504804 +0200
@@ -1,34 +0,0 @@
...

Looks like it is not respecting the spec.namespace when the environment label on resources outside that namespace?

Is this intentional? If so i think its very un-obvious, altough this might be an edge-case (we're replicating some configs into review-app namespaces).

regards,
strowi

Acceptance criteria

• Given an environment
  • When tk prune is called on it
    • Then a warning should be shown that informs the user that pruning might also affect resources outside of the primary namespace of that environment

[zerok]

Hey 🙂

Correct, prune operates exclusively on that label to look for resources which was somehow implicit in the original PR: #251 . I'm guessing that the main reason for this is that Tanka supports resources inside of an environment not to be limited to a single namespace and since the jsonnet entry might already be gone, the label is the only reference left to check.

That being said, I agree that this information should be more visible. What do you think? Should the prune command perhaps always log a warning telling users to check if these are really the resources they want to prune?

[strowi]

Hi ;),

ahh yes i read:

This file configures environment properties such as cluster connection (spec.apiServer), default namespace (spec.namespace), etc.

And somehow thought, if 'namespace' is defined, that would also limit operations to this namespace. (As opposed to NOT define it).

In our pipeline we run a tk diff before templating + deploying with shopify/krane so it is mostly a visual problem for the reviewer. to ignore.

I think a warning would be nice though. 👍

[zerok]

I've set some acceptance criteria for the person who will work on this. Are they ok for you? 🙂

[strowi]

Yes, thx! ;)