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.
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
feature request: add feature to specify default values #89
Comments
We want to ensure that this feature is implement in such a way that Kong's Ingress Controller can take advantage of it. |
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. |
What does that advantage look like? |
Imagine you can define configurable defaults for kong-specific settings (service timeouts, LB details) once on a Namespace or global level. No need to ensure that annotations are present on all services. |
there's this in Insomnia: Kong/insomnia#3319 , but also prior art wrt plugins etc. How many different flows and config formats are we ending up with? This is probably oriented towards KiC? Do we have an overacrhing design of the flows we envision we need and how they relate to each other, what roles/responsibilities are where in the process? For example: Insomnia specifically does not validate the |
the above is not about my opinion, it's just me questioning whether we need to have a look at this whole space from a more abstract perspective. |
I think we should. The experience for our customers in this area is fragmented and often broken. We should be consolidating these flows into a single code-base and build APIs around it for integrating into other projects. |
- file/codegen/main.go and corresponding schema change This is to relax the schema of kong entities that are used as input for defaults. The relaxation is necessary as otherwise the user will have to specify a name in default values. This doesn't have any side-effects because the *kong.Type is not used anywhere else in Content. - file/builder.go file/reader.go - defaulter instantiation has been moved inside builder, this feels natural, defaulter being instantiated outside the builder seems odd and the only explanation is that I simply didn't think through when implementing defaulter - other changes override the default values that are registered Fix #89
- file/codegen/main.go and corresponding schema change This is to relax the schema of kong entities that are used as input for defaults. The relaxation is necessary as otherwise the user will have to specify a name in default values. This doesn't have any side-effects because the *kong.Type is not used anywhere else in Content. - file/builder.go file/reader.go - defaulter instantiation has been moved inside builder, this feels natural, defaulter being instantiated outside the builder seems odd and the only explanation is that I simply didn't think through when implementing defaulter - other changes override the default values that are registered Fix #89
- file/codegen/main.go and corresponding schema change This is to relax the schema of kong entities that are used as input for defaults. The relaxation is necessary as otherwise the user will have to specify a name in default values. This doesn't have any side-effects because the *kong.Type is not used anywhere else in Content. - file/builder.go file/reader.go - defaulter instantiation has been moved inside builder, this feels natural, defaulter being instantiated outside the builder seems odd and the only explanation is that I simply didn't think through when implementing defaulter - other changes override the default values that are registered Fix #89
- file/codegen/main.go and corresponding schema change This is to relax the schema of kong entities that are used as input for defaults. The relaxation is necessary as otherwise the user will have to specify a name in default values. This doesn't have any side-effects because the *kong.Type is not used anywhere else in Content. - file/builder.go file/reader.go - defaulter instantiation has been moved inside builder, this feels natural, defaulter being instantiated outside the builder seems odd and the only explanation is that I simply didn't think through when implementing defaulter - other changes override the default values that are registered Fix #89
go's generator will fail if the code cannot compile. This can happen when new types are introduced. This was found during development work on #89.
go's generator will fail if the code cannot compile. This can happen when new types are introduced. This was found during development work on #89.
- file/codegen/main.go and corresponding schema change This is to relax the schema of kong entities that are used as input for defaults. The relaxation is necessary as otherwise the user will have to specify a name in default values. This doesn't have any side-effects because the *kong.Type is not used anywhere else in Content. - file/builder.go file/reader.go - defaulter instantiation has been moved inside builder, this feels natural, defaulter being instantiated outside the builder seems odd and the only explanation is that I simply didn't think through when implementing defaulter - other changes override the default values that are registered Fix #89
- file/codegen/main.go and corresponding schema change This is to relax the schema of kong entities that are used as input for defaults. The relaxation is necessary as otherwise the user will have to specify a name in default values. This doesn't have any side-effects because the *kong.Type is not used anywhere else in Content. - file/builder.go file/reader.go - defaulter instantiation has been moved inside builder, this feels natural, defaulter being instantiated outside the builder seems odd and the only explanation is that I simply didn't think through when implementing defaulter - other changes override the default values that are registered Fix #89
- file/codegen/main.go and corresponding schema change This is to relax the schema of kong entities that are used as input for defaults. The relaxation is necessary as otherwise the user will have to specify a name in default values. This doesn't have any side-effects because the *kong.Type is not used anywhere else in Content. - file/builder.go file/reader.go - defaulter instantiation has been moved inside builder, this feels natural, defaulter being instantiated outside the builder seems odd and the only explanation is that I simply didn't think through when implementing defaulter - other changes override the default values that are registered Fix #89
Fixes several issues; - fix(tags): the entitylist for tags was missing acl-groups (#89) - fix(oas): allow overriding route.strip_path - fix(oas): use google's UUID generator for UUID generation instead of an unmaintained library. Full changelog: https://github.com/Kong/go-apiops/releases/tag/v0.1.21
go's generator will fail if the code cannot compile. This can happen when new types are introduced. This was found during development work on #89.
- file/codegen/main.go and corresponding schema change This is to relax the schema of kong entities that are used as input for defaults. The relaxation is necessary as otherwise the user will have to specify a name in default values. This doesn't have any side-effects because the *kong.Type is not used anywhere else in Content. - file/builder.go file/reader.go - defaulter instantiation has been moved inside builder, this feels natural, defaulter being instantiated outside the builder seems odd and the only explanation is that I simply didn't think through when implementing defaulter - other changes override the default values that are registered Fix #89
As a user, I should be able to define default values for all instances of some entities, examples include:
The text was updated successfully, but these errors were encountered: