Operator-sdk: Add command line option to upgrade k8s dependencies when bumping SDK version

[aravindhp]

Feature Request

Is your feature request related to a problem? Please describe.
Today if an operator author has to bump the SDK version in their operator project there is no way to automatically update the k8s dependencies in Gopkg.toml. Instead we have to manually copy the Gopkg.toml from the SDK source code.

Describe the solution you'd like
Add a command line option like operator-sdk update <version> or something to that effect to help the operator author update their Gopkg.toml.

/cc @hasbro17

[AlexNPavel]

@hasbro17 Do you think it would be reasonable to expose the Gopkg scaffold with a command to help with updating sdk generated projects and their dependencies? Handling different versions would be difficult in the same binary due to changing dependencies, but we could still regenerate the Gopkg.toml to match the current binary. Do you think that would cause any major problems?

[hasbro17]

It would be hard to support updating to any desired version(plus not sure that's useful since you wouldn't want to update to v0.0.6 if say you're using the binary for v0.0.7).

Like you suggested the simplest thing to do is to regenerate the existing Gopkg.toml file from the binary(like we do in operator-sdk new) and run dep ensure.
The only issue with overwriting the existing Gopkg.toml file is the user might have added other constraints that would be removed by overwriting the file.
For e.g https://github.com/operator-framework/operator-marketplace/blob/master/Gopkg.toml#L63-L70

I don't think the dep CLI supports modifying constraints in Gopkg.toml to a specific version/branch/revision. You have to do it manually. So we might have to parse and update only what's needed.

[hasbro17]

Or we have the convention to demarcate the Gopkg.toml file into two sections. One for SDK defined constraints. And the other for user defined constraints. Then we can safely overwrite the SDK constraints to update the dependencies.

And as a last option we can just output what the file should look like for the SDK constraints, and let the user use that output to modify their Gopkg.toml manually.

[shawn-hurley]

I was thinking about this, and I don't see a good way of doing this that will not be a constant source of bugs and frustration. We also have to keep in mind that modules will eventually be here and we probably want to support them.

I think the best solution here might be better documentation. A table that says X version of the SDK expects Y version of controller-runtime and so on. This would allow for 2 things.

1. Not having to manage this file after creation, which I think would be painful.
2. If I as user X believe I can use Z version of controller-runtime and would like to and I manage my dependencies my self, the SDK won't overwrite this or stop me. Any issues that arise from this are on the user as it is not what we were expecting.

Thoughts, am I over thinking this?

[hasbro17]

@shawn-hurley Yeah I agree there are issues with trying to overwrite and manage that file ourselves. We had similar issues with updating the deploy/operator.yaml file early on.

Docs would be good. Additionally how about we have the operator-sdk CLI print out all the dependencies that it expects(from the Gopkg.toml template for that version) e.g operator-sdk print-deps or something.
So then the user can just copy,paste and edit that output into their Gopkg.toml as needed.

That at least solves the problem of showing the user what deps the SDK expects.

[shawn-hurley]

I really like the idea of print-deps. Following on what do you think of having it be pretty print first somthing like:

Name                                Version
sigs.k8s.io/controller-runtime      v0.1.4

and then a flag that will ouput it in gopkg.toml format?

[[constraint]]
  name = "sigs.k8s.io/controller-runtime
  version = "v0.1.4"