You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to group rules to NetworkPolicies by their logical relations, but would not by selectors. It means rules in one NetworkPolicy should have different selectors (to select Pods to apply the rules).
This is especially important after we introduce priorities on NetworkPolicies, because if all rules in one NetworkPolicy must share the same selectors, user might end up creating many NetworkPolicies for each "selectors + policy priority" combination. It might become super challenging to manage all these NetworkPolicies and assign the right priority number for each, without a separate orchestrator to group NetworkPolicies and auto-assign priorities.
In contrast, if each rule can have its own selectors, user can group rules just based on their logical relations (and policy priority), and in a NetworkPolicy rules are ordered in the rule slice. Then it becomes much easier to manage NetworkPolicies and priorities.
@mattfenwick and I are deeply looking into datalog/RDF style representations for this. The idea being that
a structure such as a traffic, which generically defines a relationship between two nodes in a graph, would be the primary representation of all policies.
Then after that, logical rules which cast a 'net' over traffic , i.e. "pods" , "namespaces", "service boundaries" and so on could be made.
After this, a "Matcher", runs in the background that continually translates these rules into concrete policies.
jayunit100
changed the title
[User story proposal] group rules by logical relations but not just by selectors (allow each rule to have its own selectors)
[DISCUSSION] [USER STORY PROPOSAL] group rules by logical relations but not just by selectors (allow each rule to have its own selectors)
Sep 15, 2020
I want to group rules to NetworkPolicies by their logical relations, but would not by selectors. It means rules in one NetworkPolicy should have different selectors (to select Pods to apply the rules).
This is especially important after we introduce priorities on NetworkPolicies, because if all rules in one NetworkPolicy must share the same selectors, user might end up creating many NetworkPolicies for each "selectors + policy priority" combination. It might become super challenging to manage all these NetworkPolicies and assign the right priority number for each, without a separate orchestrator to group NetworkPolicies and auto-assign priorities.
In contrast, if each rule can have its own selectors, user can group rules just based on their logical relations (and policy priority), and in a NetworkPolicy rules are ordered in the rule slice. Then it becomes much easier to manage NetworkPolicies and priorities.
@abhiraut @McCodeman
The text was updated successfully, but these errors were encountered: