On Fri, 2014-06-06 at 15:55 -0700, Adam Williamson wrote:
Hi, folks. Here's my initial dump of proposed release criteria
specific
to Server. This is primarily a Server WG responsibility (per the draft
test plan -
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_21_test_plan -
and the discussion of same), but CCing test@ as I know some folks there
will be interested. Please ensure follow-ups *at least* go to server@
(no follow-ups only to test@.)
I've now cleaned up three of the proposed criteria and posted them in
the 'stock format' here:
https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria
I did some refinements as I wrote. Things tend to occur to you as you
write release criteria. Do check over the notes. Particularly, there's
this, from the firewall criterion:
"Should kickstart firewall options conflict with the settings that would
otherwise result from a deployed server role, the kickstart options must
take precedence."
that seems to make sense to me, but assuming everyone agrees that's how
it should be, we need to design the anaconda server role integration in
that way. If everyone thinks I'm nuts and we should resolve conflicts
the other way around...we need to do the implementation that way around.
It's something we need to take into account, is what I'm sayin'. :)
Also note "the system firewall must be active on all non-loopback
interfaces" and "The only ports which may be open to incoming traffic" -
I think those are correct/appropriate clarifications. Also note
"Supported install-time firewall configuration options must work
correctly." - I think it's reasonable to require that, but it does
introduce a moderate burden of testing and installer functionality. Full
testing might involve four install runs. One 'clean' one, one with just
a server role configured, one with a big set of kickstart firewall
directives, one with both server role and kickstart firewall directives
to test the conflict case. We could do a milestone split; maybe the
'port 22 only on clean install' part at Alpha, 'server role' bits at
Beta, and 'kickstart and role/kickstart conflict' parts at Final, or
something like that?
You'll note one criterion missing, because I spotted a rather big
ambiguity. It's the remote auth configuration one. The tech spec says:
"The Fedora Server is expected to nearly always be configured for
'centrally-managed' user information; it must be possible to configure
it to rely on a directory service for this information. Fedora Server
will provide and support the realmd project for joining FreeIPA and
Active Directory domains automatically. Interacting with other identity
sources will remain a manual configuration effort."
What it never says is whether this is expected to work *at install time*
or post-install. My guess would be that we'd want to have install time
configuration of this, but I wanted to clarify it before writing it into
the criteria.
Note that this is *not currently the case*. anaconda does not have any
remote auth configuration support of which I'm aware at present. (I'm
kinda surprised it wasn't considered a blocker for RHEL 7, in all
honesty, but hey, RHEL ain't my beat). So if we wanted to block on that,
we'd need to work out a plan with anaconda devs to have it implemented,
ideally by Alpha.
Thoughts on all the above? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net