Skip to content

Enables LCM auto-upgrade - #97

Open
dharmit wants to merge 2 commits into
SUSE:mainfrom
dharmit:core-644
Open

Enables LCM auto-upgrade#97
dharmit wants to merge 2 commits into
SUSE:mainfrom
dharmit:core-644

Conversation

@dharmit

@dharmit dharmit commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

A separate phase for LCM upgrade is added as the first phase for LCM so that it gets upgraded before anything else.

A separate phase for LCM upgrade is added as the first phase for LCM so
that it gets upgraded before anything else.

Signed-off-by: Dharmit Shah <dharmit.shah@suse.com>
@dharmit
dharmit requested a review from a team as a code owner September 2, 2026 11:39
Expect(status.Message).To(Equal("All 2 LCM charts upgraded successfully (0 skipped)"))
})

FIt("should not error even if the charts fail to upgrade", func() {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created this for the purpose of discussion. In this test, CRD charts fail to upgrade, but that doesn't prevent LCM chart upgrades from getting triggered.

Do we want to keep this behaviour or break if the LCM CRD chart fails to upgrade?

Another question: do we want to return an error if either of the LCM CRD or LCM charts fail to upgrade so that the next phase doesn't get triggered? IIUC, that's not the case presently and we return a nil in error which leaves it upon the user to figure what went wrong with chart upgrades. I understand why this is OK in case of other Helm charts that are being upgraded towards the end but, for LCM charts, what behaviour do we think is more appropriate?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sharing my own thoughts. I personally feel we should not attempt to upgrade LCM chart if its CRDs fail to upgrade. And for the second one, assuming I understand things correctly, I feel we should stop the overall upgrade instead of letting OS upgrade phase get triggered.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have modified the PR to include the implementation for failure on LCM chart upgrade. It's in a separate commit to make removal easier if we decide not to fail the overall upgrade when one of these charts' upgrades fails.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fully agree, any failure in that state should stop the whole pipe and report the error IMHO.

@dharmit
dharmit force-pushed the core-644 branch 2 times, most recently from d3bec23 to 521a4f3 Compare September 7, 2026 13:11

@davidcassany davidcassany left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

Just a couple of minor comments which do not necessarily imply any requested change, they are just arguable and minor improvements.

var workloadCharts []*upgrade.HelmChartConfig
for _, chartCfg := range chartConfigs {
name := chartCfg.Chart.GetName()
if !isLCMChart(name) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: do we actually need to prevent LCMchart to be processed here? Up to my understanding it should not hurt attempting to upgrade it again, the upgrade if it is already at the desired version should do nothing.
If so, then we can probably keep the helm reconciler unmodified and if we ever set an upgrade pipe without LCMreconciler the helm reconciler would still run the full upgrade.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any technical issue in removing isLCMChart check from here. Except it being a brain thing where it feels weird to keep it in spite of having a dedicated phase for it earlier in the flow.

if we ever set an upgrade pipe without LCMreconciler the helm reconciler would still run the full upgrade.

If we do this, it would be for the purpose of prevent LCM charts' upgrade, right? But removing isLCMChart check from Helm reconciler would still cause the LCM charts' upgrade. Just presenting a counter point.

I'm fine by removing the check from here if it makes more sense. Keeping this open for others' feedback/suggestions.

Comment thread internal/upgrade/reconcilers/lcm.go Outdated
case helm.ChartStateFailed:
failed++
if failedChart == "" {
failedChart = result.chartName

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this is just keeping the last failed chart and the number of failures is not user any where. Probably you could simply directly return here with:

return &upgrade.PhaseStatus{
    State:   lifecyclev1alpha1.UpgradeFailed,
	Message: fmt.Sprintf("Chart %s upgrade failed", failedChart),
}

without the need to count the number of failures and then check if it is bigger than zero.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function was copy-pasted from Helm reconciler. In LCM reconciler, I don't see a reason to have this check and keep a counter at all if we agree to failing the entire upgrade if any of the LCM charts fails to upgrade.

Signed-off-by: Dharmit Shah <dharmit.shah@suse.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants