Replies: 3 comments 1 reply
-
|
I’m not 100% sure I understand your suggestion (besides replacing “” with a named constant). ModRuleStore should not know about the presence of cluster wide resources. It represents a simple interface for associating ModRules with the place they are stored. The namespace where KubeMod is deployed is configurable and doesn’t necessarily have to be “kubemod-system”. The reality is that ModRuleStore is the one place which you can keep clean of that configurable “kubemod-system” business. The logic in ModRule controller which replaces “kubemod-system” with “” before it goes into ModRuleStore recognizes that fact and normalizes that special namespace without leaking that logic into the ModRuleStore. Also, there is nothing magic about namespace “”. It’s simply the namespace of non-namespaced resources as they are passed in by Kubernetes to KubeMod’s webhooks. That made them naturally be a target for ModRules stored with an empty namespace (before the introduction of TargetNamespaceRegex). |
Beta Was this translation helpful? Give feedback.
-
|
But I do agree that now with the introduction of TargetNamespaceRegex where no direct namespace mapping is done for cluster wide resources with namespace “”, it makes sense to replace “” with const in two places: the KubeMod controller where namespaces equal to r.clusterModRulesNamespace are currently replaced with “”, and in the new TargetNamespaceRegex logic in getMatchingModRuleStoreItems. This also makes it possible to use an actual magic string (say a guid) for that constant in order to avoid collisions with actual namespaces (although that constant can very well be equal to “” with no possibility of collisions). |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I'm taking this back. I took a closer look at the new code and I think I understand what you mean. |
Beta Was this translation helpful? Give feedback.
-
|
@jamiecore , please take a look at #64. |
Beta Was this translation helpful? Give feedback.
-
i feel like the ModRuleStore is in a better position to make decisions about where to store + find modrules
yet today there is logic outside the ModRuleStore -- that isn't immediately obvious -- e.g. ModRules in namespace "kubemod-system" -> should actually be stored with namespace "" ?
too -- the magic string "" is used -- if gonna be this way -- maybe use a const ?
now this type of logic exists in 2 places -- 1. in the ModRule constructor + 2. in the test runner
thoughts?
Beta Was this translation helpful? Give feedback.
All reactions