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

Controllers in a multigroup project belong to the 'controllers' package #1717

Closed
miguelsorianod opened this issue Oct 9, 2020 · 7 comments
Closed
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@miguelsorianod
Copy link
Contributor

miguelsorianod commented Oct 9, 2020

Hi,

I'm using operator-sdk v1.0.1, which, if I've understood correctly makes use of Kubebuilder for some of its commands.

I'm working on migrating an operator-sdk based project to operator-sdk 1.x version.

I've created the new project with the multigroup: true setting in the PROJECT file. Once that is done I generate the controller with operator-sdk create api ..., which after looking at the code I think is a command that belongs to kubebuilder, and I can see the directory structure is like this:

controllers/apps/apicast_controller.go

However, in the Go file of the controller I can see it has the following package definition:

package controllers

Notice how the package is controllers instead of apps. Is that expected/intentional? Might that be a bug? It seems odd.

I would have expected the package to be named apps in that directory.

With the current implementation I understand all controllers between different groups are sharing the same package name right now.

If you think this should be changed I'd be interested in contributing a change for this.

Software versions being used:

  • Go version: 1.13.7
  • kubebuilder version: I'm using the one that comes with operator-sdk v1.0.1, which I think uses the Go v2 plugin currently
  • controller-runtime v0.6.2
  • Kubernetes version: v1.18

Thank you.

/kind bug

@k8s-ci-robot k8s-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Oct 9, 2020
@camilamacedo86
Copy link
Member

Hi @miguelsorianod,

thank you for raise it. Could you please let us know if you will be working on to solve this scenario? if yes, could you please assign the issue to your self? Also, since it does not cause issues wdyt about we classify it as an RFE?

@miguelsorianod
Copy link
Contributor Author

Hi @camilamacedo86,

I'll work on this yes.
No issue with classifying this as an RFE 👍

@miguelsorianod
Copy link
Contributor Author

/assign

@miguelsorianod
Copy link
Contributor Author

Hi @camilamacedo86,

I've submitted a PR #1729 with the changes.

Let me know what you think about them.

Thank you.

@camilamacedo86
Copy link
Member

I would classify that as RFE instead of a bug. Otherwise, I am totally all in for that 👍
Really thank you for your contribution.

@camilamacedo86 camilamacedo86 added the triage/accepted Indicates an issue or PR is ready to be actively worked on. label Oct 20, 2020
@prafull01
Copy link
Contributor

prafull01 commented Oct 26, 2020

The PR with this RFE has been merged to master. We can close this one. @camilamacedo86
/close

@k8s-ci-robot
Copy link
Contributor

@prafull01: You can't close an active issue/PR unless you authored it or you are a collaborator.

In response to this:

The PR with this RFE has been merged to master. We can close this one.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

4 participants