uncap kubernetes version

[prometheanfire]

At the moment openshift-restclient-python is the only package requiring a specific version of the kubernetes python library. This causes co-installability issues. This blocks others from using new versions of kubernetes until you update/release. At that point they'd have to switch to the new version as you only support one version at a time.

http://logs.openstack.org/04/657204/3/check/requirements-tox-py27-check-uc/0d243cf/job-output.txt.gz#_2019-05-07_14_43_24_123381

specifically the following line

ContextualVersionConflict: (kubernetes 9.0.0 (/home/zuul/src/opendev.org/openstack/requirements/.tox/py27-check-uc/lib/python2.7/site-packages), Requirement.parse('kubernetes<9.0.0,>=8.0.0'), set(['openshift']))

Would it be possible to uncap the version of kubernetes you support. If you want to limit the version in your installs that is what constraints are for, see the following for an example.

https://github.com/openstack/requirements/blob/16e8fd6a0f179e3cad0ae2197a5c1be18ada2ea1/upper-constraints.txt#L427
https://github.com/openstack/requirements/blob/16e8fd6a0f179e3cad0ae2197a5c1be18ada2ea1/tox.ini#L19

if 1.3.0 comes out for foo (see below) the following would happen.

#in requirements.txt
foo>=1.0.0
#in constraints.txt
foo===1.2.3

pip install foo -r requirements.txt -c constraints.txt
# would install 1.2.3 even though 1.3.0 is done

[fabianvf]

so I think the reason we pinned the version in the past is that there were breaking changes that affected our client and broke a few projects, and since the API was only guaranteed at a major version level we wanted to make sure we didn't have random breakages again when a new release came out. That being said we should definitely get the 0.9.0 release (which is pinned to 9.x) out the door so that we at least have a version out that supports every release of the kubernetes client. If there's a cleverer way to solve this I'd be happy to hear it but I think if we just remove the version constraints it might end up causing more pain than it saves.

[prometheanfire]

Ya, I'm not sure the state of your testing, but would adding tox jobs for each kubernetes version (and one uncapped) work for coverage?

I see 10.0.0a1 on pypi as of April 4th, so that's coming soon too.

[prometheanfire]

looks like urllib3 is being blocked by openshift as well

2019-05-24 21:06:58.590007 | ubuntu-bionic | ContextualVersionConflict: (urllib3 1.25.3 (/home/zuul/src/opendev.org/openstack/requirements/.tox/py27-check-uc/lib/python2.7/site-packages), Requirement.parse('urllib3<1.25'), set(['openshift']))

[fabianvf]

I think we'll continue manually updating to track the kubernetes-client version, as breaking changes remain a concern (ie, kubernetes-client/python#974)

[prometheanfire]

I think we removed the dep on openshift so we don't have this problem anymore.