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.

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

Closed
hbagdi opened this issue Nov 4, 2019 · 7 comments · Fixed by #419
Closed

feature request: add feature to specify default values #89

hbagdi opened this issue Nov 4, 2019 · 7 comments · Fixed by #419
Assignees
Labels
feature New feature or request
Milestone

Comments

@hbagdi
Copy link
Member

hbagdi commented Nov 4, 2019

As a user, I should be able to define default values for all instances of some entities, examples include:

  • timeouts in service entity
  • health-check and load-balancing configuration in upstream entity
  • certain plugin configuraitons
@hbagdi hbagdi added feature New feature or request awaiting feedback Something that is waiting on users to provide feedback labels Nov 5, 2019
@hbagdi hbagdi removed the awaiting feedback Something that is waiting on users to provide feedback label Dec 7, 2019
@hbagdi hbagdi added this to the v0.7.0 milestone Dec 7, 2019
@hbagdi hbagdi added feature New feature or request and removed feature New feature or request labels Dec 8, 2019
@hbagdi hbagdi removed this from the v0.7.0 milestone Dec 8, 2019
@hbagdi hbagdi added this to the 1.3.0 milestone Jul 14, 2020
@hbagdi
Copy link
Member Author

hbagdi commented Jul 14, 2020

We want to ensure that this feature is implement in such a way that Kong's Ingress Controller can take advantage of it.

@hbagdi hbagdi removed this from the 1.3.0 milestone Feb 21, 2021
@stale
Copy link

stale bot commented Mar 20, 2021

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.

@stale stale bot added the stale Will be closed unless advocated for within 7 days label Mar 20, 2021
@stale stale bot closed this as completed Mar 27, 2021
@hbagdi hbagdi reopened this Mar 29, 2021
@stale stale bot removed the stale Will be closed unless advocated for within 7 days label Mar 29, 2021
@hbagdi hbagdi added this to the 1.8.0 milestone May 6, 2021
@Tieske
Copy link
Member

Tieske commented May 7, 2021

We want to ensure that this feature is implement in such a way that Kong's Ingress Controller can take advantage of it.

What does that advantage look like?

@hbagdi
Copy link
Member Author

hbagdi commented May 7, 2021

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.

@Tieske
Copy link
Member

Tieske commented May 8, 2021

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 x-kong-<service/route/upstream>-defaults contents, to prevent tight coupling between Insomnia versions and Kong versions.

@Tieske
Copy link
Member

Tieske commented May 8, 2021

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.

@hbagdi
Copy link
Member Author

hbagdi commented May 10, 2021

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.

@hbagdi hbagdi self-assigned this May 15, 2021
hbagdi added a commit that referenced this issue May 27, 2021
- 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
hbagdi added a commit that referenced this issue May 27, 2021
- 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
hbagdi added a commit that referenced this issue May 27, 2021
- 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
hbagdi added a commit that referenced this issue May 27, 2021
- 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
hbagdi added a commit that referenced this issue May 27, 2021
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.
hbagdi added a commit that referenced this issue May 27, 2021
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.
hbagdi added a commit that referenced this issue May 27, 2021
- 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
hbagdi added a commit that referenced this issue May 27, 2021
- 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
hbagdi added a commit that referenced this issue May 27, 2021
- 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
Tieske added a commit that referenced this issue Sep 21, 2023
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
AntoineJac pushed a commit that referenced this issue Jan 23, 2024
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.
AntoineJac pushed a commit that referenced this issue Jan 23, 2024
- 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants