Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

<Feature Request> KongPlugin CRDs should be reusable #6

Closed
jtschulz opened this issue Apr 10, 2018 · 2 comments
Closed

<Feature Request> KongPlugin CRDs should be reusable #6

jtschulz opened this issue Apr 10, 2018 · 2 comments
Labels
area/feature New feature or request work in progress Work In Progress

Comments

@jtschulz
Copy link

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Feature request

Kong Ingress controller version:
0.0.1

Kubernetes version (use kubectl version):
1.9.6

Environment:
GKE

What happened:
We created KongPlugin manifests for the plugins that we are using for multiple routes and annotated those ingresses to use the plugins per the documentation. However, only one on the routes got the plugin via kong API. We were able to work around this by creating one unique CRD per ingress, referencing the same kong plugin in the annotation prefix, as specified in #4 .

What you expected to happen:
Ideally we could define the plugin once and reuse it in many routes/ services.
@jtschulz jtschulz changed the title <Feature Request> KongPlugin CRDs should be reusable by mult <Feature Request> KongPlugin CRDs should be reusable Apr 10, 2018
@aledbf aledbf added the area/feature New feature or request label Apr 10, 2018
@gerred
Copy link

gerred commented Apr 25, 2018

This would be a great enhancement. You can always overload the ingress resource itself to share configuration, but that makes it harder to separate out Helm charts for applications that are independent of each other.

@eamonnmcevoy eamonnmcevoy mentioned this issue Aug 16, 2018
Closed
@hbagdi hbagdi added the work in progress Work In Progress label Sep 10, 2018
@hbagdi hbagdi mentioned this issue Sep 10, 2018
Merged
hbagdi added a commit that referenced this issue Sep 11, 2018
@hbagdi
feat: reuse KongPlugin resources across ingress resources
8490c94 
Problem:
KongPlugin custom resource defines a Plugin in Kong.
Currently, a KongPlugin resource exists for every Plugin entity in Kong.
The sync process ensures that KongPlugin and the corresponding Plugin
entitiy in Kong are in sync and diff them as they share the same ID
(UID/UUID). This is not a scalable or maintainable configuration. If
there are a large (100s) number of ingress rules or services, there will
be similar number of KongPlugin objects for each plugin that is enabled
on those routes/services.
See #6
See #83

Solution:
Decouple k8s KongPlugin and Plugin entities in Kong, there-by removing
the unnecessary duplication.
This solution implies that there is not a KongPlugin resource in k8s for every
Plugin entity in Kong. This is fine as long as there can exists only a
single plugin of any type (type is key-auth, rate-limiting etc), which
is the case in Kong.
The diff and sync logic has been updated to compare
the correct plugin entity in Kong.
This makes a KongPlugin resource much more usable. If one wants to
change a configuration of plugin across multiple ingress, changing a
single KongPlugin resource will change it in all the ingress rules (or
routes/services in Kong's terminology).
hbagdi added a commit that referenced this issue Sep 11, 2018
@hbagdi
feat: reuse KongPlugin resources across ingress resources
2550758 
Problem:
KongPlugin custom resource defines a Plugin in Kong.
Currently, a KongPlugin resource exists for every Plugin entity in Kong.
The sync process ensures that KongPlugin and the corresponding Plugin
entitiy in Kong are in sync and diff them as they share the same ID
(UID/UUID). This is not a scalable or maintainable configuration. If
there are a large (100s) number of ingress rules or services, there will
be similar number of KongPlugin objects for each plugin that is enabled
on those routes/services.
See #6
See #83

Solution:
Decouple k8s KongPlugin and Plugin entities in Kong, there-by removing
the unnecessary duplication.
This solution implies that there is not a KongPlugin resource in k8s for every
Plugin entity in Kong. This is fine as long as there can exists only a
single plugin of any type (type is key-auth, rate-limiting etc), which
is the case in Kong.
The diff and sync logic has been updated to compare
the correct plugin entity in Kong.
This makes a KongPlugin resource much more usable. If one wants to
change a configuration of plugin across multiple ingress, changing a
single KongPlugin resource will change it in all the ingress rules (or
routes/services in Kong's terminology).

From #121
@hbagdi
Copy link
Member

hbagdi commented Sep 11, 2018

#121 was merged to master. This will be available in the next release of Kong Ingress Controller.

Thank you for opening this issue!

@hbagdi hbagdi closed this as completed Sep 11, 2018
hbagdi added a commit that referenced this issue Oct 23, 2018
@hbagdi
feat: reuse KongPlugin resources across ingress resources
c207eb4 
Problem:
KongPlugin custom resource defines a Plugin in Kong.
Currently, a KongPlugin resource exists for every Plugin entity in Kong.
The sync process ensures that KongPlugin and the corresponding Plugin
entitiy in Kong are in sync and diff them as they share the same ID
(UID/UUID). This is not a scalable or maintainable configuration. If
there are a large (100s) number of ingress rules or services, there will
be similar number of KongPlugin objects for each plugin that is enabled
on those routes/services.
See #6
See #83

Solution:
Decouple k8s KongPlugin and Plugin entities in Kong, there-by removing
the unnecessary duplication.
This solution implies that there is not a KongPlugin resource in k8s for every
Plugin entity in Kong. This is fine as long as there can exists only a
single plugin of any type (type is key-auth, rate-limiting etc), which
is the case in Kong.
The diff and sync logic has been updated to compare
the correct plugin entity in Kong.
This makes a KongPlugin resource much more usable. If one wants to
change a configuration of plugin across multiple ingress, changing a
single KongPlugin resource will change it in all the ingress rules (or
routes/services in Kong's terminology).

From #121
mflendrich pushed a commit that referenced this issue Feb 10, 2021
@shaneutt
feat: permit manifest generator to handle floats
0d8f541 
Fix #6

Co-authored-by: Shane Utt <[email protected]>
mflendrich pushed a commit that referenced this issue Feb 17, 2021
@shaneutt @mflendrich
feat: permit manifest generator to handle floats
cf28160 
Fix #6

Co-authored-by: Shane Utt <[email protected]>
mflendrich pushed a commit that referenced this issue Feb 17, 2021
@shaneutt @mflendrich
feat: permit manifest generator to handle floats
409f2d5 
Fix #6

Co-authored-by: Shane Utt <[email protected]>
shaneutt added a commit that referenced this issue Feb 17, 2021
@shaneutt
feat: permit manifest generator to handle floats
a1c3414 
Fix #6

Co-authored-by: Shane Utt <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/feature New feature or request work in progress Work In Progress
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@aledbf @gerred @hbagdi @jtschulz