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

fix flux plugin UpdateInstalledPackage() according to agreed upon semantics #3468

Merged

Conversation

gfichtenholt
Copy link
Contributor

No description provided.

@gfichtenholt gfichtenholt self-assigned this Sep 22, 2021
@gfichtenholt gfichtenholt linked an issue Sep 22, 2021 that may be closed by this pull request
Copy link
Contributor

@absoludity absoludity left a comment

Choose a reason for hiding this comment

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

Great, thanks Greg.

return fluxPluginClient
}
return nil
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks - yes, now it explicitly fails if someone tries to enable them but hasn't got the kind cluster running etc.

// global vars
var letters = []rune("abcdefghijklmnopqrstuvwxyz0123456789")
var typedClient kubernetes.Interface
var dynamicClient dynamic.Interface
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need global vars? Normally it should be possible to avoid this type of state (your kubeGet* fns above already return the clients).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

not sure I get what you're asking. What's the alternative to global vars if I want to keep some state in between calls (other than to have to declare a new receiver struct or explicitly pass in the state back and forth, yuck)? Must be some language feature I am not aware of. Please tell me.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not asking you to change anything here, but worth reading: https://dave.cheney.net/2017/06/11/go-without-package-scoped-variables

Copy link
Contributor Author

@gfichtenholt gfichtenholt Sep 22, 2021

Choose a reason for hiding this comment

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

Sure, I'll give it a read. Just so we are on the same page, this is test code we are talking about, not production. Furthermore, this is test code that you've pointed out will become obsolete at some point not too far away. So not going an extra mile (or in this case an extra 10 miles based on what I read of the article so far) and taking a shortcut seemed like an acceptable thing to do for that case. If you find any cases where I am doing it in production code, please point them out

Copy link
Contributor

Choose a reason for hiding this comment

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

Yep, as above, nothing to change here. Just worth being aware, that's all. I like the last line ("the bottom line") of Dave's post.

expectedRelease: flux_helm_release_updated_1,
},
{
name: "returns invalid if installed package doesn't exist",
Copy link
Contributor

Choose a reason for hiding this comment

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

s/invalid/not found/ ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, indeed. I copied that case from your test, so you might want to correct that one. hehe

@@ -50,7 +50,7 @@ service PackagesService {

rpc UpdateInstalledPackage(UpdateInstalledPackageRequest) returns (UpdateInstalledPackageResponse) {
option (google.api.http) = {
patch: "/core/packages/v1alpha1/installedpackages"
put: "/core/packages/v1alpha1/installedpackages"
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice, so there will be no problem with us later providing a patch method here either (though I understand the message formats will need references throughout).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, right on

@gfichtenholt gfichtenholt merged commit 6dca124 into vmware-tanzu:master Sep 22, 2021
@gfichtenholt gfichtenholt deleted the further-fluxv2-plugin-features-10 branch September 22, 2021 07:44
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.

Implement further fluxv2 plugin features
2 participants