Feat(SREP-202): Add new hcp forceupgrade command #830
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: typeid The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
typeid
force-pushed
the
add-force-upgrading-option
branch
from
b54a236 to
bf0df96
Compare
| Long: `Schedule forced control plane upgrades for ROSA HCP clusters. This command skips all validation checks | ||
| (critical alerts, cluster conditions, node pool checks, and version gate agreements). | ||
|
|
||
| ⚠️ REQUIRES ForceUpgrader PERMISSIONS ⚠️ |
There was a problem hiding this comment.
Should we provide some link how to get those?
There was a problem hiding this comment.
This is an internal permission within AMS so I would keep that within private document that in the separate ops-sop SOP (in-flight). Does that make sense to you?
cmd/hcp/forceupgrade/forceupgrade.go
Outdated
| cmd.Flags().BoolVar(&opts.dryRun, "dry-run", false, "Simulate the upgrade without making any changes") | ||
|
|
||
| // Service log flags | ||
| cmd.Flags().BoolVar(&opts.sendServiceLog, "send-service-log", false, "Send service log notification after scheduling upgrade") |
There was a problem hiding this comment.
I am a bit surprised that we opt to not send a servicelog by default?
cmd/hcp/forceupgrade/forceupgrade.go
Outdated
|
|
||
| // Cluster targeting flags | ||
| cmd.Flags().StringVarP(&opts.clusterID, "cluster-id", "C", "", "ID of the target HCP cluster") | ||
| cmd.Flags().StringVarP(&opts.clustersFile, "clusters-file", "c", "", "JSON file containing cluster IDs") |
There was a problem hiding this comment.
Should use the same string as the servicelog cluster's file (assuming it's using the same format - which IMO it should):
Read a list of clusters to post the servicelog to. the format of the file is: {"clusters":["$CLUSTERID"]}
cmd/hcp/forceupgrade/forceupgrade.go
Outdated
| } | ||
|
|
||
| // validateAndParseClusterFile validates the clusters file and returns the cluster IDs | ||
| func (o *forceUpgradeOptions) validateAndParseClusterFile() ([]string, error) { |
There was a problem hiding this comment.
We probably want to reuse the servicelog clustersfile logic here.
| if policy.ScheduleType() == v1.ScheduleTypeAutomatic { | ||
| automaticPolicyIDs = append(automaticPolicyIDs, policy.ID()) | ||
| } else { | ||
| return "", fmt.Errorf("existing manual upgrade policy found: target version %s scheduled at %s", |
There was a problem hiding this comment.
Do we have to make sure the upgrade that is manual will actually go to the new y-stream? If it's just a Z-stream upgrade it would not fix the cluster.
typeid
force-pushed
the
add-force-upgrading-option
branch
from
e5c3ade to
714cdca
Compare
typeid
changed the title
openshift-ci
bot
added
the
do-not-merge/work-in-progress
Implements a new forceupgrade command for HCP clusters that allows forcing cluster upgrades. Includes command structure, implementation, and tests. Co-Authored-By: Claude Sonnet 4 <noreply@anthropic.com>
typeid
force-pushed
the
add-force-upgrading-option
branch
from
714cdca to
8eb4afb
Compare
|
@typeid: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. |
typeid
changed the title
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
2 participants
This PR adds a new command that allows force upgrading ROSA HCP clusters while bypassing OCM pre-flights, utilizing the new upgrade strategy designed in OCM-DDR-0204.
This is an enablement to handling end of support clusters, which require upgrades to new versions regardless of cluster state.
Tested the following:
Code generation assisted by Claude Code.