OSD-26415: Add update-pull-secret cmd. Updates, fixes to transfer-owner cmd.

[nephomaniac]

This PR attempts to allow a user to update a cluster's pull secret w/o transferring ownership for both classic and HCP clusters. (closes PR#705)

• This adds a new command 'osdctl cluster update-pull-secret'. This cmd is a wrapper re-using the transfer-owner's pullsecret update functions and general flow, leveraging the hidden'--pull-secret-only' (bool) flag.
• When 'updating the pull secret only' is used the utility will now exit after the pull secret is updated with the account's OCM accessToken values.
• The pull secret only op prompts user to choose to send an internal service log before the operation begins, and prompts to send a customer service log after the operation completes.
• This adds additional programmatic checks/comparisons of the resulting on cluster pull-secret auths for the end user to review. ( transfer-owner and update-pull-secret)
• The new programmatic checks/comparisons may negate the need for printing to the terminal for visual comparison. Previously this util printed the secret data to the terminal, this PR changes this to instead warn + prompt the user to choose whether or not to print the raw data for the optional visual inspection. ( transfer-owner and update-pull-secret)
• Updates to existing 'Dry-run' when transferring-owner. dry-run should now skip certain operations: does not update pull-secret, does not roll pods, and now passes 'dryrun' flag to service logs ops. ( transfer-owner and update-pull-secret)
• Additional information and formatting of errors. This includes warnings related to permissions (ie region-lead), logging the requests/operations along with their status upon failures/errors, and attempts to include general SOP recommendations for specific errors( transfer-owner and update-pull-secret)
• Block execution against HCP clusters. Add refs to docs/sops.

Example usage:

osdctl cluster update-pull-secret -h
Update cluster pullsecret with current OCM accessToken data(to be done by Region Lead)

Usage:
  osdctl cluster update-pull-secret [flags]

Examples:

  # Update Pull Secret's OCM access token data
  osdctl cluster update-pull-secret --cluster-id 1kfmyclusteristhebesteverp8m --reason "Update PullSecret per pd or jira-id"


