Proposal for the Server Role API
by Thomas Woerner
Hello,
here is the proposal for the Server Role API:
* Plugin architecture
* Daemon must exit, when not in use (all D-Bus clients exited)
D-Bus server API:
org.fedoraproject.ServerRoleManager1
------------------------------------
Properties
version:s # server role manager version
state:s # active/inactive/dead?
roles:ao # role objects list
Methods
getRole(role:o)→o # get role by object
getNamedRole(name:s)→o # get role by name
getActiveRoles()→ao # get active role object list
org.fedoraproject.ServerRoleManager1.roles.$n
---------------------------------------------
Properties (general) # role settings
name:s (ro) # role name
version:s (ro) # role version
state:s (ro) # deployed/started/inactive/dead?
activate_time:i (ro) # time of activation
deploy_time:i (ro) # time of deployment
is_configured:b (ro) # is this role configured?
packages:as (ro) # packages and @groups
services:a{sas} (ro) # services to be enabled and/or started:
"enable": [s] and "start": [s]
firewall:a{sas} (ro) # firewall dict ports: [s] and service: [s]
#backup_paths:as # backup files and directories (directory
trailing slash it means "everything below here")
# ... # custom settings, passwords as key value pairs
Methods
deploy() # deploy role (i.e. running initial setup
post-package-install, ipa-server-install)
decommission() # decommision (example: moved to another
machine, ipa-server-install -u ), stop if started
start() # start the role (startServices,
installFirewall), fails if not deployed
stop() # stop the role (stopServices,
uninstallFirewall), fails if not started
updateRole() # update role: yum update; restartServices;
updateFirewall
reconfigureRole(a{sv}) # reconfgure role with new config settings
as key value pairs
installPackages() # install packages and groups
#uninstallPackages() # uninstall packages and groups, fails if
deployed - not initially
startServices() # start the services
restartServices() # restart the services
stopServices() # stop the services
installFirewall() # install firewall ports/services
updateFirewall() # update firewall ports/services
uninstallFirewall() # uninstall firewall ports/services
8 years, 9 months
Soliciting agenda items for 2014-06-03 meeting
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What shall we put on the agenda this week? We didn't get to the
branding discussion last week, so we should probably include that.
ARM support for Fedora Server?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOIohoACgkQeiVVYja6o6MX1wCfbWEHWuy8QOM+tBBHt33cnbMw
7m4An3bH4f/F56+e49F+E/Zbnawx+qFz
=gVkI
-----END PGP SIGNATURE-----
8 years, 9 months
Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
by Adam Williamson
Hi, folks. So continuing with the theme of setting up the Fedora.next QA
process, I thought before going too far with draft release criteria etc,
we could discuss a couple of important points that have come up since I
sent out the draft test plan.
There are two kind of similar issues in particular I'm thinking of.
First, at the QA meeting this week, tflink pointed out that we would
need to decide whether we will have sort of 'parallel' blocker/freeze
exception bug processes for each product. That is, do we have:
F21FinalBlocker
F21ServerFinalBlocker
F21WorkstationFinalBlocker
etc etc, and separate lists of blockers on
http://qa.fedoraproject.org/blockerbugs/current per product (and
non-Product-specific), and separate meetings? Or do we keep the
'unified' blocker nomination / review process, and just handle blocker
bugs for all Products within it?
At first blush I'd incline to keeping a single unified process, because
splitting them up seems like an awful lot of work and I'm not sure it
comes with a clear benefit. It also relies either on reporters correctly
determining what product their bug is relevant to, or on a triage step
for blocker nominations.
However, it's worth noting that if we allow the release schedules for
the Products to diverge in future, it would probably then be inevitable
that we'd need split blocker review (and release validation, for that
matter).
Second, there's a similar issue of organization with regard to the
release criteria. I haven't explicitly written this down anywhere, but
I've been sort of unconsciously expecting that we'd keep the existing
'generic' release criteria pages for criteria that are not
Product-specific, and then we'd have Product-specific release criteria
pages which would basically be *additive*: they'd add additional
criteria applicable only to that Product. They could also perhaps
'patch' the generic criteria to a limited degree, though this would get
messy if the delta got too great.
However, Mike (roshi) has produced draft release criteria for the Cloud
product as part of his work on the 'test outline' for that product -
https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Relea... , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Beta_Releas... , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Final_Relea... - and used another possible approach; the criteria he has drawn up are clearly intended to be *comprehensive* with regard to the Cloud product. They would not need to be read in conjunction with the 'generic' criteria.
I'm not as sure which approach I prefer here, and to a degree the
difference between them isn't as clear cut as it appears at first
glance; however the criteria are ultimately presented, we'll likely have
several that are applicable to multiple Products. Even if these are
displayed multiple times on 'comprehensive' pages for each Product, they
might be shared at the 'source' level using mediawiki transclusion, for
instance (to prevent them diverging unintentionally). And of course we
aren't necessarily tied to mediawiki for presenting the criteria, which
is another factor to bear in mind (I know one of tflink's Grand Plans
involves a different way of maintaining and presenting the release
criteria).
Thoughts on the best approach for each of these issues would certainly
be appreciated! I thought it'd be best to take some time to think them
over before moving ahead with drafts and so on.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 9 months
ARM delivery?
by Adam Williamson
So, I'm a bit surprised I didn't notice this before, but...our PRD
states:
"Fedora Server will produce two main installation resources, a
netinstall image and an offline install iso image that allows one to
install and configure featured roles offline."
However, this doesn't really cover how we do ARM installations, or at
least not how we've done them so far. We provide disk image files for
most ARM platforms; only one ARM platform so far (AIUI) supports use of
anaconda.
Is ARM a target arch for Server? If we say "no", well, is that okay?
What does it mean for ARM's "primary arch" status in Fedora? If we say
"yes", I guess we have to add ARM disk image media to our 'delivery
mechanisms'? Does someone want to talk to the ARM folks about this? Is
it going to be me? :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 9 months
Fedora 21 Server and log-flooding
by Reindl Harald
maybe someone of the server SIG could try to explain the
systemd-maintainers that calculation and that this is
unacceptable on real-world servers because it burries
any interesting information
the way systemd in Rawhide now logs make it unacceptable
on production servers and that said from someone running
Fedora on a lot of real-world servers for 6 years now
https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c8
if the "Stopping", "Stopped", "Removed", "Starting"
and "Reached" messages would only have a prefix to
filter them out with rsyslog, currently you can't
distinct them between system-wide messages
such flooing up to a self-DOS belongs in a debug level
________________________________________________
[root@rawhide ~]# rpm -q systemd
systemd-212-5.fc21.x86_64
[root@rawhide ~]# cat messages
May 27 12:44:25 rawhide systemd[1]: Stopping User Manager for UID 0...
May 27 12:44:25 rawhide systemd[531]: Stopping Default.
May 27 12:44:25 rawhide systemd[531]: Stopped target Default.
May 27 12:44:25 rawhide systemd[531]: Stopping Basic System.
May 27 12:44:25 rawhide systemd[531]: Stopped target Basic System.
May 27 12:44:25 rawhide systemd[531]: Stopping Paths.
May 27 12:44:25 rawhide systemd[531]: Stopped target Paths.
May 27 12:44:25 rawhide systemd[531]: Stopping Timers.
May 27 12:44:25 rawhide systemd[531]: Stopped target Timers.
May 27 12:44:25 rawhide systemd[531]: Stopping Sockets.
May 27 12:44:25 rawhide systemd[531]: Stopped target Sockets.
May 27 12:44:25 rawhide systemd[531]: Starting Shutdown.
May 27 12:44:25 rawhide systemd[531]: Reached target Shutdown.
May 27 12:44:25 rawhide systemd[531]: Starting Exit the Session...
May 27 12:44:25 rawhide systemd[531]: Received SIGRTMIN+24 from PID 687 (kill).
May 27 12:44:25 rawhide systemd[1]: Stopped User Manager for UID 0.
May 27 12:44:25 rawhide systemd[1]: Stopping user-0.slice.
May 27 12:44:25 rawhide systemd[1]: Removed slice user-0.slice.
May 27 13:01:01 rawhide systemd[1]: Starting user-0.slice.
May 27 13:01:01 rawhide systemd[1]: Created slice user-0.slice.
May 27 13:01:01 rawhide systemd[1]: Starting User Manager for UID 0...
May 27 13:01:01 rawhide systemd[697]: Starting Paths.
May 27 13:01:01 rawhide systemd[697]: Reached target Paths.
May 27 13:01:01 rawhide systemd[697]: Starting Timers.
May 27 13:01:01 rawhide systemd[697]: Reached target Timers.
May 27 13:01:01 rawhide systemd[697]: Starting Sockets.
May 27 13:01:01 rawhide systemd[697]: Reached target Sockets.
May 27 13:01:01 rawhide systemd[697]: Starting Basic System.
May 27 13:01:01 rawhide systemd[697]: Reached target Basic System.
May 27 13:01:01 rawhide systemd[697]: Starting Default.
May 27 13:01:01 rawhide systemd[697]: Reached target Default.
May 27 13:01:01 rawhide systemd[697]: Startup finished in 9ms.
May 27 13:01:01 rawhide systemd[1]: Started User Manager for UID 0.
May 27 13:01:01 rawhide systemd[1]: Stopping User Manager for UID 0...
May 27 13:01:01 rawhide systemd[697]: Stopping Default.
May 27 13:01:01 rawhide systemd[697]: Stopped target Default.
May 27 13:01:01 rawhide systemd[697]: Stopping Basic System.
May 27 13:01:01 rawhide systemd[697]: Stopped target Basic System.
May 27 13:01:01 rawhide systemd[697]: Stopping Paths.
May 27 13:01:01 rawhide systemd[697]: Stopped target Paths.
May 27 13:01:01 rawhide systemd[697]: Stopping Timers.
May 27 13:01:01 rawhide systemd[697]: Stopped target Timers.
May 27 13:01:01 rawhide systemd[697]: Stopping Sockets.
May 27 13:01:01 rawhide systemd[697]: Stopped target Sockets.
May 27 13:01:01 rawhide systemd[697]: Starting Shutdown.
May 27 13:01:01 rawhide systemd[697]: Reached target Shutdown.
May 27 13:01:01 rawhide systemd[697]: Starting Exit the Session...
May 27 13:01:01 rawhide systemd[697]: Received SIGRTMIN+24 from PID 726 (kill).
May 27 13:01:01 rawhide systemd[1]: Stopped User Manager for UID 0.
May 27 13:01:01 rawhide systemd[1]: Stopping user-0.slice.
May 27 13:01:01 rawhide systemd[1]: Removed slice user-0.slice.
May 27 14:01:01 rawhide systemd[1]: Starting user-0.slice.
May 27 14:01:01 rawhide systemd[1]: Created slice user-0.slice.
May 27 14:01:01 rawhide systemd[1]: Starting User Manager for UID 0...
May 27 14:01:01 rawhide systemd[740]: Starting Paths.
May 27 14:01:01 rawhide systemd[740]: Reached target Paths.
May 27 14:01:01 rawhide systemd[740]: Starting Timers.
May 27 14:01:01 rawhide systemd[740]: Reached target Timers.
May 27 14:01:01 rawhide systemd[740]: Starting Sockets.
May 27 14:01:01 rawhide systemd[740]: Reached target Sockets.
May 27 14:01:01 rawhide systemd[740]: Starting Basic System.
May 27 14:01:01 rawhide systemd[740]: Reached target Basic System.
May 27 14:01:01 rawhide systemd[740]: Starting Default.
May 27 14:01:01 rawhide systemd[740]: Reached target Default.
May 27 14:01:01 rawhide systemd[740]: Startup finished in 7ms.
May 27 14:01:01 rawhide systemd[1]: Started User Manager for UID 0.
May 27 14:01:01 rawhide systemd[1]: Stopping User Manager for UID 0...
May 27 14:01:01 rawhide systemd[740]: Stopping Default.
May 27 14:01:01 rawhide systemd[740]: Stopped target Default.
May 27 14:01:01 rawhide systemd[740]: Stopping Basic System.
May 27 14:01:01 rawhide systemd[740]: Stopped target Basic System.
May 27 14:01:01 rawhide systemd[740]: Stopping Paths.
May 27 14:01:01 rawhide systemd[740]: Stopped target Paths.
May 27 14:01:01 rawhide systemd[740]: Stopping Timers.
May 27 14:01:01 rawhide systemd[740]: Stopped target Timers.
May 27 14:01:01 rawhide systemd[740]: Stopping Sockets.
May 27 14:01:01 rawhide systemd[740]: Stopped target Sockets.
May 27 14:01:01 rawhide systemd[740]: Starting Shutdown.
May 27 14:01:01 rawhide systemd[740]: Starting Exit the Session...
May 27 14:01:01 rawhide systemd[740]: Received SIGRTMIN+24 from PID 769 (kill).
May 27 14:01:01 rawhide systemd[1]: Stopped User Manager for UID 0.
May 27 14:01:01 rawhide systemd[1]: Stopping user-0.slice.
May 27 14:01:01 rawhide systemd[1]: Removed slice user-0.slice.
May 27 14:13:59 rawhide systemd[1]: Starting user-0.slice.
May 27 14:13:59 rawhide systemd[1]: Created slice user-0.slice.
May 27 14:13:59 rawhide systemd[1]: Starting User Manager for UID 0...
May 27 14:13:59 rawhide systemd[798]: Starting Paths.
May 27 14:13:59 rawhide systemd[798]: Reached target Paths.
May 27 14:13:59 rawhide systemd[798]: Starting Timers.
May 27 14:13:59 rawhide systemd[798]: Reached target Timers.
May 27 14:13:59 rawhide systemd[798]: Starting Sockets.
May 27 14:13:59 rawhide systemd[798]: Reached target Sockets.
May 27 14:13:59 rawhide systemd[798]: Starting Basic System.
May 27 14:13:59 rawhide systemd[798]: Reached target Basic System.
May 27 14:13:59 rawhide systemd[798]: Starting Default.
May 27 14:13:59 rawhide systemd[798]: Reached target Default.
May 27 14:13:59 rawhide systemd[798]: Startup finished in 8ms.
May 27 14:13:59 rawhide systemd[1]: Started User Manager for UID 0.
8 years, 10 months
Fedora Server Roles and CentOS Simple Linux Server
by Stephen Gallagher
The following is a new meeting request:
Subject: Fedora Server Roles and CentOS Simple Linux Server
Organizer: "Stephen Gallagher" <sgallagh(a)redhat.com>
Location: #fedora-server on Freenode
Time: Friday, May 30, 2014, 10:00:00 AM - 12:00:00 PM GMT -05:00 US/Canada Eastern
Required: twoerner(a)redhat.com; filippo.carletti(a)nethesis.it
Optional: server(a)lists.fedoraproject.org
*~*~*~*~*~*~*~*~*~*
Discussion of the proposed Server Role API and its suitability for the CentOS SLS SIG.
I've booked two hours, hopefully we won't need the full time.
Sorry for the wide-distribution (to the mailing list), but I want to make sure that anyone who is interested in participating knows about it.
8 years, 10 months
Fedora Server Roles and CentOS Simple Linux Server
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm organizing this event : Fedora Server Roles and CentOS Simple
Linux Server
I'd like to find out your availability. This link will show you my
proposed times. All you need to do is click on when is good for you ...
http://whenisgood.net/97cw5d7
The plan is to discuss the design of the Fedora Server Role API with
the CentOS SLS folks so we can make sure to accommodate their needs.
Thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEUEARECAAYFAlOEsY8ACgkQeiVVYja6o6MD5wCY1tXm+Li4gLitEaGbGlhKY94A
DgCbBbK+UGZ7x8yBo/nqPLaYjneVndg=
=vkau
-----END PGP SIGNATURE-----
8 years, 10 months
Draft Fedora 21 Test Plan
by Adam Williamson
Hi, folks! So, I quickly bashed out that draft F21 Test Plan I've been
threatening to write for the last month or so.
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_21_test_plan
So, what's the idea here?
Really, I'm just trying to come up with a starting point for all the
decisions we need to make and planning we need to do for Fedora 21
testing, especially release validation testing, especially as regards
Fedora.next. There's some mention of other stuff in there, but what I'm
really trying to think about is what we need to do to extend our test
processes to cover all the stuff that's coming as a part of .next.
I think the most interesting points are these:
* There are several practical implications from the test plan - just
Work We Need To Do. Most obviously, we need to draw up release criteria
and supporting test cases for the Fedora.next Products. We also will
need to adjust the
https://fedoraproject.org/wiki/QA/SOP_Release_Validation_Test_Event SOP
to include those cases/matrices as they're created, and adjust the
https://fedoraproject.org/wiki/Release_criteria page to refer to/include
the Product-specific release criteria as *they're* created.
* Responsibilities! Particularly, in this *draft* Test Plan, I've
suggested that creating the Product-specific criteria and test cases
should be the responsibility of the relevant Working Groups, with
assistance from the QA team. They would also be jointly responsible,
along with the QA team, for conducting Product-specific testing, on the
general principle that the more Product-specific a bit of testing is
(and the more domain-specific expertise it needs), the more it's the
WG's responsibility and the less it's QA's responsibility. Note that
(again, as a suggestion in this draft) the QA team is still responsible
for Fedora 21 testing *overall* - i.e. it's the QA team's responsibility
to make sure the WGs do the stuff assigned to them in the plan. If that
makes sense. Discussion welcome!
* Feasibility. This is, of course, one I really want to nail down. It
will require, though, that the Product-specific release criteria and
test cases / matrices get written. Once we have those, we can try and
make a realistic judgement as to whether we as a project - the QA team
and the WGs - actually have the resources to complete the minimal
necessary level of testing within the scope of the F21 schedule. If we
don't think that's going to be the case, we can take that to FESCo, and
we can decide what to do about it that way. In the meantime I've
provided a *very* vague 'Required resources' section just to sort of
flag this up in a modest way.
I'd really, really appreciate feedback on this draft from all interested
parties - QA folks, WG folks, FESCo, anyone at all reading this who has
an opinion. Please, bikeshed away. It all helps.
I'll aim to kick off discussion between the WGs and QA about creating
Product-specific release criteria and test cases next week. Obviously
that's *somewhat* subject to feedback on this very draft, but I can't
really envisage a world in which we aren't going to need those two
things to happen, and whoever's job we ultimately decide it is, I don't
*think* that me just kicking off an attempt to draft them can be a bad
thing.
Thanks folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 10 months
Server WG Meeting Minutes (2014-05-27)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-05-27)
===================================================================
Meeting started by sgallagh at 14:59:29 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-05-27/fedora-meeti...
.
Meeting summary
- ---------------
* roll call (sgallagh, 14:59:32)
* Introductions (sgallagh, 15:03:46)
* Agenda (sgallagh, 15:06:47)
* Agenda Topic: CentOS Simple Linux Server SIG (sgallagh, 15:06:50)
* Agenda Topic: Release Engineering (sgallagh, 15:06:53)
* Agenda Topic: Branding and Logos (sgallagh, 15:06:57)
* CentOS Simple Linux Server SIG (sgallagh, 15:07:14)
* LINK: http://wiki.centos.org/SpecialInterestGroup/SLS (sgallagh,
15:07:34)
* LINK: https://fedoraproject.org/wiki/Server/Personas (sgallagh,
15:18:52)
* Release Engineering (sgallagh, 15:41:19)
* Open Floor (sgallagh, 15:57:51)
* Release Engineering (redux) (sgallagh, 16:04:40)
Meeting ended at 16:22:43 UTC.
Action Items
- ------------
Action Items, by person
- -----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (71)
* adamw (32)
* filippoc (25)
* nirik (24)
* gsanchietti (17)
* tdk2fe (15)
* twoerner (9)
* mitr (8)
* tuanta (7)
* danofsatx-work (5)
* zodbot (5)
* davidep (3)
* pcbaldwin (3)
* alefattorini (3)
* davidstrauss (2)
* dgilmore (2)
* simo (1)
* stefw (0)
* mizmo (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/
iEYEARECAAYFAlOExlIACgkQeiVVYja6o6OrKQCfdenNbg10UhY6je2VEECFX9Rj
+nYAn1ysMiOZiI7xqVJOGifqNp8ZpCpA
=x3Ic
-----END PGP SIGNATURE-----
8 years, 10 months
Agenda for Server WG Meeting (2014-05-27)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
#startmeeting Server Working Group Weekly Meeting (2014-05-27)
#topic roll call
#chair sgallagh mizmo nirik davidstrauss stefw adamw simo tuanta mitr
#topic Agenda
#info Agenda Topic: Branding and Logos
#info Agenda Topic: CentOS Simple Linux Server SIG
#info Agenda Topic: Release Engineering
#topic Branding and Logos
#topic CentOS Simple Linux Server SIG
#topic Release Engineering
#topic Open Floor
#endmeeting
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOEnOYACgkQeiVVYja6o6PakwCglohGv+gWEeREJa1FYrYu8nIX
+soAn3ilGYQe3waYdJngrWuHhYsOxErY
=bTFz
-----END PGP SIGNATURE-----
8 years, 10 months