<div dir="ltr">One potentially worthy note on this:<div><br></div><div>Using upstart, we can source as many files in whichever order we like.</div><div><br></div><div>However, this could potentially break local dev environments, unless we put all of the dev-required variables into a sample.env type of file but have our own two or three env files (one with secrets from the current s3://mofo-techops/creds/apps/<env>/<appname> ), staging.env, and production.env.</div>
<div><br></div><div>We need not necessarily wait for Habitat to take a patch. </div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 3, 2014 at 11:58 AM, Kieran Sedgwick <span dir="ltr"><<a href="mailto:kieran.sedgwick@gmail.com" target="_blank">kieran.sedgwick@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">One more +1.<div><br></div><div>This is a tough problem that I saw most of last year while contributing with you all. As Ali says, this looks like a long-term solution.</div>
<div><br></div><div>That is all :P</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 3, 2014 at 11:27 AM, JP Schneider <span dir="ltr"><<a href="mailto:john.p.schneider@gmail.com" target="_blank">john.p.schneider@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sorry for the late reply, I was out yesterday.<div><br></div><div>This would be amazing! I like Gavin's idea as well. </div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 7:18 PM, Gavin Suntop <span dir="ltr"><<a href="mailto:gavin@mozillafoundation.org" target="_blank">gavin@mozillafoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>On the error handling tip: I’ve had positive results using JSON/CSON for config because you can actually write a schema to validate against.</div>
<div><br></div><div>It does take more work to maintain the schema, but you get very comprehensive error messages “for free”. You’ll know that you’re actually missing property X, not just “something broke”.</div><div><br>
</div>
<div>I took this approach on the CSP Logger Service - <a href="https://github.com/mozilla/csp-logger" target="_blank">https://github.com/mozilla/csp-logger</a></div><div><br></div><div>Other niceties of this approach are actual types beyond strings. Like…arrays! No more splitting strings and wondering if you need quotes, commas, spaces or whatnot.</div>
<br><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">+<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="text-align:start;text-indent:0px"><b>Gavin Lazar Suntop</b></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
irc, twitter, github: <b>gvn</b></div></div>
</div><div><div>
<br><div><div>On Jun 2, 2014, at 3:42 PM, David Humphrey <<a href="mailto:david.humphrey@senecacollege.ca" target="_blank">david.humphrey@senecacollege.ca</a>> wrote:</div><br><blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<div>I wonder if habitat needs to get taught
to be more verbose in dev situations? It could tell you exactly
what it's doing on app startup.<br>
<br>
Dave<br>
<br>
On 14-06-02 6:38 PM, Kate Hudson wrote:<br>
</div>
<blockquote type="cite">
The reason I bring up debugging specifically referencing
staging/prod environments is that I really feel it should be
possible for me/others who are not Jon and JP should ideally be
able to debug config issues if both/either of them are away
<div><br>
</div>
<div>- K</div>
<div><br>
<div>
<div>On Jun 2, 2014, at 6:02 PM, Kate Hudson <<a href="mailto:kate@mozillafoundation.org" target="_blank">kate@mozillafoundation.org</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div style="word-wrap:break-word">This sounds really
good. As long as docs exist for this and we do some
thinking about how resolving bugs will work I think it
would definitely be an improvement on our process.
<div><br>
</div>
<div>I would love to see us think about the
debugging/error resolution process for common pitfalls
in this system, such as:</div>
<div><br>
</div>
<div>- How do we debug/see which files actually get
loaded, and in what order?</div>
<div>- What if our secret files on s3 contain a legacy env
variable? Would it overwrite the committed environment
files? How would we know?</div>
<div>- Do we still have env.sample (probably not)?</div>
<div>- What if we want to <i>unset</i> certain env
variables (e.g. DEV) that are defined in default files</div>
<div><br>
</div>
<div>- Kate</div>
<div><br>
<div>
<div>On Jun 2, 2014, at 5:38 PM, Jon Buckley <<a href="mailto:jon@mozillafoundation.org" target="_blank">jon@mozillafoundation.org</a>>
wrote:</div>
<br>
<blockquote type="cite">Here’s something that really
gets my goat: app configuration<br>
<br>
1) When you install an application initially, you
need to copy the config file from the defaults to
one that you can use with `cp env.dist .env`.<br>
2) When you pull down updates from git, and
something doesn’t work, you need to copy the config
file from defaults again which blows away your
changes, or you need to pick through the change log
and apply the changes manually.<br>
3) Configuration only via process env (e.g. heroku)
is tedious because there are so many env variables.<br>
4) When you make a change to the staging or
production configs, there is absolutely no
visibility into who changed what, when, or why. This
has broken services for us more than once.<br>
5) If you’re doing a deploy that requires a config
change at the same time as a code change, you’ll
need JP or I to co-ordinate that.<br>
<br>
Therefore a better application configuration
solution should:<br>
1) Work out of the box<br>
2) Work when pulling down updates<br>
3) Work with process.env<br>
4) Be version controlled, preferably using git<br>
5) Doesn’t require devops to co-ordinate a
simultaneous code + config deploy<br>
<br>
My preferred solution is the following:<br>
- Modify habitat to support loading multiple
environment files in a specific order: <a href="https://github.com/brianloveswords/habitat/pull/11" target="_blank">https://github.com/brianloveswords/habitat/pull/11</a><br>
- Add multiple configuration files to each
applications repository - staging.env,
production.env, defaults.env<br>
- Code application to support loading from these new
locations in order:<br>
- process environment<br>
- .env<br>
- NODE_ENV.env (so staging.env or production.env)<br>
- defaults.env<br>
- Document this workflow in each app as
“MAINTENANCE.md” or something similar.<br>
<br>
The new workflow when landing a ticket that changes
the application configuration somehow would be to
also make changes to staging.env and production.env
in the same patch. For secrets that cannot be made
public we will continue our current process of
putting secrets into a config file on S3.<br>
<br>
Thoughts?<br>
_______________________________________________<br>
Webmaker-dev mailing list<br>
<a href="mailto:Webmaker-dev@mozilla.org" target="_blank">Webmaker-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/webmaker-dev" target="_blank">https://mail.mozilla.org/listinfo/webmaker-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
Webmaker-dev mailing list<br>
<a href="mailto:Webmaker-dev@mozilla.org" target="_blank">Webmaker-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/webmaker-dev" target="_blank">https://mail.mozilla.org/listinfo/webmaker-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Webmaker-dev mailing list
<a href="mailto:Webmaker-dev@mozilla.org" target="_blank">Webmaker-dev@mozilla.org</a>
<a href="https://mail.mozilla.org/listinfo/webmaker-dev" target="_blank">https://mail.mozilla.org/listinfo/webmaker-dev</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>Webmaker-dev mailing list<br><a href="mailto:Webmaker-dev@mozilla.org" target="_blank">Webmaker-dev@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/webmaker-dev" target="_blank">https://mail.mozilla.org/listinfo/webmaker-dev</a><br>
</blockquote></div><br></div></div></div><br>_______________________________________________<br>
Webmaker-dev mailing list<br>
<a href="mailto:Webmaker-dev@mozilla.org" target="_blank">Webmaker-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/webmaker-dev" target="_blank">https://mail.mozilla.org/listinfo/webmaker-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Webmaker-dev mailing list<br>
<a href="mailto:Webmaker-dev@mozilla.org" target="_blank">Webmaker-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/webmaker-dev" target="_blank">https://mail.mozilla.org/listinfo/webmaker-dev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>