On Tue, Dec 12, 2017 at 11:15 AM, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
Something the current capabilities/requirements stuff doesn't
handle is the
fact that some capabilities can be configured but won't be turned on in some
situations (i.e. admin-only). Which means other capabilities that might
require them and that are present in admin-only will pass configuration
consistency checks but will fail at runtime.
I'm not sure what to do about this. Some off the top of my head thoughts:
1) The capability description data on wildly-capabilities includes something
about this, so people who want to require the capability understand whether
it can be required.
This is easy, and helps avoids future bugs. It's just documentation so it
does nothing about the actual server behavior.
2) The registration for capabilities could include "minimal running-mode"
data, and then the capability resolution could check that and fail if it
finds a mismatch in the current running mode.
I'm inclined towards this option. But...
This is more work obviously. It may help surface problems earlier,
i.e. make
it more likely that a testsuite catches a mismatch in time to correct it
before a .Final release. It would also have the minor benefit of perhaps
providing a better error message for a user who configures a mismatch.
It'd be best if we can detect this more up front if possible. If this
kind of mismatch occurs, I think it would never be the user's fault.
--
- DML