Open sbrouet opened 1 year ago
Since we will differentiate layer4 and layer7 by spec.http
and spec.stream
, and they are very different.
I think this field can be changed to spec.http.plugins
and spec.http.plugin_config_name
, what do you think?
In addition, I think we also need to describe its priority and what the final result will be when these fields are configured at the same time.
Normally, configurations with a smaller scope should have higher priority.
Since we will differentiate layer4 and layer7 by
spec.http
andspec.stream
, and they are very different. I think this field can be changed tospec.http.plugins
andspec.http.plugin_config_name
, what do you think?
Our current field is spce.http[].plugins
and spec.http[].plugin_config_name
.
Our spec.http is an array, rule level.
If this feature is supported, http should be an object, which would make an incompatible change, which would require a V3 API version.
Since we will differentiate layer4 and layer7 by
spec.http
andspec.stream
, and they are very different. I think this field can be changed tospec.http.plugins
andspec.http.plugin_config_name
, what do you think?
Hello, Indeed I see currently plugins can be configured only on http routes (according to ApisixRoute/v2 Reference: https://apisix.apache.org/zh/docs/ingress-controller/references/apisix_route_v2/) So seems reasonnable
In addition, I think we also need to describe its priority and what the final result will be when these fields are configured at the same time.
Normally, configurations with a smaller scope should have higher priority.
Hello, Yes I agree. Do you want me to edit proposal ? Do you have an example (from other bug or documentation) I could use to have clear documentation ?
If this feature is supported, http should be an object, which would make an incompatible change, which would require a V3 API version.
Hello,
That is a good remark. spec.http[].plugin_config_name
indeed is a single value
I don't know what is best practice in such cases.
Versioning (v3) probably is cleaner.
Another - hacky - option would be keeping current spec.http[].plugin_config_name
field and adding an optional array named spec.http[].plugin_config_names
(with plural). In that case old configurations would be compatible. Priority would need to be defined when both plugin_config_name
and plugin_config_names
are present.
Thanks !
Hello Team,
ApisixRoute
CRD allows defining plugins to use at rule level only, either withplugins
orplugin_config_name
element. Currently, when 1ApisixRoute
has multiple rules, the plugins configuration must be repeated to each rule. Even though we can define the plugin configuration in anApisixPluginConfig
, we still need to specify theplugin_config_name
element for each rule.Please feel free to comment and propose better approach. Let me know if any information is missing or I did not respect some rule when writing this issue, this is the first one I am opening on the project.
High level proposal
plugins
orplugin_config_name
)ApisixRoute
level, the plugin configuration at rule level overrides the one fromApisixRoute
levelSample ApisixRoute BEFORE change (current situation)
Using
plugins
elementThe
proxy-rewrite
plugin configuration must be repeated for each ruleUsing
plugin_config_name
elementThe
plugin_config_name
element must be repeated for each ruleSample ApisixRoute AFTER change (current situation)
Using
plugins
elementUsing
plugin_config_name
elementThank you Team for your good work ! Sébastien