-
Notifications
You must be signed in to change notification settings - Fork 103
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
Refactor functions to install/upgrade package resources into 'kudo' package #991
Conversation
As discussed extensively offline, |
…ces' package This reduces the coupling between the respective commands and the actual implementation that is taking care of these CRDs. It also allows non-CLI parts to use this functionality.
42140a8
to
867ee66
Compare
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.
Overall I like it, have just few small comments:
- first I think this package deserves a doc.go since we're planning that as an entrypoing for addons integration
- I don't think that majority of the usages of %w is correct based on https://blog.golang.org/go1.13-errors - do we really want to expose the underlying wrapped kubernetes client errors?
pkg/kudoctl/cmd/upgrade.go
Outdated
@@ -8,9 +8,8 @@ import ( | |||
"github.com/kudobuilder/kudo/pkg/kudoctl/env" | |||
"github.com/kudobuilder/kudo/pkg/kudoctl/util/kudo" | |||
"github.com/kudobuilder/kudo/pkg/kudoctl/util/repo" | |||
util "github.com/kudobuilder/kudo/pkg/util/kudo" | |||
"github.com/kudobuilder/kudo/pkg/kudoctl/util/resources" |
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.
could we move it one level up so it's pkg/kudoctl/util/resources
?
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.
Overall I agree, this shouldn't be under pkg/kudoctl/util
. But so shouldn't pkg/kudoctl/util/kudo
. As the function of these packages is to abstract the usage of clientset
they all should live in a folder in pkg
and that folder shouldn't be named util
😄
But given that resources
provides helper for the kudo
package, I'd rather keep it close to that package for now, hence keep it in pkg/kudoctl/util
. Instead we should move all of util
as part of a separate PR.
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.
There is this gopher talk from Ashley McNamara on package organization where he adamant on util
packages being an anti-pattern. If anything, I'd try to reduce the util
pkg footprint by moving things where they're used and name them accordingly.
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.
Let's consolidate the footprint in this PR so it's focused on the new package, and then we can immediately open a refactoring that moves util out and gets rid of it entirely, wdyt @zen-dog?
return err | ||
} | ||
|
||
if err := kc.ValidateServerForOperator(resources.Operator); err != nil { |
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.
could we rename this to something like "ValidateServerVersionsForOperator"? :) I really had to go to the implementation to actually understand what this does
I know you did not introduce it but I just found it in your diff so we should probably improve :)
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.
Let's tackle this in a different PR where we move this package and also improve on the function names, as mentioned in the comments above. wdyt?
It's "resources", not "CRDs".
// - an operator name in the remote repository | ||
// in that order. Should there exist a local folder e.g. `cassandra` it will take precedence | ||
// over the remote repository package with the same name. | ||
func GetPackageResources(operatorName string, version string, repository repo.Repository) (*packages.PackageCRDs, 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.
Why is this method not part of the /packages
pkg? It seems like a better place for it since it is dealing with packaged files (either locally or over the wire).
Also, naming:
Get
-prefix is also considered an anti-patternGetPackageResources() -> packages.Resources()
- This method should also return
*packages.Resources
instead ofPackageCRDs
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.
👍
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.
Unfortunately, this can't be moved into packages
, because this will result in import cycles due to circular package references. This is due to tight coupling in this as well as other packages. Further refactorings are necessary to clean this up and are out of scope of this PR. I'll move this to the kudo
package for now.
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.
Great effort, but we need to polish the resulting structure a bit more
Commenting without explicit approval or requesting changes. This looks good and is heading the right direction, most of my feedback is echoing and not adding more on existing feedback. |
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 think this is a better version of what we had before so let's land it! 🚢
pkg/kudoctl/util/kudo/resources.go
Outdated
// - an operator name in the remote repository | ||
// in that order. Should there exist a local folder e.g. `cassandra` it will take precedence | ||
// over the remote repository package with the same name. | ||
// TODO: move this to the 'packages' package -- currently not possible because if a dependency cycle |
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 todo still relevant? I don't think so...
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.
Yes, very relevant. This function should be in packages
but can't be there without further refactorings, see #991 (comment)
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.
okay then I would probably not move it here, since we want to move it somewhere else anyway 🤷♀
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.
We should probably reorganize packages
pgk similar to what we did for the engine
pkg:
- have
packages/types.go
with all package types - put everything else into
packages/*
sub-packages to avoid circular dependencies
This is the pattern that K8S uses a lot and it seems to make a lot of sense.
Created #1002 to track further refactorings as discussed in this PR. |
Interesting linting error due to a circular dependency:
Let me fix this. |
'pkg/kudoctl/cmd/env' depends on 'pkg/kudoctl/cmd/util/kudo' to implement a helper function that probably shouldn't live in this package.
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.
Nice! 🚢
…ackage (#991) This reduces the coupling between the respective commands and the actual implementation that is taking care of these resources. It also allows non-CLI parts to use this functionality.
What this PR does / why we need it:
This reduces the coupling between the respective commands and the actual
implementation that is taking care of these resources. It also allows non-CLI parts
to use this functionality.
Additional care has been taken to provide consistent error logging in
Install
andUpgrade
.