-
Notifications
You must be signed in to change notification settings - Fork 40
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
Handle workspace in Kong's client #62
Conversation
@mmorel-35 I think the right approach here is to do the following that solves major problems in decK's codebase:
These 3 could be 3 separate PRs that go in one after the other. |
If you add a About the Concerning thread-safe, how can it be insured ? |
Codecov Report
@@ Coverage Diff @@
## main #62 +/- ##
==========================================
- Coverage 45.50% 39.70% -5.81%
==========================================
Files 40 40
Lines 2525 2539 +14
==========================================
- Hits 1149 1008 -141
- Misses 1077 1282 +205
+ Partials 299 249 -50
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you add a
SetWorkspace()
this can set an internal workspace field of the client. Then the NewRequest will be in charge of the construction of the URL with the baseURL and the workspace.
See the attached comments - I've proposed a slightly different approach wrt. constructing the base URL, in order to avoid synchronization issues.
There can be an internal function to check the presence of a workspace
hasWorkspace()
. It would then be used by Root to know which endpoint to call.
See the attached comments as well - we need to design the APIs so that we can ensure valid concurrent access to the workspace setting.
What would be the use for
ClearWorkspace()
?
Funny legacy reasons. Some operations in decK require a client without a workspace, even if the tool has been run on a specific workspace. For sake of implementation in go-kong, let's just assume that the user of the client will have freedom to set, change and unset the workspace multiple times. But I believe that we could drop the ClearWorkspace
idea in favor of SetWorkspace("")
but that's not a strong opinion.
About the
Version()
method, what about defining aInformations
orKong
service which would hold it and also have the methods likeIsInMemory()
,Database()
,IsRBACEnabled()
orIsPortalEnabled()
which are used between KIC and the go-kong's integration tests?
On a high level I'd like us to have an API like this in go-kong, but that's probably out of scope of this PR. Could you please file an issue with a description of your idea, so that we can discuss it in a narrower context? go-kong would definitely benefit from such an improvement but let's pay due diligence before jumping into coding.
Concerning thread-safe, how can it be insured ?
See my attached review comments.
// body is always marshaled into JSON. | ||
func (c *Client) NewRequest(method, endpoint string, qs interface{}, | ||
//NewRequestRaw creates a request based on the inputs. | ||
func (c *Client) NewRequestRaw(method, baseURL string, endpoint string, qs interface{}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we rename baseURL to url
?
I think it makes the signature a bit more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using url would mean using the full one, isn't it?
As it's always concatenated with the endpoint parameter, wouldn't it lead to confusion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I misunderstood. @mflendrich Should we name these as NewWorkspacedRequest
NewRequest
and then appropriate docs comment? The current API in this patch is not very easy to grok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to achieve two results:
- no breaking changes to
NewRequest
- having a new function that accepts the base URL from the outside
Maybe we can relax the former. In that situation, we could do the following movements:
- rename
NewRequest
toNewRequestCurrentWorkspace
- rename
NewRequestRaw
toNewRequestForBaseURL
and say explicitly in the docstring that this expects the workspace URL to be passed as the base URL.
WDYT?
func (c *Client) NewRequest(method, endpoint string, qs interface{}, | ||
body interface{}) (*http.Request, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a bit more descriptive?
func (c *Client) NewRequest(method, endpoint string, qs interface{}, | |
body interface{}) (*http.Request, error) { | |
func (c *Client) NewRequest(method, relativePath string, qs interface{}, | |
body interface{}) (*http.Request, error) { |
Co-authored-by: Harry <harrybagdi@gmail.com>
Co-authored-by: Michał Flendrich <m.flendrich@gmail.com>
ping @mflendrich |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems that I reviewed this PR a week ago but the comments remained as pending 😩. Sorry about that.
// body is always marshaled into JSON. | ||
func (c *Client) NewRequest(method, endpoint string, qs interface{}, | ||
//NewRequestRaw creates a request based on the inputs. | ||
func (c *Client) NewRequestRaw(method, baseURL string, endpoint string, qs interface{}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to achieve two results:
- no breaking changes to
NewRequest
- having a new function that accepts the base URL from the outside
Maybe we can relax the former. In that situation, we could do the following movements:
- rename
NewRequest
toNewRequestCurrentWorkspace
- rename
NewRequestRaw
toNewRequestForBaseURL
and say explicitly in the docstring that this expects the workspace URL to be passed as the base URL.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No blockers left from my side.
This may have something to do with a KIC 2.0 issue about the |
This PR has not been released yet, in v0.19.0 the root was just / not /kong, with a new release, and it's integration in kic, the issue Kong/kubernetes-ingress-controller#1353 shall be fixed. It is what you meant @mflendrich, right? |
Fixes #48 (comment)