uselagoon / lagoon

Lagoon, the developer-focused application delivery platform
https://docs.lagoon.sh/
Apache License 2.0
566 stars 148 forks source link

Migrating from ASB to DBaaS issues #2499

Closed shreddedbacon closed 2 years ago

shreddedbacon commented 3 years ago

When performing a migration from the ansible service broker in openshift, to the mariadb consumer resource for the dbaas-operator, there are some issues encountered that could cause a lot of issues.

Manually creating the mariadbconsumer resource works fine. But at the first deployment lagoon in openshift does an oc process, then oc apply of a template, and this overwrites what was manually created, and the dbaas attempts to provision a new database (and is successful) so the original database remains stale, and the new one is provisioned. So 2 databases/users now exist for that environment

Subsequent deployments result in an unchanged mariadbconsumer though, so I'm not sure what is happening here.

Here is where we do the oc process https://github.com/amazeeio/lagoon/blob/master/images/oc-build-deploy-dind/build-deploy-docker-compose.sh#L591-L604 then we oc apply it here https://github.com/amazeeio/lagoon/blob/master/images/oc-build-deploy-dind/build-deploy-docker-compose.sh#L895 with a bunch of other resources.

I'm not sure why this remains unchanged after the initial creation, but i think we should only oc process this resource if it doesn't exist.

Schnitzel commented 3 years ago

Subsequent deployments result in an unchanged mariadbconsumer though, so I'm not sure what is happening here.

how do we create the mariadbconsumer resource during the migration? I could imagine that it is not created via kubectl apply and therefore the kubectl.kubernetes.io/last-applied-configuration is not existing, so the next time that lagoon adds the mariadbconsumer resource via kubectl apply the kubectl has no idea which fields have been added before and which not, so it overwrites the complete object.

shreddedbacon commented 3 years ago

I tried to do it the following ways, and both result in the resource being overwritten by lagoon and the dbaas attempting to provision a new database for the namespace.

1) straight up oc apply the full crd with all the information required

oc apply -f tmp.yml

2) doing it a similar way to how lagoon does it using oc process of a template

oc process -o yaml \
                -n ${1} \
                -f tmp.yml \
                -p SERVICE_NAME="${2}" \
                -p SAFE_BRANCH="${GIT_SAFE_BRANCH}" \
                -p SAFE_PROJECT="${PROJECT}" \
                -p ENVIRONMENT="${ENVIRONMENT_TYPE}"

I still think #2502 should be merged, because there isn't really any reason to apply or generate the consumer crd if it already exists?

shreddedbacon commented 2 years ago

Openshift 3.11 with ASB doesn't exist anymore