Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Kubernetes configured via kubeconfig #46244
What does this PR do?
Newer versions of python-kubernetes (>2.0) has changed a lot in the way they want to have the configuration parameters. Also new types of authentication were added and more will come in near future.
The only future-proof way seems to be to provide the full
What issues does this PR fix or reference?
Mainly it support new python-kubernetes library as requested in #44701 .
Configuring via kubeconfig was requested in #43514 .
Last but not least this PR make it also possible to provide the full kubeconfig as data to overwrite configured kubeconfig like requested in #46086 .
Configuring the cluster access and authentication was possible via single values:
This will be replaced by just configure via
Yes (adapted the existing)
Commits signed with GPG?
2017.7 - add warning about config option change : #46320
@mcalmer Since Kubernetes is moving pretty quickly and this change will make it easier to maintain this module moving forward, I am fine with changing these configuration items in a feature release. However, I want to make sure that this is documented appropriately - there should be warnings at the top of the module that these configuration options have changed, and it probably would be good to add this to the
It would also be prudent to add some deprecation warnings to the old configuration style in the 2017.7 branch.
@mcalmer I don't have any doc examples handy off the top of my head, but something along the lines of "The following configuration options have been removed in favor of x, y, z" and list out which items were removed (and why they were removed) and what to use instead. For example, if someone is using 2017.7.x or 2018.3.x and they upgrade and now their modules/states don't work, they need to know why and how to remediate the issue. This needs to be added to the Fluorine release notes.
I also would like to see a PR implementing the
@rallytime I have adapted the warning message here, but I am not sure if using warn_until in older versions is a good idea. These messages would just pollute the logfiles with tons of warnings and
So I would like to go with just a message in the docs.
An alternative would be to backport the feature and try to make both options available - let's say in oxygen. Then warn_until would make sense because the admin could switch to the new config style and prevent the warnings.
What do you prefer?
referenced this pull request
Mar 3, 2018
@mcalmer I would say, we should have indeed some sort of warning and a proper deprecation process. For this we actually using deprecation mechanism and it is just a decorator on top of a function. This decorator makes possible to retire old signatures without losing the API names. Full doc of which you can read here. This is something like:
def _stuff(): 'This has old signature. Underscore in front is hiding it initially' @with_deprecated(globals(), "Beryllium") def stuff(foo=None): 'This has new signature'
Then, depending on what user wants to use (new or old Kubernetes), they just configure the minion accordingly.
@mcalmer technically, surely it will. It is just in this case it is equivalent to:
@with_deprecated(globals(), "Fluorine") def foo(**kwargs): ... # all the real code _foo = foo
The problem is here that due to the nature of the
def _version_blocker(func, **kwargs): ''' This will raise an exception if kubernetes is more than 2.0, for example. ''' if _get_version_of_kubernetes() > (2, 0): # Check what API we are linked to raise CommandExecutionError('Sticky bit become loose!') return func(**kwargs) @with_deprecated(globals(), "Fluorine") def foo(**kwargs): ... # all the real code _foo = lambda **kwargs: _version_blocker(foo, **kwargs) @with_deprecated(globals(), "Fluorine") def bar(**kwargs): ... # all the real code _bar = lambda **kwargs: _version_blocker(bar, **kwargs)
Well, you've got the idea.
@mcalmer Regarding your questions about a proper deprecation process - what if we keep the old way of doing things for now with a
@rallytime - It is not easy as new python-kubernetes client lib do not support this old way.