这是一个BUG报告还是功能请求?
取消注解其中一个,并单独放在一行:
/kind bug
/kind feature
发生了什么?Namespace
有两个finalizers字段:Namespace.ObjectMeta.finalizers
和Namespace.Spec.finalizers
。NamespacedResourcesDeleter
使用NamespaceSpec.finalizers
,而ObjectMeta.finalizers
似乎未被使用/无效(如果我错了,请纠正我)。
你期望发生什么?NamespacedResourcesDeleter
应该使用ObjectMeta.finalizers
,或者如果有技术原因不这样做,应该记录如何以及为什么这些字段不同。此外,如果ObjectMeta.finalizers
字段对于命名空间完全未被使用(不确定是否如此),也许API应该拒绝设置该字段的命名空间创建请求。
TL;DR:我错误地将finalizer放在了命名空间元数据中,而不是命名空间规范中。这应该是支持的,显然通过文档/命名是错误的,或者是无效的请求。
9条答案
按热度按时间rnmwe5a21#
/sig api-machinery
yruzcnhs2#
你好,@khogeland
ObjectMeta.finalizers
用于通用用途,这些终结器将由API服务器内部的通用存储逻辑和垃圾回收机制进行处理。至于NamespaceSpec.finalizers
,它是专门为命名空间控制器设计的,该控制器位于另一个组件中。如您所见,它们由单独的控制器处理,因此将这些终结器合并到一个公共字段中是有疑问的。😃据我了解,这并不是一个真正的BUG。dz6r00yl3#
/cc @caesarxuchao
oug3syen4#
我错误地将终结器放在了命名空间元数据中,而不是命名空间规范中。这应该是支持的,显然通过文档/命名是错误的,或者不是一个有效的请求。
我们无法加强验证,因为那将是不向后兼容的。
我们可以更新命名空间注册表以尊重metadata.finalizer。
eimct9ow5#
我们不能收紧验证,因为这会导致向后不兼容。
也许一个使用棘轮验证的用例:#64907?
/cc @liggitt
lymgl2op6#
我们不能收紧验证,因为那样会导致向后不兼容。
也许一个使用棘轮验证的用例:#64907?
不,两个API字段都有意义,可以很好地使用:
metadata.finalizers
可以像其他任何对象一样填充,并以一致的方式处理。我们不会破坏这一点。spec.finalizers
对于命名空间(/finalize
子资源)有特殊的访问模式,我们也不会破坏这一点。我认为这里的行动项目是:
metadata.finalizers
填充与垃圾回收相关的终结器spec.finalizers
字段的文档,以澄清它与metadata.finalizers
之间的区别以及何时应该使用每个字段。mklgxw1f7#
问题在90天不活跃后过期。
使用
/remove-lifecycle stale
将问题标记为新鲜。过期的问题在30天不活跃后开始腐烂并最终关闭。
如果现在可以安全地关闭此问题,请使用
/close
进行操作。向 sig-testing, kubernetes/test-infra 和/或 fejta 发送反馈。
生命周期:过期
dba5bblo8#
过期的问题在30天不活动后会变质。
使用
/remove-lifecycle rotten
将问题标记为新鲜。腐烂的问题在额外的30天不活动后关闭。
如果现在可以安全地关闭此问题,请使用
/close
进行操作。将反馈发送给sig-testing, kubernetes/test-infra 和/或 fejta 。
生命周期腐烂
mf98qq949#
刚遇到这个问题——实际上,我认为当前的状态是一个大问题,但由于API版本更改规则,它无法修复。