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

Migrate namespaces retrieval from Kubeops to Kubeapps APIs #5239

Merged
merged 6 commits into from Aug 31, 2022

Conversation

castelblanque
Copy link
Collaborator

Signed-off-by: Rafa Castelblanque rcastelblanq@vmware.com

Description of the change

Migration of the namespaces list retrieval from Kubeops to Kubeapps APIs. It resides now in the resources plugin, under the endpoint GetNamespaceNames. Frontend has been changed to use the new endpoint too.

image

One affected functionality is the one for trusted namespaces (#2671/#2506). Chart values for specifying header name and pattern have been moved into the resources plugin configuration section.

Benefits

We are one step closer to deprecating Kubeops.

Possible drawbacks

Backwards compatibilty issue for adopters using the trusted namespaces functionality from headers.

Applicable issues

Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
@netlify
Copy link

netlify bot commented Aug 26, 2022

Deploy Preview for kubeapps-dev canceled.

Name Link
🔨 Latest commit fbf252b
🔍 Latest deploy log https://app.netlify.com/sites/kubeapps-dev/deploys/630f52396cb8670008c96121

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

license-eye has totally checked 1571 files.

Valid Invalid Ignored Fixed
748 2 821 0
Click to see the invalid file list
  • cmd/kubeapps-apis/plugins/resources/v1alpha1/common/plugin_test.go
  • cmd/kubeapps-apis/plugins/resources/v1alpha1/namespaces_filtering.go

Rafa Castelblanque and others added 2 commits August 29, 2022 08:16
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
@castelblanque castelblanque marked this pull request as ready for review August 29, 2022 07:21
Copy link
Contributor

@antgamdia antgamdia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really happy to see we are removing old code from the pkg/kube thing and moving to the place it really belongs now: a plugin in the kubeapps-apis server! Thanks

cmd/kubeops/cmd/root.go Show resolved Hide resolved
@@ -312,7 +307,6 @@ type handler interface {
UpdateAppRepository(appRepoBody io.ReadCloser, requestNamespace string) (*v1alpha1.AppRepository, error)
RefreshAppRepository(repoName string, requestNamespace string) (*v1alpha1.AppRepository, error)
DeleteAppRepository(name, namespace string) error
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious: do you know if we can remove more logic from this file? If so, do you plan to do so as part of the kubeops deprecation? Or should we file another issue for it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly, from the pkg/kube we can remove a lot of stuff. That will be done after removing Kubeops in a subsequent step.

Rafa Castelblanque and others added 3 commits August 31, 2022 13:15
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
@castelblanque castelblanque merged commit 83b277a into main Aug 31, 2022
@castelblanque castelblanque deleted the 4785-remove-kubeops branch August 31, 2022 13:54
This was referenced Aug 31, 2022
}
var config resourcesConfig

// #nosec G304
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @castelblanque, just for the sake of learning, I've never seen this kind of comment/annotation before, and I guess it should be processed by some kind of security linter/checker. Could you tell me what's the tool in charge of this and where is its configuration?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a gosec annotation we use for ignoring false positives and wontfixes. See https://github.com/securego/gosec#annotating-code

Comment on lines +71 to +73
if err != nil {
log.Fatalf("%s", err)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't you considered the use of github.com/stretchr/testify library (which I've checked is already included in the project) to ease the writing and reading of tests? This way you could replace these three lines with just a oneliner like require.NotNil(t, err)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely, I'll try to remember next time. In many cases, this block of code is just copy-pasted.
Thanks!

}

// Try to list namespaces with the user token, for backward compatibility
namespaces, err := typedClient.CoreV1().Namespaces().List(context.TODO(), metav1.ListOptions{})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand why context.TODO() is used here. Shouldn't we pass the parent function's context ctx or context.Background() in case we want a totally new context?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The auth token of the request is actually handled in the s.clientGetter func of line 44. It is, in turn, handled here based on the request's context.
Commenting here your post below: parts of the code are legacy from Kubeops so we inherit some stuff, but agree with you that we should try to harmonize the usage of context.Background() and context.TODO(). The two are mainly the same (see the contexts definition here), it is regarding semantics.

Go docs say that Code should use context.TODO when it's unclear which Context to use or it is not yet available (because the surrounding function has not yet been extended to accept a Context parameter).

Documentation here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks for the explanation 🙂

namespaces, err := typedClient.CoreV1().Namespaces().List(context.TODO(), metav1.ListOptions{})
if err != nil {
if k8sErrors.IsForbidden(err) {
backgroundCtx := context.Background()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, here we're not being consistent with previous uses and are using context.Background(), and below we resort to context.TODO() again. Also, I guess you could get rid of backgroundCtx variable as it's only used in one single place, so it could be inlined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove/migrate UI calls to Kubeops
4 participants