Configurable /mnt/state
This spec covers making the top level directory where persistent and stateful data is written to configurable. Currently this top level path is hardcoded to /mnt/state in our os-apply-config templates, os-refresh-config scripts, and other element scripts. If the path is configurable, that opens the door for different read only root implementations when TripleO is ready for read only root. In particular, the fedora-readonly systemd approach uses bind mounts so that services do not need to be reconfigured at all in their configuration files. Change-Id: Ifdaf31a97a76d69d89c0b5f48714cedfb3cf7b06
This commit is contained in:
James Slagle
parent
35c975a2b3
commit
209665d62d
|
|
@ -0,0 +1,172 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
=======================================================
|
||||
Configurable directory for persistent and stateful data
|
||||
=======================================================
|
||||
|
||||
# TODO: file blueprint
|
||||
https://blueprints.launchpad.net/tripleo
|
||||
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
The directory on instances where persistent and stateful data is stored should
|
||||
not be hardcoded to /mnt/state and instead be configurable.
|
||||
|
||||
This change would allow distros that have a built-in read only root feature to
|
||||
make use of those features as they exist today. In particular, Red Hat style
|
||||
distros offer a read only root feature that is implemented via bind mounts. In
|
||||
this case the stateful path would be configured to be /. A new
|
||||
tripleo-image-element that relied on this feature would take care of creating
|
||||
the configuration files that setup this read only root feature.
|
||||
|
||||
It's important to realize that this read only root implementation would still
|
||||
make use of a stateful partition mounted at a known location such as
|
||||
/mnt/state. It's different though in that the bind mounts enable you to
|
||||
reconfigure more centrally then in many different configuration files.
|
||||
|
||||
This implementation is attractive because there is less to reconfigure in
|
||||
individual service's configuration files to re-point all paths to /mnt/state.
|
||||
Configuration files look more similar to upstream versions and well known
|
||||
filesystem paths are still used (such as /var/log, /var/lib). This is friendly
|
||||
to deployers.
|
||||
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
In order to make the stateful path configurable, all of the hardcoded
|
||||
references to /mnt/state in os-refresh-config scripts would be replaced with an
|
||||
environment variable, $STATEFUL_PATH.
|
||||
|
||||
$STATEFUL_PATH would be set in an environment.d script that is provided by a
|
||||
specific element that configures the path to the desired location. If
|
||||
/mnt/state is the desired location, a mnt-state element could do the following
|
||||
in os-refresh-config/environment.d/00-set-stateful-path:
|
||||
|
||||
export STATEFUL_PATH=/mnt/state
|
||||
|
||||
os-apply-config also needs access to the value set by $STATEFUL_PATH since the
|
||||
path would be used in template config files. The templates themselves would be
|
||||
updated to replace the hardcoded /mnt/state with {{stateful-path}}. The
|
||||
mnt-state element could then install a json file that sets stateful-path equal
|
||||
to /mnt/state. An additional environment.d script in the mnt-state element
|
||||
would modify and export OS_CONFIG_FILES to include this json file. When
|
||||
os-apply-config is run, it will read the value for stateful-path from this json
|
||||
file.
|
||||
|
||||
Any element that wished to configure the stateful path could configure it in a
|
||||
similar manner.
|
||||
|
||||
# TODO(slagle)
|
||||
In either case whether /mnt/state is hardcoded or the Fedora style read only
|
||||
root support is desired we are effectively maintaining a list of all
|
||||
stateful/persistent paths. When /mnt/state is used, we have to know all the
|
||||
paths and update them across a set of config files and scripts. When the Fedora
|
||||
support is used, we have to list all the paths and directories in /etc/statetab
|
||||
and /etc/rwtab. It seems like the fedora-state element could just maintain this
|
||||
list on it's own since it is the element that cares about it, but if it is
|
||||
useful to other elements we should instead make it reusable and consumable in
|
||||
some fashion.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
None come to mind, the point of this spec is to enable an alternative to what's
|
||||
already existing. There may be additional alternatives out there other folks
|
||||
may wish to add support for.
|
||||
|
||||
Security Impact
|
||||
---------------
|
||||
None
|
||||
|
||||
Other End User Impact
|
||||
---------------------
|
||||
End users using elements that change the stateful path location from /mnt/state
|
||||
to something else will see this change reflected in configuration files and in
|
||||
the directories used for persistent and stateful data.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
None.
|
||||
|
||||
Other Deployer Impact
|
||||
---------------------
|
||||
Deployers will be able to choose different elements that may reconfigure the
|
||||
stateful path. The default will remain unchanged however. The mnt-state element
|
||||
could have "stateful-path" in its element-provides and other elements that wish
|
||||
to override that could also provide "stateful-path". This would work the same
|
||||
way as we have multiple elements providing "mysql", and if one of the elements
|
||||
is specified explicitly, that is the one that will get used.
|
||||
|
||||
Deployers would have to know what the stateful path is, and if it's different
|
||||
across their environment, this could be confusing. However, this seems unlikely
|
||||
as deployers are likely to be standardizing on one set of common elements,
|
||||
distro, etc.
|
||||
|
||||
Developer Impact
|
||||
----------------
|
||||
TripleO developers will have the option of choosing the element they want that
|
||||
provides a stateful-path.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
james-slagle
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
tripleo-image-elements
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
* Add a new mnt-state element that configures stateful-path and $STATEFUL_PATH to /mnt/state
|
||||
* Update os-apply-config templates to replace /mnt/state with {{stateful-path}}
|
||||
* Update os-refresh-config scripts to replace /mnt/state with $STATEFUL_PATH
|
||||
* Add redhat-state element that sets up / as the stateful path.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
There is currently no testing that all stateful and persistent data is actually
|
||||
written to a stateful partition.
|
||||
|
||||
We should like add tempest tests that directly exercise the preserve_ephemeral
|
||||
option, and have tests that check that all stateful data has been preserved
|
||||
across a "nova rebuild". Tempest seems like a reasonable place to add these
|
||||
tests since preserve_ephemeral is a Nova OpenStack feature. Plus, once TripleO
|
||||
CI is running tempest against the deployed OverCloud, we will be testing this
|
||||
feature.
|
||||
|
||||
We should also test in TripleO CI that state is preserved across a rebuild by
|
||||
adding stateful data before a rebuild and verifying it is still present after a
|
||||
rebuild.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
We should document any new elements and also the Fedora read only root support
|
||||
when available.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
Red Hat style read only root support this would enable:
|
||||
https://git.fedorahosted.org/cgit/initscripts.git/tree/systemd/fedora-readonly
|
||||
https://git.fedorahosted.org/cgit/initscripts.git/tree/sysconfig/readonly-root
|
||||
https://git.fedorahosted.org/cgit/initscripts.git/tree/statetab
|
||||
https://git.fedorahosted.org/cgit/initscripts.git/tree/rwtab
|
||||
Loading…
Reference in New Issue