Skip to content

[Feature request] Have a command to rename an existing API and code consuming it #560

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

Closed
cmoulliard opened this issue Oct 2, 2018 · 11 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. needs discussion

Comments

@cmoulliard
Copy link

What is the best approach to rename an API / CRD + operator's code ?

  • I have generated the code of my first API using this command operator-sdk new spring-boot-operator --api-version=springboot.snowdrop.me/v1alpha1 --kind=SpringBoot,
  • developed the code of the operator and
  • now I would like to rename the API to pkg/apis/component/v1alpha1 + CRD + ... files
@lli-hiya
Copy link

lli-hiya commented Oct 4, 2018

+1, I found it to be very hard to manually do this after it was generated using sdk.

@lilic lilic added the triage/support Indicates an issue that is a support question. label Oct 12, 2018
@lilic
Copy link
Member

lilic commented Oct 12, 2018

@cmoulliard you can for now just do a sed to rename it in the code. As far as I am aware there is no command for that in the operator-sdk. But if you can change the title of this to turn this question into a feature request instead?

@lilic lilic added kind/feature Categorizes issue or PR as related to a new feature. needs discussion and removed triage/support Indicates an issue that is a support question. labels Oct 12, 2018
@cmoulliard cmoulliard changed the title Best approach to rename an API + operator's code [Feature request] Have a command to rename an existing API and code consuming it Oct 16, 2018
@cmoulliard
Copy link
Author

Title renamed.

@riccardomc
Copy link

I'd be also interested in this.

@aravindhp
Copy link
Member

I also ran into this went wanting to change the Group and Version of my operator's CRD operator-framework/operator-marketplace#139. It is also preferable to be able to handle both versions in the same operator allowing code to be shared.

@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 20, 2019
@openshift-bot
Copy link

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci-robot openshift-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jul 20, 2019
@openshift-bot
Copy link

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-ci-robot
Copy link

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/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.

@hasbro17
Copy link
Contributor

I'm unsure if the SDK should support rewriting/renaming an existing API and all the associated manifest and controller files that are using that API.
It's much cleaner(although more painful) in my opinion to define a new type and controller and copy over the reconcile loop for the new type.

In any case this isn't on our radar at the moment (and why this was ignored for so long) so proposals are appreciated if this seems to be a common workflow.

wking added a commit to wking/cincinnati-operator that referenced this issue Nov 10, 2020
Generated with:

  $ git rm -rf .
  $ operator-sdk-v0.19.3 init --domain openshift.io --repo github.com/openshift/cincinnati-operator
  $ operator-sdk-v0.19.3 create api --group updateservice --version v1 --kind UpdateService --resource --controller
  $ sed -i 's/cincinnati-operator/update-service-operator/' config/default/kustomization.yaml
  $ git add -A .gitignore *
  The following paths are ignored by one of your .gitignore files:
  bin
  hint: Use -f if you really want to add them.
  hint: Turn this message off by running
  hint: "git config advice.addIgnoredFile false"

We don't want to commit bin, so the warning is fine.  This regenerates
the file with the scaffolding for the new API name, and we can merge
it into our main branch to update the type there.  From [1],
regenerating a new API is the prefered migration approach, and running
the '... create api ...' call directly in the main branch gave:

  ...
  vet: functests/utils.go:79:53: SchemeGroupVersion not declared by package v1beta1
  make: *** [vet] Error 1
  Error: failed to create API with version "3-alpha": exit status 2
  ...
  FATA[0006] failed to create API with version "3-alpha": exit status 2

[1]: operator-framework/operator-sdk#560 (comment)
wking added a commit to wking/cincinnati-operator that referenced this issue Nov 12, 2020
Generated with:

  $ git rm -rf .
  $ operator-sdk-v0.19.3 init --domain openshift.io --repo github.com/openshift/cincinnati-operator
  $ operator-sdk-v0.19.3 create api --group updateservice --version v1 --kind UpdateService --resource --controller
  $ sed -i 's/cincinnati-operator/update-service-operator/' config/default/kustomization.yaml
  $ git add -A .gitignore *
  The following paths are ignored by one of your .gitignore files:
  bin
  cover.out
  hint: Use -f if you really want to add them.
  hint: Turn this message off by running
  hint: "git config advice.addIgnoredFile false"

We don't want to commit bin or cover.out, so the warning is fine.
This regenerates the file with the scaffolding for the new API name,
and we can merge it into our main branch to update the type there.
From [1], regenerating a new API is the prefered migration approach,
and running the '... create api ...' call directly in the main branch
gave:

  ...
  vet: functests/utils.go:79:53: SchemeGroupVersion not declared by package v1beta1
  make: *** [vet] Error 1
  Error: failed to create API with version "3-alpha": exit status 2
  ...
  FATA[0006] failed to create API with version "3-alpha": exit status 2

[1]: operator-framework/operator-sdk#560 (comment)
@buffalo1024
Copy link

Met this problem too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. needs discussion
Projects
None yet
Development

No branches or pull requests

9 participants