<div dir="ltr">Hi Russel,<br><br>I have something that is pushing it for to stay in nova (at least the compute drivers). I should have a gerrit branch for people to review soon.<br><br>Regards<br>chuck<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Dec 16, 2013 at 10:07 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 12/16/2013 09:27 AM, Daniel Kuffner wrote:<br>
> Hi All,<br>
><br>
> I have submitted a new blueprint which addresses the a common pattern<br>
> in the docker world. A usual pattern in the docker world is to use<br>
> environment variables to configure a container.<br>
><br>
> docker run -e "SQL_URL=postgres://user:password@/db" my-app<br>
><br>
> The nova docker driver doesn't support to set any environment<br>
> variables. To work around this issue I used cloud-init which works<br>
> fine. But this approach has of course the drawback that a) I have to<br>
> install the cloud init service. and b) my docker container doesn't<br>
> work outside of openstack.<br>
><br>
> I propose to allow a user to set docker environment variables via nova<br>
> instance metadata. The metadata key should have a prefix like ENV_<br>
> which can be used to determine all environment variables. The prefix<br>
> should be removed and the remainder key and vaule will be injected.<br>
><br>
> The metadata can unfortunately not be set in horizon but can be used<br>
> from the nova command line tool and from heat. Example heat:<br>
><br>
> myapp:<br>
>     Type: OS::Nova::Server<br>
>     Properties:<br>
>       flavor: m1.small<br>
>       image: my-app:latest<br>
>       meta-data:<br>
>         - ENV_SQL_URL: postgres://user:password@/db<br>
>         - ENV_SOMETHING_ELSE: Value<br>
><br>
><br>
> Let me know what you think about that.<br>
><br>
> Blueprint: <a href="https://blueprints.launchpad.net/nova/+spec/docker-env-via-meta-data" target="_blank">https://blueprints.launchpad.net/nova/+spec/docker-env-via-meta-data</a><br>
<br>
</div></div>Thanks for starting the discussion.  More people should do this for<br>
their blueprints.  :-)<br>
<br>
One of the things we should be striving for is to provide as consistent<br>
of an experience as we can across drivers.  Right now, we have the<br>
metadata service and config drive, and neither of those are driver<br>
specific.  In the case of config drive, whether it's used or not is<br>
exposed through the API.  As you point out, the meta-data service does<br>
technically work with the docker driver.<br>
<br>
I don't think we should support environment variables like this<br>
automatically.  Instead, I think it would be more appropriate to add an<br>
API extension for specifying env vars.  That way the behavior is more<br>
explicit and communicated through the API.  The env vars would be passed<br>
through all of the appropriate plumbing and down to drivers that are<br>
able to support it.<br>
<br>
This is all also assuming that containers support is staying in Nova and<br>
not a new service.  That discussion seems to have stalled.  Is anyone<br>
still pushing on that?  Any updates?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>