Document/prevent no-op constant configuration drifts such as with duplicate consumers

[yndai]

Is there an existing issue for this?

• [X] I have searched the existing issues

Problem Statement

Hi - after debugging a lingering latency issue in our cluster (on KIC 2.8.1 now), we narrowed it down to the constant configuration pushes from the controller at every sync interval. Diff'ing a few consecutive config dumps, we found that the only change was the position of consumers in the list perpetually shifting position:

       ]
     },
     {
-      "username": "user"
-    },
-    {
       "username": "user",
       "acls": [
         {
@@ -713647,9 +713644,6 @@
       ]
     },
     {
-      "username": "user"
-    },
-    {
       "username": "user",
       "acls": [
         {
@@ -713666,6 +713660,12 @@
       ]
     },
     {
+      "username": "user"
+    },
+    {
+      "username": "user"
+    },

Fixing those consumers and making names unique fixed this issue. I realize that it is not valid for there to be two KongConsumers with the same username in general (and I see the admission hook is now enabled by default in the official chart: https://github.com/Kong/charts/pull/727), but I just wanted to get this out there to see if there are other ways for the configuration to drift like this.

Proposed Solution

Document and/or prevent ways for the configuration to drift in a no-op way.

Additional information

No response

Acceptance Criteria

• [ ] document and/or prevent ways for the configuration to drift in a no-op way

[mflendrich]

@yndai,

This is certainly undesired behavior that should be considered a bug - but we cannot reliably tell if this has been fixed already without reproduction steps.

I'll leave this issue open with pending author feedback - if you can share a config that causes this perpetual syncing behavior, we'll be able to fix it.

Thank you for this report and we're looking forward to hearing back from you.

[yndai]

@mflendrich thanks for taking a look.

The configuration we had was roughly:

kind: KongConsumer
metadata:
  annotations:
    kubernetes.io/ingress.class: kong
  name: userA
  namespace: namespaceA
username: user
credentials:
- credentials1A
- credentials2A
---
kind: KongConsumer
metadata:
  annotations:
    kubernetes.io/ingress.class: kong
  name: userB
  namespace: namespaceB
username: user
credentials:
- credentials1B
- credentials2B
---
kind: KongConsumer
metadata:
  annotations:
    kubernetes.io/ingress.class: kong
  name: userC
  namespace: namespaceC
username: user
credentials:
- credentials1C
- credentials2C
[...]

And the output from enabling CONTROLLER_DUMP_CONFIG with such a config and diff'ing sequential syncs is in my first message (there were no other network topology changes). We have since had each app use unique usernames and have not seen this behavior anymore.

Again - I realize having multiple consumers with the same username is technically invalid and we did not have the admission webhook validator enabled so this was not caught so I'm not sure if this is a bug. I mainly wanted to get this out for visibility.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.