DBAAS-1193: workaround to the ack-rds-controller upgrade issue#343
DBAAS-1193: workaround to the ack-rds-controller upgrade issue#343xieshenzh wants to merge 3 commits intoRHEcosystemAppEng:mainfrom
Conversation
xieshenzh
force-pushed
the
DBAAS-1193-2
branch
4 times, most recently
from
118f80d to
40acdd4
Compare
xieshenzh
requested review from
jeremyary,
jianrongzhang89,
redhatHameed and
tchughesiv
as code owners
| - type: olm.package | ||
| value: | ||
| packageName: ack-rds-controller | ||
| version: ">=0.0.27 <=0.1.3" |
There was a problem hiding this comment.
is this intentional removed ? if yes how the RDS controller will be installed ?
There was a problem hiding this comment.
It will be installed as a dependency of the rds-dbaa-operator.
There was a problem hiding this comment.
this isn't good enough... in my prior testing its required in both places. If nothing else, dbaas-operator at the very least is where this dep needs to be. This is because during a RHODA upgrade, if ack-rds-controller has since release a new version... say 0.2.0, ACK will upgrade without this dep declared. This will then break the rhoda install as rds would have a dep conflict
There was a problem hiding this comment.
this should not be removed
There was a problem hiding this comment.
The auto-upgrade of the ack-rds-controller is broken. Since the upgrade of the ack-rds-controller is not maintained, it is not necessary to allow it to upgrade, which causes various issues.
Changes in this PR will delete any ack-rds-controller as soon as the dbaas-operator is installed in the namespace, upgrade of the ack-rds-controller will not take place during RHODA upgrade.
When the rds-dbaas-operator is re-installed, the properly version of the ack-rds-controller will be installed as a dependency.
There was a problem hiding this comment.
that doesn't help in clusters where ack is installed in another ns
There was a problem hiding this comment.
this is the benefit of using olm deps
There was a problem hiding this comment.
If the ack-rds-controller is installed in another namespace, rhoda will not work. Because the secret and configmap of the ack-rds-controller must be set by the rhoda operator in the rhoda installation namespace in order to create a provider account, then rhoda will scale up the deployment of the ack-rds-controller in the rhoda installation namespace.
There was a problem hiding this comment.
but, wouldn't anyone who's installed ack in another namespace have configured it already? why would we care if it's in same namespace?
There was a problem hiding this comment.
The configuration information of the ack-rds-controller should be provided via rhoda provider account creation. Only one provider account can be created for RDS in a cluster, and the credentials of the provider account is used to set up the ack-rds-controller.
If users configure and install the operator in another namespace without using rhoda, then it is supposed to work independent of rhoda.
| - type: olm.package | ||
| value: | ||
| packageName: ack-rds-controller | ||
| version: ">=0.0.27 <=0.1.3" |
There was a problem hiding this comment.
this should not be removed
| if err := cli.Create(ctx, cm); err != nil { | ||
| } | ||
| if instanceCRD && clusterCRD { | ||
| if err := cli.Delete(ctx, &csv); err != nil { |
There was a problem hiding this comment.
What happens when the dbaas-manger pod gets restarted? Would this cause the ack sub to be deleted?
There was a problem hiding this comment.
Thanks. The ack-rds-controller will be deleted in this case.
Changed the code to also delete rds-dbaas-operator when starting dbaas-operator. Then the rds-dbaas-operator and ack-rds-controller will be re-installed when re-starting dbaas-operator.
There was a problem hiding this comment.
I'm not sure that's a solution though. We can't have ack and rds being uninstalled/reinstalled every time the pod restarts... which could be often.
There was a problem hiding this comment.
I could check the version of the ack-rds-controller only delete it when the version is not right.
Otherwise, I am not sure if there is a good solution to the ack-rds-controller upgrade issues.
xieshenzh
force-pushed
the
DBAAS-1193-2
branch
from
f3e3192 to
974d84f
Compare
xieshenzh
force-pushed
the
DBAAS-1193-2
branch
from
974d84f to
5d624b9
Compare
3 participants
Description
New upgrade issue was found with ARO cluster when the ack-rds-controller upgrades from v0.1.0 to v0.1.1.
Jira: https://issues.redhat.com/browse/DBAAS-1193
The new workaround is to delete the ack-rds-controller Subscription and CSV when dbaas-operator v0.0.4 is installed.
So that, ack-rds-controller v0.1.3 installation will be triggered when installing the rds-dbaas-operator, and ack-rds-controller upgrade is skipped.
Verification Steps
Upgrading RHODA v0.0.3 to 0.0.4.
Check if the upgrade succeeds and if the ack-rds-controller is upgraded to v0.1.3.
Type of change
Checklist (Definition of Done)