[Proposal] Make application configuration easier

Gavin Suntop gavin at mozillafoundation.org
Mon Jun 2 17:18:51 PDT 2014


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.

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”.

I took this approach on the CSP Logger Service - https://github.com/mozilla/csp-logger

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.

+

Gavin Lazar Suntop

irc, twitter, github:  gvn

On Jun 2, 2014, at 3:42 PM, David Humphrey <david.humphrey at senecacollege.ca> wrote:

> 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.
> 
> Dave
> 
> On 14-06-02 6:38 PM, Kate Hudson wrote:
>> 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
>> 
>> - K
>> 
>> On Jun 2, 2014, at 6:02 PM, Kate Hudson <kate at mozillafoundation.org> wrote:
>> 
>>> 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.
>>> 
>>> I would love to see us think about the debugging/error resolution process for common pitfalls in this system, such as:
>>> 
>>> - How do we debug/see which files actually get loaded, and in what order?
>>> - What if our secret files on s3 contain a legacy env variable? Would it overwrite the committed environment files? How would we know?
>>> - Do we still have env.sample (probably not)?
>>> - What if we want to unset certain env variables (e.g. DEV) that are defined in default files
>>> 
>>> - Kate
>>> 
>>> On Jun 2, 2014, at 5:38 PM, Jon Buckley <jon at mozillafoundation.org> wrote:
>>> 
>>>> Here’s something that really gets my goat: app configuration
>>>> 
>>>> 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`.
>>>> 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.
>>>> 3) Configuration only via process env (e.g. heroku) is tedious because there are so many env variables.
>>>> 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.
>>>> 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.
>>>> 
>>>> Therefore a better application configuration solution should:
>>>> 1) Work out of the box
>>>> 2) Work when pulling down updates
>>>> 3) Work with process.env
>>>> 4) Be version controlled, preferably using git
>>>> 5) Doesn’t require devops to co-ordinate a simultaneous code + config deploy
>>>> 
>>>> My preferred solution is the following:
>>>> - Modify habitat to support loading multiple environment files in a specific order: https://github.com/brianloveswords/habitat/pull/11
>>>> - Add multiple configuration files to each applications repository - staging.env, production.env, defaults.env
>>>> - Code application to support loading from these new locations in order:
>>>>  - process environment
>>>>  - .env
>>>>  - NODE_ENV.env (so staging.env or production.env)
>>>>  - defaults.env
>>>> - Document this workflow in each app as “MAINTENANCE.md” or something similar.
>>>> 
>>>> 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.
>>>> 
>>>> Thoughts?
>>>> _______________________________________________
>>>> Webmaker-dev mailing list
>>>> Webmaker-dev at mozilla.org
>>>> https://mail.mozilla.org/listinfo/webmaker-dev
>>> 
>>> _______________________________________________
>>> Webmaker-dev mailing list
>>> Webmaker-dev at mozilla.org
>>> https://mail.mozilla.org/listinfo/webmaker-dev
>> 
>> 
>> 
>> _______________________________________________
>> Webmaker-dev mailing list
>> Webmaker-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/webmaker-dev
> 
> _______________________________________________
> Webmaker-dev mailing list
> Webmaker-dev at mozilla.org
> https://mail.mozilla.org/listinfo/webmaker-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/webmaker-dev/attachments/20140602/e08cbe34/attachment-0001.html>


More information about the Webmaker-dev mailing list