Best way to handle multiple API configs

[jakubjanousek]

Hi,
we are currently syncing config across multiple instances in the following way:

• tables/actions/forms are created locally with the YAML config saved in git
• a custom build is created based on motoradmin/motoradmin:latest with the custom YAML config
• this build is then deployed on multiple k8s clusters (containing among others its own DB instance & API)
• motoradmin pod stores its data in Postgres

We will need to have a custom form submitting data to our API. Locally this means sending to localhost:3001, on the test server, it would point to the test server API (and in future further instances would need to point to their own API as well).

Right now I've tried creating a new API in motoradmin on the test server, but after restarting the pod, I cannot see it in API list, although it is selected in the form itself. The form currently doesn't submit and returns 302 without any explanation (neither motoradmin logs provide any insight except for logging the request). The request doesn't hit our API.

What is the best way to handle such a situation? Also can we debug the /api/run_api_request 302 in any way? Thanks a lot for your input

[omohokcoj]

@jakubjanousek if all your multiple instances are going to point to the same API then the best way to handle that would be to modify motor.yaml on the Docker image build step (dockerfile)

Let's say there is "Backend" endpoint in localhost that points to localhost:3000 but on production you want to point it to prod.company.com.

So in Dockerfile after you COPY motor-admin.yml add another step to replace localhost:3000 with prod url:
RUN sed -i 's/old-url/new-url/g' motor-admin.yml - or using some other cli tool or script.

Also make sure that motoradmin stores admin configs in the PG database (not sqlite inside the container) - so that config changes won't be lost on restart (DATABASE_URL motor admin env).

Let me know if it helps to solve the problem.

[jakubjanousek]

@omohokcoj unfortunately this wouldn't work as we want to deploy the built image across multiple clusters/productions (and building separate image for each cluster would be really cumbersome).

We are already storing the admin configs in PG, I even saw the motor_api_configs table in there, but there seems to be some issue with it being different from the api_config in YAML as the API that was added on production is now visible in the list after restart (but still selected in the form I used it in).

[omohokcoj]

@jakubjanousek motor admin updates rows with configs in PG db on app restart - but i uses updated_at value to decide if the value should be reset or no.

So in your case - you need to manually update API url on prod so that updated_at is > than motor-admin.yml updated at for that api config record - this way api config url in PG db won't be replaced with the localhost value from motor-admin.yml.

It's a bit hard to advice any solution for this without knowing the full context of how/why you're using multiple motor admin in clusters with multiple external apis.
Another solution could be to put your api and motor admin under reverse proxy so that /admin and /product_api are available under the same host and can be accessed via the 'Origin' api config (meaning triggering requests to the same host).

[jakubjanousek]

This makes sense, thanks a lot.

We will just create a local config, that won't be touched and then overwrite its URL on production. Worst case, we will have to overwrite it once again if we need to make changes to the local API config instance.

[jakubjanousek]

Regarding the 302 we have encountered, this was a k8s misconfiguration purely on our side