You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 17, 2023. It is now read-only.
This appears to be meant as a way to easily set the required overlays and ensure that the "external-mysql" overlays are rolled out instead of the default "db" ones. However, this did not work as it seems to update configmaps "metadata-config" and "api-service-config" that do not get rolled out at all and are not referenced by any of the points.
So I went about it manually. The following manually changes fixed it for me:
Yes, that is the conclusion I came to as well. Doesn't look like it would be too hard to implement though? Essentially instead of creating the config maps as it currently does it does needs to adjust the overlays as described above. That would be quite useful since one then only needs to update the kfdef
All the other parts of implementation are finished, except how to pass password to replace K8s secret, it's fairly easy in the k8s onfigmap, however not in k8s secret.
It's about kfctl implementation, we generate all the manifests (including secrets and configmap) at first, then place them with our KfAwsPlugin parameter.
I touched it previously, might need to spend some time figuring it out.
I spent some time today rolling out KF 1.2.0 on EKS using exclusively RDS databases instead of an on-cluster MySQL deployment.
The latest kfctl has a "managedRelationDatabase" field that can be set in the kfdef, such as here:
This appears to be meant as a way to easily set the required overlays and ensure that the "external-mysql" overlays are rolled out instead of the default "db" ones. However, this did not work as it seems to update configmaps "metadata-config" and "api-service-config" that do not get rolled out at all and are not referenced by any of the points.
So I went about it manually. The following manually changes fixed it for me:
where
configure_rds_overlays.sh
has the following contents:It seems that the above (or at least something similar) is the behaviour that setting
managedRelationDatabase
is intended to invoke.The text was updated successfully, but these errors were encountered: