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

Deprecate 'generate openapi', add 'generate crds' #2276

Merged

Conversation

joelanford
Copy link
Member

@joelanford joelanford commented Nov 27, 2019

Description of the change:
This PR deprecates the operator-sdk generate openapi command and adds operator-sdk generate crds

Motivation for the change:
The zz_generated.openapi.go files are rarely required, so the SDK should be less opinionated about creating them for users.

This change also aligns the SDK more closely with kubebuilder, which does not generate zz_generated.openapi.go by default.

@openshift-ci-robot openshift-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Nov 27, 2019
CHANGELOG.md Outdated
@@ -12,10 +12,12 @@
- Updated `pkg/test/e2eutil.WaitForDeployment()` and `pkg/test/e2eutil.WaitForOperatorDeployment()` to successfully complete waiting when the available replica count is _at least_ (rather than exactly) the minimum replica count required. ([#2248](https://github.com/operator-framework/operator-sdk/pull/2248))
- Replace in the Ansible based operators module tests `k8s_info` for `k8s_facts` which is deprecated. ([#2168](https://github.com/operator-framework/operator-sdk/issues/2168))
- Upgrade the Ansible version from `2.8` to `2.9` on the Ansible based operators image. ([#2168](https://github.com/operator-framework/operator-sdk/issues/2168))
- **Breaking change:** Renamed `operator-sdk generate openapi` to `operator-sdk generate crds`. ([#2276](https://github.com/operator-framework/operator-sdk/pull/2276))
Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure if we should move forward with. See that kubebuilder is not supporting it and users are asking for here and a track issue from them here which in my understand shows that require it as well.

Copy link
Member

@estroz estroz Nov 27, 2019

Choose a reason for hiding this comment

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

The first issue is fair; based on feedback in #2042 some users do not use zz_generated.openapi.go, which, on top of it not being necessary for API code unlike zz_generated.deepcopy.go, is why I decided to push for removing it. We should either:

  1. Add documentation on building and using openapi-gen to generate the files yourself, which is fairly straightforward.
  2. Keep generate openapi as a command but move CRD generation into generate crd.

I vote for option 1 since we can offer Go OpenAPI code by wrapping openapi-gen in a Makefile recipe (in the future).

The second issue describes something we do not currently support in API code right now since we use the same tool as kubebuilder to generate CRDs, controller-gen from controller-tools. Generating zz_generated.openapi.go does not change the state of supported annotations for CRD manifest validation in the SDK.

We agreed to make this change because it de-couples CRD generation from OpenAPI spec generation, two different albeit related processes. This change will help users debug errors more easily as well.

Copy link
Member Author

Choose a reason for hiding this comment

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

Another option would be to add generate crds but keep generate openapi as is and deprecate it. We could hide it from the help output and log a deprecation message when it is called.

Then in a later version it could be removed.

Copy link
Member Author

Choose a reason for hiding this comment

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

And we could/should still do one of the options @estroz suggested.

Copy link
Member

Choose a reason for hiding this comment

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

@joelanford I like the combination of what you suggested and my first option. The docs referencing Go OpenAPI spec generation (I believe the only documentation doing so is the one being changed in this PR already) should warn that the subcommand is deprecated and users should switch to installing and running openapi-gen themselves if they still want that spec file.

Copy link
Member

Choose a reason for hiding this comment

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

I think the idea of phasing out the old command with a deprecation warning.

@estroz @joelanford we need to make it easy to download and use the openapi-gen command if that is the guidance, we either do it for the user and attempt to install the binary into a known location and give them the option to supply their own openapi-gen.

Could we vendor the openapi-gen command and use it in the operator-sdk command? was that an option already looked?

Copy link
Member

Choose a reason for hiding this comment

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

@shawn-hurley we currently vendor the exposed openapi-gen generator in generate openapi. If we want to install this binary for the user, I suggest this as the first candidate for a Makefile:

openapi-gen:
	which ./bin/openapi-gen > /dev/null || go build -o ./bin/openapi-gen k8s.io/kube-openapi/cmd/openapi-gen
	./bin/openapi-gen ...

Otherwise documentation to the effect of the above script should suffice. I'd rather have documentation than a make recipe.

Copy link
Member Author

Choose a reason for hiding this comment

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

By the way, our vendoring of the code generation libraries is what causes the GOROOT and panic issues described in this issue: #1854 (comment)

If we direct users to build openapi-gen from source like Eric suggests, we'll help them avoid that issue, at least for the openapi generation (I think it will still be an issue for deepcopy generation).

Copy link
Member Author

Choose a reason for hiding this comment

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

Alright, updated the PR to keep generate openapi, but to hide it from help and deprecate it.

@@ -134,6 +134,21 @@ pkg/apis/app/v1alpha1/

### openapi
Copy link
Member

Choose a reason for hiding this comment

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

Side note: should we remove this doc entirely now that we auto-generate CLI docs under doc/cli?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, probably.

@theishshah is there anything else we need to do before we remove it?

Copy link
Contributor

@camilamacedo86 camilamacedo86 Dec 4, 2019

Choose a reason for hiding this comment

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

If we are just deprecated the command then:
IHMO:

  • We should not remove/change the docs
  • We just need to add on top of the func used by it which will be removed the comments that it is deprecated for have the func strikethrough as:

Screenshot 2019-12-04 at 21 39 44

Comment: // Deprecated: xpto

  • Also, we need to provide a doc with the info for users knowhow them can customize the projects to still be able to gen and use the open API. Will be it done in another PR?

Then, should not be better have a PR to deprecated and one to add the new command?

Copy link
Member

@estroz estroz Dec 4, 2019

Choose a reason for hiding this comment

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

We want existing users who have written scripts around generate openapi to still be able to use the command while they migrate to generate crds, but new users to use generate crds. By removing docs we can ensure visibility of generate crds without confusing anyone.

The "documentation" explaining deprecation and new behavior is here. We can remove doc/sdk-cli-reference.md in a follow-up PR.

I'm ok with a deprecation comment, like it is used here.

Copy link
Member Author

Choose a reason for hiding this comment

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

I can put the GoDoc deprecation comments on the functions used for generate openapi but they won't serve much purpose since none of the functions are public. IMO the big reason to add the deprecation comments is to signal to users that the API is changing, but we're the only users of these private functions.

This PR isn't really a Go code API deprecation. It's a deprecation of a CLI subcommand.

Copy link
Contributor

@camilamacedo86 camilamacedo86 Dec 5, 2019

Choose a reason for hiding this comment

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

Hi @joelanford,

The comments would be helpful to us know what should not be used so long and removed soon. Regards the command, a notice output as it was done here for example would be more appropriate.

c/c @estroz

Copy link
Member Author

Choose a reason for hiding this comment

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

This PR includes a deprecation notice in the output when generate openapi is run. See here.

hack/generate/gen-cli-doc.go Outdated Show resolved Hide resolved
Copy link
Member

@estroz estroz left a comment

Choose a reason for hiding this comment

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

/lgtm

@shawn-hurley you're ok with the alternate method to generate zz_generated.openapi.go?

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Dec 3, 2019
@openshift-ci-robot openshift-ci-robot removed the lgtm Indicates that a PR is ready to be merged. label Dec 4, 2019
Copy link
Member

@shawn-hurley shawn-hurley left a comment

Choose a reason for hiding this comment

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

This all makes sense to me now thanks!

"github.com/spf13/cobra"
)

func newGenerateCRDsCmd() *cobra.Command {
Copy link
Member

Choose a reason for hiding this comment

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

can we add a flag for passing in the location of the CRD's?

Copy link
Member Author

Choose a reason for hiding this comment

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

Once this merges, I'll make an issue to discuss this idea for a follow-up.

@joelanford joelanford changed the title *: remove zz_generated.openapi.go, rename 'generate openapi' to 'generate crds' Deprecate 'generate openapi', add 'generate crds' Dec 4, 2019
joelanford added a commit to joelanford/operator-sdk that referenced this pull request Dec 4, 2019
Copy link
Contributor

@camilamacedo86 camilamacedo86 left a comment

Choose a reason for hiding this comment

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

.

Copy link
Contributor

@camilamacedo86 camilamacedo86 left a comment

Choose a reason for hiding this comment

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

/lgtm
/approved

Great 👍

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Dec 5, 2019
@joelanford joelanford merged commit 7cc38cc into operator-framework:master Dec 5, 2019
@joelanford joelanford deleted the remove-zz-generated-openapi branch December 5, 2019 16:36
slagle added a commit to slagle/keystone-operator that referenced this pull request Jul 22, 2020
operator-sdk no longer generates the openapi file[1], so remove it from the
repo. If we want to continue offering it, we'll need to use openapi-gen
directly[2].

[1] operator-framework/operator-sdk#2276
[2] https://github.com/kubernetes/kube-openapi

Signed-off-by: James Slagle <jslagle@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants