veyepar: How Mozilla draws the line between configuration and data while using configuration management tools

Author(s):	Brian Hourigan,Justin Dow
Location	MCC5
Date	feb Fri 01	Days Raw Files
Start	11:35	First Raw Start	error-in-template
Duration	0:45:00	Offset	None
End	12:20	Last Raw End
Chapters
Total cuts_time	None min.

http://lca2013.linux.org.au/schedule/30159/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf How_Mozilla_draws_the_line_between_configuration_and_data_while_using_configuration_management_tools.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:

Locked:

clear this to unlock

Locked by:

user/process that locked.

Start:

initially scheduled time from master, adjusted to match reality

Duration:

length in hh:mm:ss

Name:

Video Title (shows in video search results)

Emails:

email(s) of the presenter(s)

Released:

has someone authorised pubication

Normalise:

Channelcopy:

m=mono, 01=copy left to right, 10=right to left, 00=ignore.

Thumbnail:

filename.png

Description:

markdown

How Mozilla draws the line between configuration and data while using configuration management tools - with Brian Hourigan and Justin Dow from Mozilla Corporation.

As each quarter passes Mozilla depends on configuration management more and more. It's a formal goal to have all of our systems under configuration management. Ideally, no system should ever have data that a configuration management engine doesn't know about.

How do you draw the line between configuration data and content? If you're maintaining a web server and have a few hundred kb of data in the DocumentRoot it may make sense to store everything in a VCS. If you're maintaining a mrepo/cobbler system, people will notice (and probably complain) if you add 6GB of binary data to a VCS.

We all know backups are important. "Backup all the things" is a great motto to live by, but often it is the time you spend installing and configuring a server that is lost during a disaster. Not just the data. Configuration management can go a long way in that regard, but it might not be appropriate for everything. If you are maintaining your own RPMs, you don't want to check all your RPMs into your VCS and lug those around with you. There is a concept of "data" and there is a concept of "configuration". Both of these are very important to all aspects of systems administration, and a VCS might be appropriate for configuration and plain text data, but not necessarily for binary data. Backups might be appropriate for data, but not necessarily for configuration. Where do you draw the line? How do these strategies work together? What if you have nightly backups of your data, but not of your configuration? How much time do you want to spent restoring a backup, just to get your software's configuration back? What if your new guy accidentally inserted a space after the leading slash in his "sudo rm -rf" command and wiped out half of your server? Where do you start to get that server back up and running exactly how it was, with both the data and the configuration intact?

We will go into depth on the following points using free and open source software:

- How do you distinguish configuration data from content?
- Where should you keep it?
- How do you implement version control on data that isn't meant for a version control system?
- How do you customize this data for just a few systems?

Comment:

production notes