Cannot modify HTTPScaledObjects after moving from 0.7.0 to 0.8.0

[jocelynthode]

Report

After upgrading to 0.8.0. The CRD seems to have changed and the enum for status.conditions[].type now only supports Ready as a value.

Before this update to the CRD we supported the following values:

- Created
- Error
- Pending
- Unknown
- Terminating
- Terminated
- Ready

I was able to workaround it by editing the CRD and readding these statuses and then edit them so that the status conditions could be cleaned up.

Expected Behavior

I expect to be able to edit old HTTPScaledObjects

Actual Behavior

Old HTTPScaledObjects fail to be edited with the following messages:

* status.conditions[414].type: Unsupported value: "Pending": supported values: "Ready"
* status.conditions[415].type: Unsupported value: "Created": supported values: "Ready"
* status.conditions[417].type: Unsupported value: "Pending": supported values: "Ready"
* status.conditions[418].type: Unsupported value: "Created": supported values: "Ready"
* status.conditions[420].type: Unsupported value: "Pending": supported values: "Ready"
* status.conditions[421].type: Unsupported value: "Created": supported values: "Ready"
* status.conditions[423].type: Unsupported value: "Pending": supported values: "Ready"
* status.conditions[424].type: Unsupported value: "Error": supported values: "Ready"

Steps to Reproduce the Problem

1. Have an old HTTPScaledObject with some status conditions other than Ready
2. Update to 0.8.0
3. Try to edit the HTTPScaledObjects

Logs from KEDA HTTP operator

No response

HTTP Add-on Version

0.8.0

Kubernetes Version

1.27

Platform

Other

Anything else?

No response

[massimeddu-sj]

Same issue here on Kubernetes 1.29.

Thanks @jocelynthode , your work around worked just fine.

[JorTurFer]

f**k I didn't notice that changing the status fields I can break the CRD :/
The HTTP Add-on shouldn't use them anymore either but probably it doesn't remove them if they are already there. Does it fail after the rollout of the new version is completed?

[JorTurFer]

I'm asking because we have to include a check for removing those states from the HTTPScaledObject if they are available

[jocelynthode]

f**k I didn't notice that changing the status fields I can break the CRD :/ The HTTP Add-on shouldn't use them anymore either but probably it doesn't remove them if they are already there. Does it fail after the rollout of the new version is completed?

Yes The upgrade to 0.8.0 was successful and everything seemed to be working. Then when I wanted to edit HTTPScaledObjects created before the upgrade I was met with the error. The problem is indeed that it does not remove old statuses and thus after the upgrades prevents objects with old statuses to be updated.

[JorTurFer]

Yes The upgrade to 0.8.0 was successful and everything seemed to be working. Then when I wanted to edit HTTPScaledObjects created before the upgrade I was met with the error. The problem is indeed that it does not remove old statuses and thus after the upgrades prevents objects with old statuses to be updated.

Thanks for the feedback, I'm going to try to fix this during the week and cut a fix release. I thought that old values were dropped automatically but apparently not (every day you learn things xD). The operator will drop them during the upgrade for future releases. Sorry for the inconvenience

[jocelynthode]

No worries, thanks for the work 🙂

[oto-macenauer-absa]

just encountered this, bumping so it doesn't get stale:)

[jocelynthode]

@JorTurFer : Any update on this issue? It's been a few months with no releases.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[jocelynthode]

Do not close

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[jegork]

Still an issue