This is working in interactive services, but not in computational services. In interactive services we can have the block below in an .osparc/osparc-dakota-comp/runtime.yml file, and it exposes the variables in the service. This doesn't seem to work in computational service, since compose-spec seems dynamic-sidecar specific.
To be able to use the osparc python API client in computational services, we need the API host/key/secret exposed.
These variables were exposed in (e.g.) https://github.com/ITISFoundation/osparc-simcore/pull/5695
This is working in interactive services, but not in computational services. In interactive services we can have the block below in an .osparc/osparc-dakota-comp/runtime.yml file, and it exposes the variables in the service. This doesn't seem to work in computational service, since compose-spec seems dynamic-sidecar specific.
compose-spec: │ version: "3.7" │ services: │ │ osparc-dakota-comp: │ │ │ image: $${SIMCORE_REGISTRY}/simcore/services/comp/osparc-dakota-comp:$${SERVICE_VERSION} │ │ │ environment: │ │ │ │ - OSPARC_API_HOST=$${OSPARC_VARIABLE_API_HOST} │ │ │ │ - OSPARC_API_KEY=$${OSPARC_VARIABLE_API_KEY} │ │ │ │ - OSPARC_API_SECRET=$${OSPARC_VARIABLE_API_SECRET} container-http-entrypoint: osparc-dakota-comp
@sanderegg Could you help with this? Or do you have any ideas how to get the keys into the containers?