Initial set of proposed release criteria for Server product
by Adam Williamson
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@.)
* It must be possible to forward system logs from one system running the
release to another using rsyslog.
* After system installation, the system firewall must be active, and the
only ports which may be open are port 22 and any ports associated with
server Roles selected during installation. [pace explicit kickstart
configuration]
* After system installation, SELinux must be enabled and in enforcing
mode. [if user does not explicitly request otherwise via cmdline or
kickstart]
* It must be possible to join the system to a FreeIPA or Active
Directory domain, and the system must respect the identity,
authentication and access control configuration provided by the domain.
[details as subnotes]
The bits in square brackets are rough notes; they indicate things that
would be expanded on via the 'expandable sub-notes' mechanism used on
the release criteria pages at present (see any of the release criteria
pages, e.g.
https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria ). The
text given above would be the 'main text' for each criterion. We haven't
yet really settled the question of how exactly the presentation of the
criteria needs to be done in a Product world, but we can consider the
actual additional criteria that are required more or less independently
of how they should be presented, I think.
This set of criteria are the ones I think need to be added to 'back' the
tech spec,
https://fedoraproject.org/wiki/Server/Technical_Specification ,
*excluding* Role functionality - I expect we'll need a whole subset of
criteria for Role functionality, so I figured I can write that up as a
separate batch to keep each chunk a manageable size.
There are two areas which probably need to be captured with a criterion,
but which I couldn't really write one for yet because of vagueness in
the spec. One is problem reporting mechanisms - see my separate mail on
that topic. The other is remote system management. The spec says:
"Software updates on the Fedora Server must be possible to perform
either locally using command-line tools (e.g. yum/dnf)..."
(okay, we already cover that in current criteria)
"...or centrally by common management systems (e.g. Puppet, Chef,
Satellite, Spacewalk, OpenLMI)."
well, that's extremely broad. Do we really want to have the criteria say
"it must be possible to update a Fedora Server system via Puppet, Chef,
Satellite, Spacewalk or OpenLMI", write a test case for each, and block
releases unless all of those mechanisms work? Or do we want to focus
down a bit?
Thoughts on the proposed criteria, the remote update issue, or any other
criteria we might need beyond the existing 'core' criteria and the ones
for Role functionality would be great! Thanks folks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 10 months
Server WG Meeting Minutes (2014-06-17)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-06-17)
===================================================================
Meeting started by sgallagh at 15:01:27 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-06-17/fedora-meeti...
.
Meeting summary
- ---------------
* roll call (sgallagh, 15:01:34)
* Agenda (sgallagh, 15:05:27)
* Agenda Topic: Release Criteria (sgallagh, 15:05:33)
* Agenda Topic: Server Role Daemon Naming (sgallagh, 15:05:37)
* Release Criteria (sgallagh, 15:07:46)
* LINK:
https://fedoraproject.org/wiki/User:Adamwill/Draft_server_release_criteria
(sgallagh, 15:08:09)
* ACTION: adamw to clarify "at install" phrasing to mean "running at
the conclusion of the first boot-up after installation concludes"
(sgallagh, 15:14:43)
* ACTION: adamw to reword "role deployment" criterion to be a bit
vaguer (as part of install-time role deployment may happen during
firstboot) (adamw, 15:24:42)
* ACTION: adamw to revise firewall criterion to allow port to be open
for access to Cockpit web management console (adamw, 15:25:02)
* ACTION: adamw to write criterion requiring Cockpit web management
console to be available OOTB (adamw, 15:25:28)
* Server Role API must *eventually* support blocking ports by network
interface, but this feature is eligible for deferral in Fedora 21
(sgallagh, 15:27:39)
* LINK:
http://www.iana.org/assignments/service-names-port-numbers/service-names-...
(tuanta, 15:39:35)
* ACTION: sgallagh to work with Cockpit team to find memorable port
for reservation (sgallagh, 15:40:46)
* Server Role Daemon Naming (sgallagh, 15:57:38)
* Proposed Name: RoleD/roled (sgallagh, 15:57:38)
* Proposed Name: thespian (sgallagh, 15:57:39)
* Proposed Name: RoleKit (sgallagh, 15:57:39)
* Proposed Name: RoleMgr (sgallagh, 15:57:39)
* Proposed Name: RoleManager (sgallagh, 15:57:40)
* Proposed Name: Serverd (simo, 15:59:42)
* Proposed Name: RoleCtl (sgallagh, 16:07:07)
* AGREED: Project will be named 'rolekit', it's daemon will be 'roled'
and its command-line interface will be 'rolectl' (sgallagh,
16:10:35)
* Open Floor (sgallagh, 16:10:41)
* ACTION: simo to chair next week's meeting (sgallagh, 16:14:46)
Meeting ended at 16:15:24 UTC.
Action Items
- ------------
* adamw to clarify "at install" phrasing to mean "running at the
conclusion of the first boot-up after installation concludes"
* adamw to reword "role deployment" criterion to be a bit vaguer (as
part of install-time role deployment may happen during firstboot)
* adamw to revise firewall criterion to allow port to be open for access
to Cockpit web management console
* adamw to write criterion requiring Cockpit web management console to
be available OOTB
* sgallagh to work with Cockpit team to find memorable port for
reservation
* simo to chair next week's meeting
Action Items, by person
- -----------------------
* adamw
* adamw to clarify "at install" phrasing to mean "running at the
conclusion of the first boot-up after installation concludes"
* adamw to reword "role deployment" criterion to be a bit vaguer (as
part of install-time role deployment may happen during firstboot)
* adamw to revise firewall criterion to allow port to be open for
access to Cockpit web management console
* adamw to write criterion requiring Cockpit web management console to
be available OOTB
* sgallagh
* sgallagh to work with Cockpit team to find memorable port for
reservation
* simo
* simo to chair next week's meeting
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (116)
* adamw (64)
* simo (60)
* stefw (49)
* nirik (18)
* tuanta (11)
* twoerner (10)
* zodbot (9)
* mizmo (8)
* danofsatx-work (6)
* davidstrauss (6)
* jsmith (3)
* mitr (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOgaeoACgkQeiVVYja6o6OfcACggiHJ0zfkaTxjrwdCNEP6apnf
ALAAn0BRJGn7mtTfnuUY9Kfc/mALCuMG
=pjg1
-----END PGP SIGNATURE-----
9 years, 10 months
Agenda for Server WG Meeting (2014-06-17)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
#startmeeting Server Working Group Weekly Meeting (2014-06-17)
#chair sgallagh mizmo nirik davidstrauss stefw adamw simo tuanta mitr
#topic roll call
#topic Agenda
#info Agenda Topic: Release Criteria
#info Agenda Topic: Server Role Daemon Naming
#topic Release Criteria
#topic Server Role Daemon Naming
#info Proposed Name: RoleD/roled
#info Proposed Name: thespian
#info Proposed Name: RoleKit
#info Proposed Name: RoleMgr
#info Proposed Name: RoleManager
#topic Open Floor
#endmeeting
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOgQ0QACgkQeiVVYja6o6O54gCbBfFYFFEmIoj2HUeHOCEB1owV
y0AAoK+c2f1ovZXLrui4RjK4t/fr1ZPO
=9ifU
-----END PGP SIGNATURE-----
9 years, 10 months
What's in a name?
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Now that we've got a pretty good idea of what the Role API needs to
look like, we need to start putting together the daemon to control it.
Any good open-source project needs a name, so here's where you get to
make your recommendations :)
So far, I've got:
* "RoleD" - Keeping with a recent theme in Fedora
* "thespian" - Synonym for actor/actress, or "someone who plays
multiple roles"
What's your best idea?
Once we come up with a name, I'll set up a Fedora Hosted project to
track it. Let's get as many suggestions as we can by Tuesday's WG
meeting and then select it there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlObMD0ACgkQeiVVYja6o6NNtwCfapKBNAUunq99QNIm0A0i5oAo
+1AAoIaIKusWPCbZaLL8CDqr8EZtFS/3
=BIVY
-----END PGP SIGNATURE-----
9 years, 10 months
Soliciting agenda items for 2014-06-17 meeting
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What is on our list this week, folks?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlObB5gACgkQeiVVYja6o6ML5wCggQ8XzeFwYybemvNrrs9AkL1B
+UsAn3ZpGzsD5NCCjfPfPLJBiGJpUgTp
=TBDo
-----END PGP SIGNATURE-----
9 years, 10 months
Server Role States
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas Woerner, Miloslav Trmač and I had a long discussion the other
day about how to handle states in the Role API. We came up with the
following approach:
Persistent States:
Nascent[1] (We know about the Role but have not attempted to deploy it)
ReadyToStart (It has been installed and configured but is not running)
Running (Self-explanatory)
Error (Something has gone wrong and needs to be corrected to return
the system to ReadyToStart[2])
Transitional States (used to indicate that other clients should not
interfere):
Deploying
Decommissioning
Starting
Stopping
I've attached a graphviz document and a rendered PNG of the state
diagram to hopefully make it clear. Comments and feedback welcome, but
our intent is to be off and implementing before the end of the week.
[1] While we were discussing this, we had "Known, not deployed" as a
placeholder here. I think "nascent" covers this elegantly, but if
others have a better idea, the name is not set in stone.
[2] There will be two ways to recover from the Error state. The client
can call deploy() again and fix the issue, or they can call
resetError() which will short-cut to ReadyToStart. This is how they
can proceed if they choose to fix the error with manual edits that the
API doesn't understand. resetError() should be a last resort.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOXFEgACgkQeiVVYja6o6NgjgCfdl3/ZOlUU4BUaUtMp4apkdGb
54wAn3+f1iuG+omWrOPfrHxNEsWEtwjS
=pn9o
-----END PGP SIGNATURE-----
9 years, 10 months
"Problem reporting" section of tech spec rather loose
by Adam Williamson
I'm currently drafting some rough proposed release criteria for Server,
heavily based on the tech spec. I notice the "Problem reporting" section
of the spec is somewhat loose. It reads:
"Problem reporting
Problems and error conditions (e.g. kernel oopses, Selinux AVCs,
application crashes, OOM, disk errors) should all be reported in the
systemd journal.
Support for sending this information to a central place (like abrt does
for crashes today) is mandatory."
the word "must" appears multiple other times in the page, so we have the
old chestnut of whether we're using "must" and "should" with strict
definitions, or as synonyms, or what. And then the second paragraph
throws in another candidate: "Support...is mandatory". What exactly is
"is mandatory" supposed to mean in this context? Such "support" must be
*available* in Server? It must be *installed* (and enabled?) for the
system to count as a "Fedora Server system"? Both of these are possible
interpretations. What do we mean by "a central place"? Does a log server
qualify, or do we mean a *public*, *shared* repository, for communal
troubleshooting?
The definition of "problems and error conditions" is also both vague and
apparently wide. There is no precise definition - "e.g." means "for
example", i.e. it is not comprehensive. But just the things listed in
the "e.g." clause are quite broad:
"kernel oopses, Selinux AVCs, application crashes, OOM, disk errors"
abrt handles kernel oopses and crashes. setroubleshoot handles AVCs. We
do not to my knowledge have anything that submits OOM conditions or
"disk errors" to "a central place" in the style of abrt or
setroubleshoot. I'm not even sure that it makes any sense to send them
to some kind of public issue concentrator, given that these are as
likely to indicate local configuration issues or hardware problems as
they are to indicate bugs in Fedora Server.
So...do we feel this needs cleaning up / clarifying? Anyone who was
involved in drafting this bit remember what the intent was?
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 10 months
Cancel today's meeting? (2014-06-10)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I forgot to send out a call for agenda, but from the discussions on
the list I don't think we have anything urgent to discuss. If I am
mistaken, please correct me.
Otherwise, let's continue talking on the mailing list or in
#fedora-server.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOW52AACgkQeiVVYja6o6M2ywCgrNDX6fEHYUNiuN3nf725ZJtT
RUkAniF6PQDz7LZ8LGyGcuqkBfk20lcF
=xL7R
-----END PGP SIGNATURE-----
9 years, 10 months
