-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Clarify files to edit & not edit to ease upgrade #773
Comments
For reference here's what a simple go operator project looks like with a single added api and controller.
Since the SDK is still alpha, it's hard to answer this question with a strong guarantee. To answer your specific questions:
Using the example about, I think the following are expected to be changed by an operator developer:
Outside of those, do you have a use case for changing the other *.go files?
The SDK is primarily concerned that these files exist in their scaffolded location and that they are valid syntactically. For For the |
Thanks for the reply. I don't currently have a good reason to change the other files. I think this is sufficient for my purposes. |
@JohnStrunk once we reach non-alpha status, only major version changes, ex. v1.x.x -> v2.x.x, will break compatibility with old operator projects. Because we're in alpha, changes to operator project file structure can still occur with minor version changes, ex. v0.1.x -> v0.2.x. We will be sure to make documentation available for migration when we make breaking changes, like we did for v0.0.x -> v0.1.0. Hopefully that helps. If you're satisfied I'll close this issue. |
That works for me. My takeaway is... Non-breaking upgrades amount to:
Breaking upgrades will have specific documentation, but in general, I can expect to re-run Assuming this is approximately correct, I'm good w/ closing this. |
Type of question
Are you asking about community best practices, how to implement a specific feature, or about general context and help around the operator-sdk?
Best practices
Question
In reading the docs, it's clear that the operator developer should modify the
*_types.go
and*_controller.go
files for their CRDs. What isn't as clear is what other files should or should not be modified.Presumably as the SDK evolves, the template code that is created by
operator-sdk new
will change. What are good recommendations for operator developers to keep in mind so that it remains easy to upgrade the SDK? For example:*.go
files to be owned by the SDK and avoid modifying them (with the exception of the two mentioned above)?The text was updated successfully, but these errors were encountered: