New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DotEnv + Unicorn zero downtime = fail #57

Closed
johnae opened this Issue Sep 4, 2013 · 4 comments

Comments

Projects
None yet
2 participants
@johnae

johnae commented Sep 4, 2013

The problem is the fact that DotEnv doesn't overwrite keys in ENV that already exist. Since Unicorns zero downtime feature works by having the "old" master process execute a new master process the new master process inherits the old ENV and DotEnv dutifully skips setting any of the old DotEnv keys which means you can't do zero downtime deploys using Unicorn + DotEnv and have configuration update itself.

I would suggest at least adding a setting to DotEnv so that you can have it overwrite existing keys... and honestly, i.m.o, I don't think NOT overwriting keys in production is a bad default. I can understand it for development but not production.

@johnae

This comment has been minimized.

Show comment
Hide comment
@johnae

johnae Sep 4, 2013

Apparently this feature was up voted when implemented... I don't really understand why since dotenv solves the, i.m.o, mess of having env vars from all kinds of places you don't even know of sometimes. Why not have it all in the same place?

Anyway I forked the repo and made the change (which is obviously extremely simple). Here it is:
johnae@0556d5e

johnae commented Sep 4, 2013

Apparently this feature was up voted when implemented... I don't really understand why since dotenv solves the, i.m.o, mess of having env vars from all kinds of places you don't even know of sometimes. Why not have it all in the same place?

Anyway I forked the repo and made the change (which is obviously extremely simple). Here it is:
johnae@0556d5e

@bkeepers

This comment has been minimized.

Show comment
Hide comment
@bkeepers

bkeepers Sep 4, 2013

Owner

See #38. I'm not against changing how this is implemented, it just needs to be done properly.

and honestly, i.m.o, I don't think NOT overwriting keys in production is a bad default.

I disagree. The deployment environment should ALWAYS have the final say. dotenv is primary aimed at solving the problem in development. In production, it's really easy to just set your config options in the environment.

Owner

bkeepers commented Sep 4, 2013

See #38. I'm not against changing how this is implemented, it just needs to be done properly.

and honestly, i.m.o, I don't think NOT overwriting keys in production is a bad default.

I disagree. The deployment environment should ALWAYS have the final say. dotenv is primary aimed at solving the problem in development. In production, it's really easy to just set your config options in the environment.

@johnae

This comment has been minimized.

Show comment
Hide comment
@johnae

johnae Sep 4, 2013

Well I guess we disagree, at least in part. I like the fact that you can now have the same variables defined in the same way for both dev and prod. That way it is less confusing where the variables come from. We store all config in a config-repo where we've got development and production stuff defined. It's all in the same place and gets deployed when the apps are deployed, or synced automatically in development. I could understand why some developers would want to set vars on the command line and expect them to not be overwritten but in production - not really. Anyway, perhaps someone wants that too - I realize people do things differently :-).

Sorry for missing the existing issue, my bad. Anyway - a configuration option or something for this would be a very nice feature.

johnae commented Sep 4, 2013

Well I guess we disagree, at least in part. I like the fact that you can now have the same variables defined in the same way for both dev and prod. That way it is less confusing where the variables come from. We store all config in a config-repo where we've got development and production stuff defined. It's all in the same place and gets deployed when the apps are deployed, or synced automatically in development. I could understand why some developers would want to set vars on the command line and expect them to not be overwritten but in production - not really. Anyway, perhaps someone wants that too - I realize people do things differently :-).

Sorry for missing the existing issue, my bad. Anyway - a configuration option or something for this would be a very nice feature.

@bkeepers

This comment has been minimized.

Show comment
Hide comment
@bkeepers

bkeepers Sep 4, 2013

Owner

Here's more of the philosophy that inspires dotenv: http://12factor.net/config

Anyway - a configuration option or something for this would be a very nice feature.

Pull requests welcome.

Owner

bkeepers commented Sep 4, 2013

Here's more of the philosophy that inspires dotenv: http://12factor.net/config

Anyway - a configuration option or something for this would be a very nice feature.

Pull requests welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment