diff options
author | Jake Hunsaker <jhunsake@redhat.com> | 2022-04-05 11:32:11 -0400 |
---|---|---|
committer | Jake Hunsaker <jhunsake@redhat.com> | 2022-04-08 12:02:33 -0400 |
commit | ce289a3ae7101a898efdb84ddfd575576ba5819b (patch) | |
tree | 9722371c6b3c092076e4d097e28a242f88a3f5b4 /requirements.txt | |
parent | 8cdc77c484c12b5ecaa901c892bc5799ef468e32 (diff) | |
download | sos-ce289a3ae7101a898efdb84ddfd575576ba5819b.tar.gz |
[ocp, openshift] Re-align API collection options and rename option
Previously, in #2888, the `openshift` plugin was extended to allow API
collections by using a default-available kubeconfig file rather than
relying on user-provided tokens. This also included flipping the default
value of the `no-oc` plugin option to `True` (meaning do not collect API
output by default).
This worked for the plugin, but it introduced a gap in `sos collect`
whereby the cluster profile could no longer reliably enable API
collections when trying to leverage the new functionality of not
requiring a user token.
Fix this by updating the cluster profile to align with the new
default-off approach of API collections.
Along with this, add a toggle to the cluster profile directly to allow
users to toggle API collections on or off (default off) directly. This
is done via a new `with-api` cluster option (e.g. `-c ocp.with-api`).
Further, rename the `openshift` plugin option from `no-oc` to
`with-api`. This change not only makes the option use case far more
obvious, it will also align the use of the option to both `collect` and
`report` so that users need only be aware of a single option for either
method.
The cluster profile also has logic to detect which plugin option,
`no-oc` or `with-api` to use based on the (RHEL) sos version installed
on the nodes being inspected by the `ocp` cluster profile.
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
Diffstat (limited to 'requirements.txt')
0 files changed, 0 insertions, 0 deletions