Improve the error output of the declarative plugin

[mariuskimmina]

What do you want to happen?

As discussed in #2562 the error output of the declarative plugin could be improved.

Errors such as:

 kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins declarative.go.kubebuilder.io/v1
Error: unknown flag: --domain

Can be confusing to the user. I'll work on this myself, just creating the issue to track the work.

Extra Labels

No response

[mariuskimmina]

/assign

[camilamacedo86]

@mariuskimmina,

Could you please improve the description and add: When the error/problem is faced? What are the circumstances? What is the behaviour expected Then, what is the behaviour faced Also, what is the proposed solution for this one?

[mariuskimmina]

The problem occurs when people try to use the declarative plugin to initialise a new project

for example, the following command looks like it should be correct

kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins declarative.go.kubebuilder.io/v1

But the user will get the following error

Error: unknown flag: --domain

Obviously the domain flag does exist, the real problem is, that the declarative plugin can't be used alone - if we use the same command but add another plugin:

kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins go.kubebuilder.io/v3,declarative.go.kubebuilder.io/v1

then the command works. But this might not be obvious to a new user and the error in this case is not helpfull at all.

Idealy we would want an error here indicating that the kubebuilder plugin can't be used alone.

[camilamacedo86]

Thank you for the clarifications. See that each plugin must know what is required for its self-work and not about other plugins explicitly.

For the error: Error: unknown flag: --domain

It happens because the declarative plugin does not have this flag implemented at all.

However, I understand that we might have a hall for improvements here. We might be able to improve the plugin helpers, errors and etc in order to clarify what is or not available, what is a requirement or not for this plugin as improving its messages.

[mariuskimmina]

Yes I understand, I already tried to work on this and saw that it wasn't as simple as adjusting just the plugin code itself. That being sad, I would still be looking further into this and see if I can make some improvements - just going to take longer than I originally anticipated.

[rashmigottipati]

@mariuskimmina can you please propose the improvements you are suggesting to handle such scenarios?

[mariuskimmina]

So, I think the problem is that when we are using the declarative plugin alone, such as an in this command

kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins declarative.go.kubebuilder.io/v1

Which results in the error Error: unknown flag: --domain because the plugin does not have this flag. But I would suggest that the plugin shouldn't try to run at all - instead there should be an error explaining that the declarative plugin can not be used without another plugin. I'm not sure how to properly implement this tho and I am also currently more focused on another project over at CoreDNS, thus I would unassign myself from this issue for now. If noone else wants to pick this up, feel free to close it.

[NikhilSharmaWe]

@camilamacedo86 Do we need to work on this?

If yes, do we want to:

• Return error whenever the declarative plugin is used without another plugin. And when flag --domain is also used, we should return both errors (declarative plugin and unknown flag).
• Not run the command when an unknown flag is used, even if another plugin is present other than a declarative one. Like in this case kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins go.kubebuilder.io/v3,declarative.go.kubebuilder.io/v1, it is mentioned that this command runs without any error.

[camilamacedo86]

Hi @NikhilSharmaWe,

You do not need to any issue :-). However, if you want to contribute to this one, I am not sure how would be the best approach to address improvements regarding this case.

As part of this issue, we are still required to do an assessment and see if we could propose any improvement/change to address this one. It might also involve seeing if the solution approach could be a more generic design where we could allow the definition, for example, pre-requirements for the plugins. (not sure if that would be the case)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.