hive upgrade to 1.1.6 is expecting CRD API version to be v1beta instead of v1 about hive

[2uasimojo]

Looks like you may be trying to run a really old (>1y) version of hive on a cluster with a newer (>=1.22) version of k8s. Are you getting this from OperatorHub? That's the only place I can imagine 1.1.x to be available.

I would suggest upgrading to a more recent version. If you're using OLM and it's not letting you skip versions, you should be able to uninstall hive entirely (the CRDs and therefore CRs like your ClusterDeployments ought to remain unaffected) and reinstall it e.g. from the tip of the alpha channel in OperatorHub.

[groenator]

Hi @2uasimojo

Thank you for your reply.

I manage to upgrade hive operator successfully and now everything is back to normal. What you said above I did exactly the same.

I thought at first that if I delete the sub and the CSV would delete the CRD as well. It didn't do that, which is really good :)

I will close this issue.

Regards, Bogdan

[groenator]

Hi,

I forgot to ask you one thing.

The ClusterDeployment now is showing FailedToStart in the Power state because it cannot validate the AWS credentials. I purposely add some dummy credentials in the past when I was using the old version.

What would be the impact if I leave the status like that for a while?

The AWS credentials are only used to provision resources in AWS, it won't impact hive to manage or apply configurations on the clusters?

Regards,

[2uasimojo]

I thought at first that if I delete the sub and the CSV would delete the CRD as well. It didn't do that, which is really good :)

Agree. There was at one point a feature request in OLM to support (optional) removal of CRs and CRDs, but I don't think it ever took off.

now is showing FailedToStart in the Power state because it cannot validate the AWS credentials.

Hive supports hibernation/resume by stopping/starting cloud instances. I'm not sure exactly when this feature was introduced, but I wouldn't be surprised if it was waaay after 1.1.5. So what's happening right now is the controller responsible for the cluster's power state is trying to figure out what that state is for the first time, and since it can't connect to the cloud, it's assuming the instances are down. If they're really not, and you're able to access the console/API and do work, then you should be fine to leave it as is. However, it would probably behoove you to fix those creds so you can take advantage of this feature.

[groenator]

Hi,

I am in the process of migrating all the clusterDeployments from EKS to a new Openshift cluster, and because of this migration, I rather not fix the AWS creds now and just do it when the CD is migrated over.

I can access the console and API fine, the clusters are operating without any issues.

Once again, thanks for your input. I will close this issue for now.

Regards,