permissions created via meta data api doesnt reflect in meta data files

[zlil]

Version Information

Server Version: 2.1.1
CLI Version (for CLI related issue): 2.1.1

Environment

Docker container

What is the expected behaviour?

when creating permissions via metadata API applying the changes inside the related metadata tables yaml files.
for ex. if for some reason the container is down and we want to rebuild it and runing migrations from scratch I can't recover the permissions. another ex. is that we want to keep these changes under source control like git.

Keywords

api metadata docker yaml

What is the current behaviour?

creating permissions via the /v1/metadata/ is fine but to way to keep it on track inside metadata yaml files.

How to reproduce the issue?

create permissions via the api meta data -
https://hasura.io/docs/latest/graphql/core/api-reference/metadata-api/permission.html#pg-create-insert-permission

[rikinsk]

hey. just checking if you used the hasura metadata export cli command after using the API to update the metadata files?

[zlil]

hey. just checking if you used the Hasura metadata export CLI command after using the API to update the metadata files?

no, I don't want to use metadata-export command, lets's say we have a custom dashboard where an admin can create different roles on demand. he uses metadata API to create these roles including the right permissions on the table. my expected behavior is after the user makes the request to create different roles & permissions there is something behind the scene that keep these changes (permissions) on track and right them down to the yaml files.

[rikinsk]

I am not sure I undertstand your use case correctly. As I understand, your admin has a local Hasura instance running via docker which is connected to a dashboard that is used to update your Hasura metadata using the metadata APIs and you would like those changes to be exported to the yaml file on the admin's local filesystem. If this isnt accurate could you elaborate a bit more on your set up?

In any case, the HGE server doesnt not have access to the local file system and currently cannot write to it directly. The CLI is the tool that helps relay changes from the server to the yaml files on the filesystem.

Would love to understand your use case a bit more and see if there is a way to achieve what you are looking for

[adiazarya100]

@rikinsk Thank you for the quick response.
We have our own UI web application where the admin user can create his own roles.
When the admin generates a new role it doesn't reflect in the yaml files.

The problem is:

1. The admin user creates a new custom role via our custom UI web application (not via Hasura console)
2. The role will be available while the Hasura instance is alive. (docker file)
3. In case the Hasura instance failed and we have to build a new container using docker compose up --build the role will be deleted and could not be reproduced because these permissions are not in the yaml file.

are we missing something?
tnx!

[rikinsk]

Thanks for sharing these details.

Just a couple more question on your setup so that I have a better understanding:

• where exactly are your metadata yaml files present? I am assuming its in some directory on the admin user's computer?
• I would like to understand how the metadata from your yaml files gets applied to the Hasura instance when you build a new container. so what exactly does docker compose up --build do? would it be possible to share your docker-compose file (after redacting any sensitive info of course) so that i can understand this easier?

[adiazarya100]

Hi,

where exactly are your metadata yaml files present? I am assuming it's in some directory on the admin user's computer?

I would like to understand how the metadata from your yaml files gets applied to the Hasura instance when you build a new container. so what exactly does docker compose up --build do? would it be possible to share your docker-compose file (after redacting any sensitive info of course) so that I can understand this easier?

This is our Dockerfile:

FROM hasura/graphql-engine:v2.1.1.cli-migrations-v3

ENV HASURA_GRAPHQL_MIGRATIONS_DIR=/hasura-migrations
ENV HASURA_GRAPHQL_METADATA_DIR=/hasura-metadata

COPY ./docker-entrypoint.sh /bin/docker-entrypoint.sh
COPY ./migrations /hasura-migrations
COPY ./metadata /hasura-metadata

USER hasura

When we run docker compose up --build we actually running this:

hasura:
    image: ${DOCKER_REGISTRY}/active-hasura:latest
    build:
      context: hasura
    env_file: .env
    ports:
      - '9999:9999'
    depends_on:
      - postgres

Thank you!

[BenoitRanque]

The issue here is that the metadata api does not export metadata files (nor should it).
Instead, you can use the export metadata api to get a JSON object with your entire metadata. This is the same format you get when you export metadata from the hasura console, and it can be applied with the replace metadata api.

But what you're looking for is the YAML representation of this object. Converting the JSON object to YAML is handled by the cli, but there is a util here that could help you implement this yourself. But this isn't my recommended way forward.

The way the hasura cli works is that every time the metadata is changed via the console, the export metadata api will be invoked and the YAML files in the local directory will be replaced. Are your requests to the various hasura metadat apis going through a proxy?
If so, assuming that proxy is running in a container, you could copy the hasura cli onto it, and run hasura metadata export from there. You would of course need to mount the metadata directory onto that container.