Flags:
  -C, --cluster-id string   The Internal Cluster ID/External Cluster ID/ Cluster Name
  -d, --dry-run             Dry-run - show all changes but do not apply them
  -h, --help                help for update-pull-secret
      --reason string       The reason for this command, which requires elevation, to be run (usually an OHSS or PD ticket

[openshift-ci-robot]

@nephomaniac: This pull request references OSD-26415 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set.

Details

In response to this:

This PR attempts to allow a user to update a cluster's pull secret w/o transferring ownership for both classic and HCP clusters. (closes PR#705)

• This adds a new command 'osdctl cluster update-pull-secret'. This cmd is a wrapper re-using the transfer-owner's pullsecret update functions and general flow, leveraging the hidden'--pull-secret-only' (bool) flag.
• When 'updating the pull secret only' is used the utility will now exit after the pull secret is updated with the account's OCM accessToken values.
• The pull secret only op prompts user to choose to send an internal service log before the operation begins, and prompts to send a customer service log after the operation completes.
• This adds additional programmatic checks/comparisons of the resulting on cluster pull-secret auths for the end user to review. ( transfer-owner and update-pull-secret)
• The new programmatic checks/comparisons may negate the need for printing to the terminal for visual comparison. Previously this util printed the secret data to the terminal, this PR changes this to instead warn + prompt the user to choose whether or not to print the raw data for the optional visual inspection. ( transfer-owner and update-pull-secret)
• Updates to existing 'Dry-run' when transferring-owner: Do not update pull-secret, roll pods, and pass 'dryrun' flag to service logs . ( transfer-owner and update-pull-secret)
• Additional information and formatting of errors. ( transfer-owner and update-pull-secret)

Example usage:

osdctl cluster update-pull-secret -h
Update cluster pullsecret with current OCM accessToken data(to be done by Region Lead)

Usage:
 osdctl cluster update-pull-secret [flags]

Examples:

 # Update Pull Secret's OCM access token data
 osdctl cluster update-pull-secret --cluster-id 1kfmyclusteristhebesteverp8m --reason "Update PullSecret per pd or jira-id"


Flags:
 -C, --cluster-id string   The Internal Cluster ID/External Cluster ID/ Cluster Name
 -d, --dry-run             Dry-run - show all changes but do not apply them
 -h, --help                help for update-pull-secret
     --reason string       The reason for this command, which requires elevation, to be run (usually an OHSS or PD ticket

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: nephomaniac
Once this PR has been reviewed and has the lgtm label, please assign iamkirkbater for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[nephomaniac]

/label tide/merge-method-squash

[openshift-ci-robot]

@nephomaniac: This pull request references OSD-26415 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set.

Details

In response to this:

This PR attempts to allow a user to update a cluster's pull secret w/o transferring ownership for both classic and HCP clusters. (closes PR#705)

• This adds a new command 'osdctl cluster update-pull-secret'. This cmd is a wrapper re-using the transfer-owner's pullsecret update functions and general flow, leveraging the hidden'--pull-secret-only' (bool) flag.
• When 'updating the pull secret only' is used the utility will now exit after the pull secret is updated with the account's OCM accessToken values.
• The pull secret only op prompts user to choose to send an internal service log before the operation begins, and prompts to send a customer service log after the operation completes.
• This adds additional programmatic checks/comparisons of the resulting on cluster pull-secret auths for the end user to review. ( transfer-owner and update-pull-secret)
• The new programmatic checks/comparisons may negate the need for printing to the terminal for visual comparison. Previously this util printed the secret data to the terminal, this PR changes this to instead warn + prompt the user to choose whether or not to print the raw data for the optional visual inspection. ( transfer-owner and update-pull-secret)
• Updates to existing 'Dry-run' when transferring-owner. dry-run should now skip certain operations: does not update pull-secret, does not roll pods, and now passes 'dryrun' flag to service logs ops. ( transfer-owner and update-pull-secret)
• Additional information and formatting of errors. ( transfer-owner and update-pull-secret)

Example usage:

osdctl cluster update-pull-secret -h
Update cluster pullsecret with current OCM accessToken data(to be done by Region Lead)

Usage:
 osdctl cluster update-pull-secret [flags]

Examples:

 # Update Pull Secret's OCM access token data
 osdctl cluster update-pull-secret --cluster-id 1kfmyclusteristhebesteverp8m --reason "Update PullSecret per pd or jira-id"


Flags:
 -C, --cluster-id string   The Internal Cluster ID/External Cluster ID/ Cluster Name
 -d, --dry-run             Dry-run - show all changes but do not apply them
 -h, --help                help for update-pull-secret
     --reason string       The reason for this command, which requires elevation, to be run (usually an OHSS or PD ticket

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@nephomaniac: This pull request references OSD-26415 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set.

Details

In response to this:

This PR attempts to allow a user to update a cluster's pull secret w/o transferring ownership for both classic and HCP clusters. (closes PR#705)

• This adds a new command 'osdctl cluster update-pull-secret'. This cmd is a wrapper re-using the transfer-owner's pullsecret update functions and general flow, leveraging the hidden'--pull-secret-only' (bool) flag.
• When 'updating the pull secret only' is used the utility will now exit after the pull secret is updated with the account's OCM accessToken values.
• The pull secret only op prompts user to choose to send an internal service log before the operation begins, and prompts to send a customer service log after the operation completes.
• This adds additional programmatic checks/comparisons of the resulting on cluster pull-secret auths for the end user to review. ( transfer-owner and update-pull-secret)
• The new programmatic checks/comparisons may negate the need for printing to the terminal for visual comparison. Previously this util printed the secret data to the terminal, this PR changes this to instead warn + prompt the user to choose whether or not to print the raw data for the optional visual inspection. ( transfer-owner and update-pull-secret)
• Updates to existing 'Dry-run' when transferring-owner. dry-run should now skip certain operations: does not update pull-secret, does not roll pods, and now passes 'dryrun' flag to service logs ops. ( transfer-owner and update-pull-secret)
• Additional information and formatting of errors. This includes warnings related to permissions (ie region-lead), logging the requests/operations along with their status upon failures/errors, and attempts to include general SOP recommendations for specific errors( transfer-owner and update-pull-secret)

Example usage:

osdctl cluster update-pull-secret -h
Update cluster pullsecret with current OCM accessToken data(to be done by Region Lead)

Usage:
 osdctl cluster update-pull-secret [flags]

Examples:

 # Update Pull Secret's OCM access token data
 osdctl cluster update-pull-secret --cluster-id 1kfmyclusteristhebesteverp8m --reason "Update PullSecret per pd or jira-id"


Flags:
 -C, --cluster-id string   The Internal Cluster ID/External Cluster ID/ Cluster Name
 -d, --dry-run             Dry-run - show all changes but do not apply them
 -h, --help                help for update-pull-secret
     --reason string       The reason for this command, which requires elevation, to be run (usually an OHSS or PD ticket

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[nephomaniac]

/retest

[openshift-ci-robot]

@nephomaniac: This pull request references OSD-26415 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set.

Details

In response to this:

This PR attempts to allow a user to update a cluster's pull secret w/o transferring ownership for both classic and HCP clusters. (closes PR#705)

• This adds a new command 'osdctl cluster update-pull-secret'. This cmd is a wrapper re-using the transfer-owner's pullsecret update functions and general flow, leveraging the hidden'--pull-secret-only' (bool) flag.
• When 'updating the pull secret only' is used the utility will now exit after the pull secret is updated with the account's OCM accessToken values.
• The pull secret only op prompts user to choose to send an internal service log before the operation begins, and prompts to send a customer service log after the operation completes.
• This adds additional programmatic checks/comparisons of the resulting on cluster pull-secret auths for the end user to review. ( transfer-owner and update-pull-secret)
• The new programmatic checks/comparisons may negate the need for printing to the terminal for visual comparison. Previously this util printed the secret data to the terminal, this PR changes this to instead warn + prompt the user to choose whether or not to print the raw data for the optional visual inspection. ( transfer-owner and update-pull-secret)
• Updates to existing 'Dry-run' when transferring-owner. dry-run should now skip certain operations: does not update pull-secret, does not roll pods, and now passes 'dryrun' flag to service logs ops. ( transfer-owner and update-pull-secret)
• Additional information and formatting of errors. This includes warnings related to permissions (ie region-lead), logging the requests/operations along with their status upon failures/errors, and attempts to include general SOP recommendations for specific errors( transfer-owner and update-pull-secret)
• Block execution against HCP clusters. Add refs to docs/sops.

Example usage:

osdctl cluster update-pull-secret -h
Update cluster pullsecret with current OCM accessToken data(to be done by Region Lead)

Usage:
 osdctl cluster update-pull-secret [flags]

Examples:

 # Update Pull Secret's OCM access token data
 osdctl cluster update-pull-secret --cluster-id 1kfmyclusteristhebesteverp8m --reason "Update PullSecret per pd or jira-id"


Flags:
 -C, --cluster-id string   The Internal Cluster ID/External Cluster ID/ Cluster Name
 -d, --dry-run             Dry-run - show all changes but do not apply them
 -h, --help                help for update-pull-secret
     --reason string       The reason for this command, which requires elevation, to be run (usually an OHSS or PD ticket

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

@nephomaniac: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closed this PR.

Details

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.