util: add kernel version checks libraries

[iamniting]

These funcs allow user to check the kernel support on ocp cluster

Signed-off-by: Nitin Goyal nigoyal@redhat.com

https://issues.redhat.com/browse/RHSTOR-7293

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: iamniting

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [iamniting]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[iamniting]

/test ocs-operator-bundle-e2e-aws

[nixpanic]

A unit test that shows how these functions work together would be very welcome.

[nixpanic]

This version checking is pretty much RHEL specific, this is fine but could be noted somewhere.

Added one question, otherwise it looks good to me, thanks.

[iamniting]

This version checking is pretty much RHEL specific, this is fine but could be noted somewhere.

Added one question, otherwise it looks good to me, thanks.

As far as we are concerned with rhel and coreos. As far as I remember, we discussed that it is going to be the same for both. Pls correct me if I am wrong.

[nixpanic]

As far as we are concerned with rhel and coreos. As far as I remember, we discussed that it is going to be the same for both. Pls correct me if I am wrong.

That is correct. Red Hat CoreOS is based on RHEL, it has the same kernel builds and versioning.

[leelavg]

better be explicit in the filename that we are dealing w/ kernel version as we already have a version folder at the root and during imports it helps to distinguish?

[iamniting]

Done

[leelavg]

can you add a sample unit test on how you intend that one should use these util funcs? isn't the intention just to export a single func whether I can rotate the ceph key or not?

[iamniting]

Done

[rohan47]

@iamniting @leelavg ocs-client-operator will also require this functionality to send the kernel version of nodes to the provider,
will it make sense to move this changes to provider api?
else this will have to be copied to ocs-client-operator as well

[iamniting]

@iamniting @leelavg ocs-client-operator will also require this functionality to send the kernel version of nodes to the provider, will it make sense to move this changes to provider api? else this will have to be copied to ocs-client-operator as well

You mean under services/provider/api as a new directory

[rohan47]

@iamniting @leelavg ocs-client-operator will also require this functionality to send the kernel version of nodes to the provider, will it make sense to move this changes to provider api? else this will have to be copied to ocs-client-operator as well

You mean under services/provider/api as a new directory

As per discussion with Ohad, this move should not be done.