fix #3294 #3303 exposing apigroups and apiresource

[shawkins]

Description

Adds client methods for apigroups and apiresources. Also consolidates existing logic about openshift adapting.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[centos-ci]

Can one of the admins verify this patch?

[shawkins]

This adds methods to the Client interface for the api resource and group information. Alternatives include introducing a Client.metadata() call and associated container api, but something like that hasn't been mentioned anywhere so it doesn't seem necessary.

[shawkins]

I'll address the openshift test next time I have a cluster up to test against. The compile errors though don't make sense to me.

[rohanKanojia]

I'll address the openshift test next time I have a cluster up to test against.

@shawkins : I'm not sure you're aware of this but you can easily get a free OpenShift Cluster with Red Hat Developer Sandbox[0]. I usually test OpenShift related stuff and it works okay.

The compile errors though don't make sense to me.

I'm not able to reproduce these errors as well.

[0] https://developers.redhat.com/developer-sandbox

[shawkins]

Looks like I made a simple mistake in the isAdaptable method. I've pushed a correction along with getting a single api group.

[shawkins]

@rohanKanojia the remaining exception is related to https://github.com/fabric8io/kubernetes-client/pull/3405/files#diff-32314261b10bfe7703677b8086d5a28ff2dd1d0a8dc1061cdaad58e22c091576L84 I've changed things to no longer swallow the exception - the mock server is not responding to /apis. Was the old code intentionally swallowing the exception or should I look at adding mock server support for this as well?

[rohanKanojia]

I think I did a mistake by swallowing the exception.

[shawkins]

@rohanKanojia I think things are good now. There was another boolean that needed flipped. The build still seems to be hitting those weird compile errors.

[shawkins]

@manusa rebased and still behaving oddly.

[manusa]

Fixed in #3487