Open Stack

On 12/16/2013 09:27 AM, Daniel Kuffner wrote:
> Hi All,
> 
> I have submitted a new blueprint which addresses the a common pattern
> in the docker world. A usual pattern in the docker world is to use
> environment variables to configure a container.
> 
> docker run -e "SQL_URL=postgres://user:password@/db" my-app
> 
> The nova docker driver doesn't support to set any environment
> variables. To work around this issue I used cloud-init which works
> fine. But this approach has of course the drawback that a) I have to
> install the cloud init service. and b) my docker container doesn't
> work outside of openstack.
> 
> I propose to allow a user to set docker environment variables via nova
> instance metadata. The metadata key should have a prefix like ENV_
> which can be used to determine all environment variables. The prefix
> should be removed and the remainder key and vaule will be injected.
> 
> The metadata can unfortunately not be set in horizon but can be used
> from the nova command line tool and from heat. Example heat:
> 
> myapp:
>     Type: OS::Nova::Server
>     Properties:
>       flavor: m1.small
>       image: my-app:latest
>       meta-data:
>         - ENV_SQL_URL: postgres://user:password@/db
>         - ENV_SOMETHING_ELSE: Value
> 
> 
> Let me know what you think about that.
> 
> Blueprint: https://blueprints.launchpad.net/nova/+spec/docker-env-via-meta-data

Thanks for starting the discussion.  More people should do this for
their blueprints.  :-)

One of the things we should be striving for is to provide as consistent
of an experience as we can across drivers.  Right now, we have the
metadata service and config drive, and neither of those are driver
specific.  In the case of config drive, whether it's used or not is
exposed through the API.  As you point out, the meta-data service does
technically work with the docker driver.

I don't think we should support environment variables like this
automatically.  Instead, I think it would be more appropriate to add an
API extension for specifying env vars.  That way the behavior is more
explicit and communicated through the API.  The env vars would be passed
through all of the appropriate plumbing and down to drivers that are
able to support it.

This is all also assuming that containers support is staying in Nova and
not a new service.  That discussion seems to have stalled.  Is anyone
still pushing on that?  Any updates?

-- 
Russell Bryant