feature: exclusion/inclusion of plugins via additional metadata on services/routes

[hbagdi]

Users have expressed a need for two things:

• Ability to apply a global plugin but exclude certain services/routes (https://github.com/Kong/kong/issues/5233)
• Ability to define plugins templates and then directly use them on services/routes

The scope here is to figure out a way to define these things using decK's state file and then decK does the heavy lifting in the background to render the correct state and sync it to Kong.

[zekth]

What about having something like:

---
_format_version: "3.0"
_info:
  defaults:
    service:
      plugins:
      - name: foo
      _tag_policy: exclude
      _tag: bar

So this would add the plugin foo to all services without the tag bar. _tag_policy would be include or exclude On the same note i'd expect when a service has already the plugin foo to have its own definition overriding the defaults one.

What do you think @hbagdi ? i can work on this.

[hbagdi]

I spent 10 minutes thinking about this but I cannot convince myself one way or another because there is just too much to think about when it comes to features like this. This needs a bit more product thought before we start executing on this and requires a bit more careful evaluation of the use cases that it enables/disables. That's not a very encouraging answer.

So here is another way to execute:

• Write out a design document that starts from use cases that this would address and wouldn't.
• Explain how the design can introduce more programmability of policies in future versions
• Narrow down the scope to something minimal
• And then write code and ship

We must not skip the design phase here because quickly executing such a feature has backfired in Kong because (A) a change in one component affects others in ways that are not apparent on the surface (B) second-order effects show up after months/years and fixing those has proven to be very hard. We cannot do a perfect job but we want to account for these knock-on effects as much as possible because maintainability is a growing concern.

Please book some time on my calendar if you need to discuss this further. This feature has been highly requested and even though I have reservations about shipping it via decK, it can still be a worthwhile effort.