blob: 2068d24325b7e943b1367b84decf8c77d221f72c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
\documentclass[11pt]{article}
\title{Bcfg2 Repository Design}
\author{Narayan Desai \\ desai@mcs.anl.gov}
\setlength{\oddsidemargin}{0in}
\setlength{\evensidemargin}{0in}
\setlength{\topmargin}{0.0in}
\setlength{\headheight}{0in}
\setlength{\headsep}{0.5in}
\setlength{\textwidth}{6.5in}
\setlength{\textheight}{8.5in}
\setlength{\parskip}{0.05in}
\begin{document}
\maketitle
The BCFG repository is the storage depot for all components of client
configurations. In BCFG1, this depot was composed of several SQL
database tables and a filesystem hierarchy, composed of several types
of data.
One of the high-level features desired from BCFG from the start was
the ability for configuration changes, acquired through some automated
mechanism, to be correctly installed into the configuration
repository. While using this ad-hoc repository, the underlying
structure of data made automatic inclusion of new configuration
fragments difficult. To address this problem, we have redesigned the
repository to allow better data access and update semantics.
\section{Why is an ad-hoc repository problematic?'}
\section{Design}
\end{document}
|
