cli-utils: Bug: implicit namespace resolution in apply-time-mutation causes dependency sorting failure

Resources:

  • namespace test
  • pod-a
    • implicit dep: namespace test
  • pob-b
    • implicit dep: namespace test
    • explicit dep: apply-time mutation with pod-a as source

Output (from kpt using cli-utils master):

$ kpt live apply
namespace/test unchanged
1 resource(s) applied. 0 created, 1 unchanged, 0 configured, 0 failed
pod/pod-a created
pod/pod-b apply failed: failed to mutate "test_pod-b__Pod" with "ApplyTimeMutator": failed to read field ($.status.podIP) from source resource (/namespaces/test/Pod/pod-a): expected 1 match, but found 0)
2 resource(s) applied. 1 created, 0 unchanged, 0 configured, 1 failed
error: 1 resources failed

Problem:

  • pod-b didn’t get sorted into a 3rd ApplyTask. So when it applied, pod-a wasn’t reconciled yet.

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Comments: 17 (13 by maintainers)

Most upvoted comments

Today, all the namespaced objects sent from Config Sync to cli-utils have the metadata.namespace field explicitly set. Is it reasonable to expect this from other users of cli-utils ?

cli-utils already requires this.

This problem here is with apply-time-mutation annotations which were initially designed to support inferring the namespace of dependencies from the namespace of the dependent object. However, it does look like disabling implicit namespace resolution for apply-time-mutation is the easier path forward, and would align with the requirement on the objects themselves.