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

First step of AddPackageRepository - Package Repository API for Helm #4723

Merged
merged 19 commits into from
May 27, 2022

Conversation

castelblanque
Copy link
Collaborator

Description of the change

Adds a basic implementation of AddPackageRepository method from package repository API for the Helm plugin (#3496). With basic I mean:

  • No Docker credentials supported yet
  • No TLS config with secret ref (it is, though, the TLS CA)
  • No custom fields for Helm repos (e.g. template for cronjobs)

Package repositories for Helm plugin can be created now with the common repository API definition, e.g.

{
  "context": { "namespace": "example-ns" },
  "name": "example-repo",
  "type": "helm",
  "namespace_scoped": true,
  "url": "https://charts.bitnami.com/bitnami"
}

The above example will create a repository in the namespace example-ns.

Benefits

Repositories can be created meeting the new Package Repository API definition.

Possible drawbacks

None that I know. Outcome of this implementation should be the same AppRepository CRD created by the already existing API.
Don't see a problem with both APIs coexisting.

Applicable issues

Partially implements #4662.

Additional information

Following the example above, the one below will have the repo created in the global namespace, even if there is a namespace specified:

{
  "context": { "namespace": "example-ns" },
  "name": "example-repo",
  "type": "helm",
  "namespace_scoped": false,
  "url": "https://charts.bitnami.com/bitnami"
}

That does not seem very consistent to me, should we return failure in this case?

Rafa Castelblanque added 6 commits May 13, 2022 16:04
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
@netlify
Copy link

netlify bot commented May 17, 2022

Deploy Preview for kubeapps-dev canceled.

Name Link
🔨 Latest commit cff7999
🔍 Latest deploy log https://app.netlify.com/sites/kubeapps-dev/deploys/628f914d7fbfe00008a04f16

Rafa Castelblanque added 6 commits May 17, 2022 23:47
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
@castelblanque castelblanque marked this pull request as ready for review May 20, 2022 16:49
Rafa Castelblanque added 5 commits May 20, 2022 18:55
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
Signed-off-by: Rafa Castelblanque <rcastelblanq@vmware.com>
@absoludity
Copy link
Contributor

Hey @castelblanque . Did you check with @dlaloue-vmware about reviewing each other work? I can jump in and review if needed, but I think since you're both working on similar aspects for different plugins, it'd be a great chance to review each others and learn together?

@castelblanque
Copy link
Collaborator Author

You are totally right @absoludity. Will do!

@castelblanque castelblanque requested review from dlaloue-vmware and removed request for absoludity May 25, 2022 06:48
@absoludity absoludity mentioned this pull request May 26, 2022
@@ -1024,3 +996,75 @@ func (s *Server) GetInstalledPackageResourceRefs(ctx context.Context, request *c
}, nil
}
}

func (s *Server) AddPackageRepository(ctx context.Context, request *corev1.AddPackageRepositoryRequest) (*corev1.AddPackageRepositoryResponse, error) {
log.Infof("+helm AddPackageRepository [%v]", request)
Copy link
Collaborator

Choose a reason for hiding this comment

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

logging the whole request may leak credentials. it would be better to abstract only what is necessary (see how it is done in the method CreateInstalledPackage)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It is a line copied from Flux plugin here.
If it is just to locate the operation in the logs, I would say that name and URL should suffice.
@gfichtenholt what do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

I needed more than name and URL when I was working on flux as some point. I debugged and found and fixed the problem, whatever it was, then and this just kind of remained. I think @dlaloue-vmware is right, could you fix it and also fix one in flux as well if you have the bandwidth. Thanks in advance

return nil, status.Errorf(codes.InvalidArgument, "no package repository Name provided")
}
name := types.NamespacedName{Name: request.Name}
if request.GetNamespaceScoped() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

i think we have agreed to validate that the namespace and scope were consistent (e.g. if scope is global but namespace is not the global namespace, then it should be a validation error)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, added the check.

if request == nil {
return nil, status.Errorf(codes.InvalidArgument, "no request provided")
}
if request.Context == nil || request.Context.Namespace == "" {
Copy link
Collaborator

Choose a reason for hiding this comment

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

this is just a suggestion, but if the namespace is not provided, we could default it to the global namespace.
this makes it easier for users as the global namespace is not required to be known

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yep, it makes sense. Will add it.

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

@dlaloue-vmware Thanks for the review!

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.

Thanks for the changes! LGTM
I wanted to get into the UI revamp to refresh my knowledge regarding repos before looking at the PR.

Minor side coment:

Comment on lines +32 to +34
{
"name": "HelmRepositoriesService"
},
Copy link
Contributor

Choose a reason for hiding this comment

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

No action required in this PR, but just mentioning it for all us to be aware: the openapi.yaml file (which is the doc used for the interactive REST API portal) will get out of sync.

Also, but unrelated: I don't know why my generator is different (meaning worse) than yours haha.

}

// this func is only used with kubeapps-managed secrets
func newSecretFromTlsConfigAndAuth(repoName types.NamespacedName,
Copy link
Contributor

Choose a reason for hiding this comment

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

Didn't we have a shared /pkg/ folder share code across plugins?
I'm not sure, but I'd rather remove any dup code if possible, no?
(mentioning this bc I saw a similar fn in the flux plg)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Some code here is copied from Greg's Flux.
Most of the times due to Flux-specific structs it isn't possible to make it generic. I tried at the beginning but had to undo down the road.
We could do some refactoring in a later iteration if needed.

metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)

var (
Copy link
Contributor

Choose a reason for hiding this comment

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

Correct me if I'm wrong here, @absoludity , but I'd rather say we weren't so fans of globals in the tests, preferring instead each test case being defining (and customizing with a given set of test-case properties) the object.

So, what about replacing those globals with just functions creating each struct based upon a set of params (where you foresee the variability, I mean).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, I didn't know about that decision. I've used functions to generate structs at some points, but didn't want to convert tests in another set of complex code 😄

Copy link
Contributor

Choose a reason for hiding this comment

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

Not so much a decision as a recommendation - global vars create shared state that is then used by different tests. Can lead to one test updating that shared state causing hard to debug failures in other tests etc. See https://dave.cheney.net/2017/06/11/go-without-package-scoped-variables for a good discussion.

{
name: "returns error if invalid cluster",
request: &corev1.AddPackageRepositoryRequest{Context: &corev1.Context{Cluster: "wrongCluster", Namespace: "foo"}},
statusCode: codes.Unimplemented,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why unimplemented if invalid cluster?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Mmm yes, probably InvalidArgument makes more sense. Thanks!

@@ -0,0 +1,8 @@
{
"CN": "fluxv2plugin-testdata-ssl-svc.default.svc.cluster.local CA",
Copy link
Contributor

Choose a reason for hiding this comment

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

nitpick (same in the rest of ocurrences)

Suggested change
"CN": "fluxv2plugin-testdata-ssl-svc.default.svc.cluster.local CA",
"CN": "helmplugin-testdata-ssl-svc.default.svc.cluster.local CA",

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Will change it in the following PR that is based in this branch, if you don't mind.

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

Successfully merging this pull request may close these issues.

None yet

5 participants