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

WIP: refactor: place utility methods in pkg/cmd #1371

Merged
merged 3 commits into from
Jan 10, 2022

Conversation

rkpattnaik780
Copy link
Contributor

@rkpattnaik780 rkpattnaik780 commented Jan 6, 2022

Moved utility methods to respective commands.

The sub-directories of kafkautil could be moved to the respective command specific directory.
Certain methods of kafkautil, serviceregistryutil and serviceaccountutil had few methods used by core, specific methods have been moved to respective directory.

Directory Structure

|─ pkg
|── cmd
|   ├── kafka
|           |─── create
|           |─── update
|           |─── topic
|                   |─── create
|                   |─── update
|                   |─── ...
|                   |─── sdk
|           |─── ......
|           |─── sdk
|   ├── cluster
|           |─── sdk
|           |─── ...
|   ├── sdk
|──  kafkautil
|── serviceregistryutil
|── serviceaccountutil

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation change
  • Refactor

Checklist

  • Documentation added for the feature
  • CI and all relevant tests are passing
  • Code Review completed
  • Verified independently by reviewer

Copy link
Contributor

@craicoverflow craicoverflow left a comment

Choose a reason for hiding this comment

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

Calling all of these packages a generic sdk makes things less readable.

Comment on lines 6 to 9
"github.com/redhat-developer/app-services-cli/pkg/cmd/cluster/sdk"
"github.com/redhat-developer/app-services-cli/pkg/cmd/cluster/sdk/kubeclient"
"github.com/redhat-developer/app-services-cli/pkg/cmd/cluster/sdk/services/resources"
"github.com/redhat-developer/app-services-cli/pkg/cmd/cluster/sdk/v1alpha"
Copy link
Contributor

Choose a reason for hiding this comment

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

I would not class the cluster packages as utils - isn't the purpose of this PR to only move utils?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah I agree. sdk and util is the same thing to me, different names.. cluster should be the package name here.

@@ -1,12 +1,12 @@
package cluster
package sdk
Copy link
Contributor

Choose a reason for hiding this comment

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

This package name is too generic IMO. You will have multiple packages called sdk.

https://rakyll.org/style-packages/

@@ -83,7 +83,7 @@ func NewAdminACLCommand(f *factory.Factory) *cobra.Command {
}

// user and service account should not allow wildcard
if userID == aclutil.Wildcard || serviceAccount == aclutil.Wildcard || userID == aclutil.AllAlias || serviceAccount == aclutil.AllAlias {
if userID == sdk.Wildcard || serviceAccount == sdk.Wildcard || userID == sdk.AllAlias || serviceAccount == sdk.AllAlias {
Copy link
Contributor

Choose a reason for hiding this comment

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

If you look at this line, it is very difficult to understand what sdk relates to. aclutil is much more self descriptive.

<thing>util is a common pattern in Go: https://pkg.go.dev/io/ioutil

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have followed <thing>util for utility methods at top level, i.e pkg/kafkautil, pkg/serviceregistryutil. I was hoping to follow a different naming convention for utils specific to commands, maybe aclcmdutil, topiccmdutil could be better alternative? Wdyt?

Copy link
Collaborator

@wtrocki wtrocki Jan 7, 2022

Choose a reason for hiding this comment

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

I think it is all about import path.

if util/sdk/common has subpackages then we have nice pattern - single name used across all cli packages with specific sub packages.

It might be overkill so them we sacrifice pattern of using single name towards more packages in root - which is ok

Copy link
Collaborator

Choose a reason for hiding this comment

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

Quick look at other projects confirms what enda said. Havents seen packages with common subpackages being used in go

Copy link
Collaborator

Choose a reason for hiding this comment

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

Although our case is different as people might want import sdk etc. so it is self documenting change. etc

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, the import path does not matter a bit, what is important is the name of the package which will be used in the code.

Copy link
Contributor

Choose a reason for hiding this comment

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

I have followed <thing>util for utility methods at top level, i.e pkg/kafkautil, pkg/serviceregistryutil. I was hoping to follow a different naming convention for utils specific to commands, maybe aclcmdutil, topiccmdutil could be better alternative? Wdyt?

Yes I like that!.

@wtrocki
Copy link
Collaborator

wtrocki commented Jan 7, 2022

Reviewed it later than Enda. Fully agree with the naming scheme that Enda proposed.
I'm not 100% sure what to do with cluster logic right now until we have shared service package where we put code that needs to be aware of the all services etc. That is why I think cluster might stay where it is for now? WDYT?

@rkpattnaik780
Copy link
Contributor Author

That is why I think cluster might stay where it is for now? WDYT?

I will agree, reverting the commit.

@wtrocki
Copy link
Collaborator

wtrocki commented Jan 8, 2022

Amazing work!
I think we could start documenting our approach in the docs explaining approaches etc.

We can do that after PR is merged

Copy link
Contributor

@craicoverflow craicoverflow left a comment

Choose a reason for hiding this comment

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

LGTM!

@@ -162,7 +162,7 @@ func runDelete(instanceID string, opts *aclutil.CrudOptions) error {
defer httpRes.Body.Close()
}

err = aclutil.ValidateAPIError(httpRes, opts.Localizer, err, "delete", kafkaInstance.GetName())
err = aclcmdutil.ValidateAPIError(httpRes, opts.Localizer, err, "delete", kafkaInstance.GetName())
Copy link
Contributor

Choose a reason for hiding this comment

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

I think that ValidateAPIError belongs more in an SDK instead of a cmd util, but we can revisit that when the error handling refactor happens.

activeMembersCount := consumergrouputil.GetActiveConsumersCount(consumers)
partitionsWithLagCount := consumergrouputil.GetPartitionsWithLag(consumers)
unassignedPartitions := consumergrouputil.GetUnassignedPartitions(consumers)
activeMembersCount := groupcmdutil.GetActiveConsumersCount(consumers)
Copy link
Contributor

Choose a reason for hiding this comment

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

nice and concise now :)

@@ -203,7 +202,7 @@ func runCmd(opts *options) error {
}

func runInteractivePrompt(opts *options) (err error) {
validator := topicutil.Validator{
validator := topiccmdutil.Validator{
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd say eventually, validators wont be in the util package as they are not util methods, again that can happen during the SDK creation.

@@ -1,4 +1,4 @@
package topicutil
package topiccmdutil
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably start to document all pakcage names and their meaning too, this should happen at the top of the package topiccmdutil declaration, but to prevent duplication can be added in a doc.go file: https://go.dev/blog/godoc

@craicoverflow
Copy link
Contributor

Amazing work! I think we could start documenting our approach in the docs explaining approaches etc.

We can do that after PR is merged

https://go.dev/blog/godoc

We could document packages using the available Go tooling. You can define it all in a doc.go file: https://github.com/googleapis/google-cloud-go/blob/main/datastore/doc.go

@wtrocki
Copy link
Collaborator

wtrocki commented Jan 10, 2022

Actually realized that syntax for the ones we have is wrong: https://pkg.go.dev/github.com/redhat-developer/[email protected]/pkg/cluster and as enda mentioned we should probably use docs.go instead.
If that is option we can do with it.

@craicoverflow craicoverflow linked an issue Jan 10, 2022 that may be closed by this pull request
@wtrocki wtrocki merged commit cc5417f into redhat-developer:development Jan 10, 2022
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.

Refactor the pkg public API to improve organization.
3 participants