[389-devel] Feature gating discussion
Hi all,
Something that has been on my mind lately has been how we manage the
release of new features, reverting, and more. We've had two major
reverts lately (filter optimising, nunc-stans), so I've been thinking
about:
* How we can develop new features in isolation (reviews don't get left
for months because we don't know if they are "ready")
* How we can revert without "git revert"
* How we can test
* How we can release features when we are ready.
I've been thinking that what we did with nunc-stans is pretty close to
what we want, but we need some refinement. "Feature gating" is where we
have a series of on/off switches for features. This way we can release
with features in the "off" state, and enable them in testing and when
we are ready to release. When we are happy, we set them "on". If an
issue happens, we can disable them, or if they are good, we eventually
can remove the switch.
At the moment we do this in cn=config but the issue is if users ever
set their own values - suddenly our defaults-upgrade mechanism won't
work because we always respect the user values. This means features
being in the "on" state when we want to revert, and features in the
"off" state when we want to enable them on release. This also has an
issue in bootstrapping during ds setup becuase we need the server built
to enable the feature, but enabling the feature may break the setup.
Additionally, we may want the feature we are testing to be part of
cn=config, so that creates a "chicken and egg problem".
I'm wondering if we should add a different feature gating mechanism.
First, this mean cn=config is "just configuration" and we avoid the
above. It also means we resolve some of the above issues, and we can
more easily test.
A few ideas:
* defaults.inf can list booleans that we read early in ns-slapd startup
* environment variables (these can be passed from systemd units or
lib389)
* command line switches (passed in lib389 or systemd args)
For example, there is a really substantial patch for NS that's been
outstanding since march, slapi v4 that has been there since late last
year. If we can apply them but "disable", it means we can test and get
confidence, the code is not "rotting". I think it's a nice balance
between "innovate and change" and "conservative changes and confidence
in releases".
What do we think?
--
Sincerely,
William