2:19 p.m.
TL;DR Should ipaplatform be dynamic or fixed at build time?
Last November a ticket was proposed to change the platform detection
from being done at build time (via autoconf) to runtime in ticket
https://pagure.io/freeipa/issue/6474
This was inspired somewhat by
http://www.freeipa.org/page/V4/Integration_Improvements
This consisted of two main proposals:
1. Let one specify the location of the IPA configuration so that clients
not enrolled via ipa-client-install can still work (e.g. you can use it
completely as non-root).
2. Make ipaplatform dynamically detect the underlying OS for use in PyPi.
Discussion on this proposal happened in thread
https://www.redhat.com/archives/freeipa-devel/2016-November/msg00391.html
Discussion continued in the PR,
https://www.redhat.com/archives/freeipa-devel/2016-November/msg00887.html
From my reading no firm decision (beyond pushing the code) was made
except that there was resistance to both of these proposals. The
relevant part for now is ipaplatform. Moving around a bunch of code
ended up being quite disruptive internally and wasn't ultimately
completely successful, see https://github.com/freeipa/freeipa/pull/1036
The boat has sailed on moving the code around but the moves were
disruptive to anything that was using ipalib (another discussion
altogether is the supportabilty/stability of ipalib).
What we're left with is that the PyPi build is currently broken and has
been for several weeks. The current proposed fix is to duplicate values
which while undesirable generally is a quick and dirty way to get PyPi
working. Felipe agreed to update his PR to use a _ prefix to indicate
the constants are for internal-use only. This should buy us time to work
on a more complete solution.
So to me the question is dynamic vs build-time detection of the
underlying OS. If one lives in the world of only OS-distributed packages
then build-time detection makes perfect sense and leaves no room for
error on deployed systems.
PyPi is another story though. The PyPi version doesn't ship ipaplatform
at all which makes PyPi a bit of a second-class citizen. This could
impact future systems like ansible that might want to deploy from PyPi,
and tox which often installs its own dependencies during testing. PyPi
also lets one easily install different versions of packages in different
virtual environments for expanded testing without requiring root.
IMHO something needs to change. Felipe's PR has the feeling of the first
of a thousand cuts. I'm in favor of runtime detection with extreme, if
not ridiculous logging. The major downside of runtime detection, which
wasn't discussed previously, is opaqueness: you can't tell why things
are behaving as they are because the runtime choice was opaque. With
copious debug-level logging I think this would be a moot point. Bugs may
still occur with detection but they will hopefully be painfully obvious
and easily fixable.
The main opposition to runtime dependency seemed to me to be related to
handling failures gracefully. I think a hard stop with tons of output is
sufficient to handle this case. All major distros already do a lot of
testing pre-release which would catch any issues. There remains some
risk for bleeding-edge releases that could make changes post-release.
If /etc/os-release goes away then this would have to be dealt with in
the installer anyway, the impact will just be broader (and therefore
likely fixed faster).
It may be worthwhile to collect /etc/os-release from as many Linux
distros as possible to ensure the best level of compatibility.
A final else "Your distro is not supported" will handle things we have
not encountered yet, or targeted (e.g. win32, Solaris, etc). Support for
these could be contributed.
rob