Fedora Server Role D-BUS API Design Discussion
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
During this week's Fedora Server Working Group meeting[1], we started
planning out how we want the public D-BUS API to look. I volunteered
to take the discussion to the list so we could start hashing it out
with a wider audience. I'm CC-ing the cockpit-devel list since a lot
of this will affect that project, but I'd prefer to keep replies on
server(a)lists.fedoraproject.org please (easier to track on one list).
Some pre-conditions/goals (many of these are reminders from earlier
discussions):
1) We want to be able to support two initial clients of this API: the
Cockpit management console and a local command-line tool (I've been
tentatively calling it 'fedora-role-manage') A third, future option
will be to also support remote access to this API via the OpenLMI
Project.
2) We do not need to have a single generic API that will work for any
conceivable Role. We've identified in the past that the selection of
Featured roles will (for the conceivable future) remain a small,
manageable list. For this reason, it is acceptable for the
deployment and post-deployment configuration APIs to be entirely
different between two roles. However, some functionality such as
the backup and firewall queries should be stable between all roles.
3) The supported clients should be able to determine if a target system
supports the deployment of a particular role (for backwards-
compatibility and architecture differences), but the Role API should
*NOT* be attempting to dictate the UI experience. UIs should merely
check whether the role is available and then use a previously-
developed experience. We don't want to be reimplementing PAM or
debconf here.
4) The D-BUS API must be stable. If it is likely that the set of input
required to deploy or configure will change, this should be planned
for in the design.
5) As it is not possible to plan for all contingencies, the API must be
versioned such that the clients can determine whether they can
properly perform the requested actions.
Some initial thoughts on the matter (all are open to discussion):
Standard Objects:
/org/fedoraproject/server/ServerRoleManager:
* properties:
* all_roles: list of object references to Roles that can be
installed and deployed
* staging_roles: list of object references to Roles that have been
pre-loaded but not yet configured
* active_roles: list of object references to deployed Roles
* version: API version
* methods:
# These properties and methods should be available and identical on
# all Roles
/org/fedoraproject/server/role/$ROLE:
* properties:
* version: API version
* loaded: Bool: whether the packages are installed
* deployed: Bool: whether the Role has been deployed
* methods:
* PreloadRole: Install all necessary software packages for
default operation
* GetFirewallPorts: list of port/protocol pairs that the Role needs
open in the firewall
* PrepBackup: method to invoke any necessary pre-backup steps
(such as running a database dump to a file)
* GetBackupFiles: list of filesystem path objects that identifies
all data that should be copied by backup software
# Individual Roles should have unique implementations of installation
# and deployment
e.g. /org/fedoraproject/server/role/DomainController
* methods:
* DeployPrimaryDomainController: Set up the first domain controller in
the domain.
* DeployReplicaDomainController: Add a new replica domain controller
to the domain
* AddCertificateAuthority: Add a certificate authority to this
domain controller
* EnableDisableDNS: Enable or disable the DNS server on
this server
== Open questions ==
1) How do we handle configuring the Firewall? I think we want to have
a Firewall object (/org/fedoraproject/server/RoleFirewallManager)
available to query the firewall as a whole, but we may also want to be
able to view and apply firewall rules from the Role objects directly.
(Note: I'm not suggesting we need a complete firewall solution here.
This should be a wrapper that deals only with the Roles). Firewalld
already provides a more comprehensive firewall interface for the
general case.
I'm sure there are other questions we'll discover out there, but this
email is already running long for an "introduction" to the topic.
[1]
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-18/fedora-meeti...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMpn+gACgkQeiVVYja6o6Ou5wCeJw5zELa1zwLj++EBf66PKMKh
z6EAn1MOkhPQhY4bj9afTy1of68/QhXR
=xz9N
-----END PGP SIGNATURE-----
10 years, 1 month
Fedora Server WG Meeting Minutes (2014-03-25)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-03-25)
===================================================================
Meeting started by sgallagh at 15:00:50 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-25/fedora-meeti...
.
Meeting summary
- ---------------
* roll call (sgallagh, 15:00:55)
* sgallagh is present (sgallagh, 15:01:02)
* nirik is present (sgallagh, 15:01:08)
* jreznik is present (sgallagh, 15:01:13)
* mizmo is present (sgallagh, 15:02:04)
* tuanta is present (sgallagh, 15:02:07)
* adamw is present (sgallagh, 15:02:42)
* simo is present (sgallagh, 15:06:13)
* zoglesby is present to represent Documentation (sgallagh, 15:06:29)
* agenda (sgallagh, 15:06:44)
* Agenda Topic: tcpwrappers (sgallagh, 15:06:47)
* Agenda Topic: Documentation Needs (sgallagh, 15:06:50)
* Agenda Topic: Change Proposal Filing (sgallagh, 15:06:53)
* tcpwrappers (sgallagh, 15:08:07)
* davidstrauss is present (sgallagh, 15:10:08)
* AGREED: Fedora Server won't include tcpwrappers as a mandatory
component unless Base Design elects to do so. If someone is
maintaining it for Fedora, let them keep doing so. (+7, 0, -0)
(sgallagh, 15:15:34)
* Documentation Needs (sgallagh, 15:16:03)
* The Documentation team (represented today by zoglesby) would like us
to let them know what Server-specific tasks we will have for them
(sgallagh, 15:16:37)
* General consensus (no formal vote) is that there should be a primary
Fedora Server document that can refer to other documentation common
to other Products or non-Product Fedora. (sgallagh, 15:27:39)
* Change Proposal Filing (sgallagh, 15:29:04)
* Change Proposal: Framework for Server Role Deployment (sgallagh,
15:32:55)
* Change Proposal: Featured Server Role: Domain Controller (sgallagh,
15:33:03)
* Change Proposal: Featured Server Role: SQL Database Server
(sgallagh, 15:33:26)
* Change Proposal: Cockpit Server Management Console (sgallagh,
15:33:38)
* Change Proposal: OpenLMI Support for Server Roles (sgallagh,
15:34:17)
* ACTION: sgallagh and simo to file the Domain Controller change
(sgallagh, 15:47:47)
* ACTION: nirik and tuanta to file the SQL Database Server Change
(sgallagh, 15:48:44)
* ACTION: adamw to file the "Framework for Server Role Deployment"
Change Proposal. (sgallagh, 15:51:54)
* ACTION: sgallagh to ask mitr to assist adamw (sgallagh, 15:52:12)
* ACTION: sgallagh to coordinate with Cockpit and OpenLMI upstreams to
file their Change proposals. (sgallagh, 15:53:18)
* ACTION: davidstrauss to provide final editing review for Cockpit,
OpenLMI and DB Server Changes. (sgallagh, 15:54:41)
* jreznik is available to assist with filing proposals (sgallagh,
15:54:56)
* Change Submissions must be complete two weeks from today (sgallagh,
15:58:36)
* Open Floor (sgallagh, 15:58:41)
Meeting ended at 16:00:30 UTC.
Action Items
- ------------
* sgallagh and simo to file the Domain Controller change
* nirik and tuanta to file the SQL Database Server Change
* adamw to file the "Framework for Server Role Deployment" Change
Proposal.
* sgallagh to ask mitr to assist adamw
* sgallagh to coordinate with Cockpit and OpenLMI upstreams to file
their Change proposals.
* davidstrauss to provide final editing review for Cockpit, OpenLMI and
DB Server Changes.
Action Items, by person
- -----------------------
* adamw
* adamw to file the "Framework for Server Role Deployment" Change
Proposal.
* sgallagh to ask mitr to assist adamw
* davidstrauss
* davidstrauss to provide final editing review for Cockpit, OpenLMI
and DB Server Changes.
* mitr
* sgallagh to ask mitr to assist adamw
* nirik
* nirik and tuanta to file the SQL Database Server Change
* sgallagh
* sgallagh and simo to file the Domain Controller change
* sgallagh to ask mitr to assist adamw
* sgallagh to coordinate with Cockpit and OpenLMI upstreams to file
their Change proposals.
* simo
* sgallagh and simo to file the Domain Controller change
* tuanta
* nirik and tuanta to file the SQL Database Server Change
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (132)
* nirik (25)
* simo (21)
* tuanta (18)
* jreznik (18)
* adamw (14)
* zoglesby (9)
* davidstrauss (9)
* mizmo (8)
* zodbot (7)
* jsmith (2)
* Evolution (0)
* 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/
iEYEARECAAYFAlMxqLIACgkQeiVVYja6o6OeRACeNAoBloy/sh2MSFSS5QAeaFsw
trAAn0KPHOF5Jo5q/+E9aYXuVnJTKpzA
=JjqO
-----END PGP SIGNATURE-----
10 years, 1 month
Fine grained deadlines for roles implementations ?
by Simo Sorce
At the end of the meeting it occurred to me we have Fedora Deadlines to
live by but we haven't created any internal Fedora Server Product
deadlines to match progress on blocker issues.
I think we should discuss this topic on the next meeting so we can set
our priorities straight in he next weeks.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10 years, 1 month
Agenda for Fedora Server WG Meeting (2014-03-25)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Agenda Topics:
* tcpwrappers (Does Fedora Server want to support them?)
I was hoping we could also hear from QA and rel-eng tomorrow, but I
haven't heard confirmation one way or another whether they will have
anything to say.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMwmD8ACgkQeiVVYja6o6N5cwCdEF1Ac2tGkOJhZSF2Jq82r+9z
xGQAn0h/+TbpVrKLSyZNRpY4K7P6lnfI
=q0I3
-----END PGP SIGNATURE-----
10 years, 1 month
RE: Fedora Server Role D-BUS API Design Discussion
by Jan Safranek
I'm injecting the old "Fedora Server Role D-BUS API Design Discussion"
thread as I was not subscribed at that time... I looked at the API and I
have few remarks:
First, don't use under_scores, DBus prefers CamelCase.
> /org/fedoraproject/server/ServerRoleManager:
> * properties:
> * all_roles: list of object references to Roles that can be
> installed and deployed
> * staging_roles: list of object references to Roles that have been
> pre-loaded but not yet configured
> * active_roles: list of object references to deployed Roles
> * version: API version
> * methods:
It would be nice if there was e.g. /org/fedoraproject/server/ServerRole
object with org.freedesktop.DBus.ObjectManager interface, which would
list all objects provided by the service. That's how DBus works usually.
It may make 'all_roles', 'staging_roles' and 'active_roles' properties
of ServerRoleManager irrelevant, as an application can easily list all
object + filter out those with appropriate properties.
> /org/fedoraproject/server/role/$ROLE:
> * properties:
> * version: API version
> * loaded: Bool: whether the packages are installed
> * deployed: Bool: whether the Role has been deployed
> * methods:
> * PreloadRole: Install all necessary software packages for
> default operation
> * GetFirewallPorts: list of port/protocol pairs that the Role needs
> open in the firewall
> * PrepBackup: method to invoke any necessary pre-backup steps
> (such as running a database dump to a file)
> * GetBackupFiles: list of filesystem path objects that identifies
> all data that should be copied by backup software
>
> # Individual Roles should have unique implementations of installation
> # and deployment
>
> e.g. /org/fedoraproject/server/role/DomainController
> * methods:
> * DeployPrimaryDomainController: Set up the first domain controller in
> the domain.
> * DeployReplicaDomainController: Add a new replica domain controller
> to the domain
> * AddCertificateAuthority: Add a certificate authority to this
> domain controller
> * EnableDisableDNS: Enable or disable the DNS server on
> this server
I am not sure if DBus supports inheritance. I have seen only single
object implementing multiple interfaces, i.e.
/org/fedoraproject/Server/Role/DomainController would implement both,
org.fedoraproject.Server.Role.Generic [or so] and
org.fedoraproject.Server.Role.DomainController, each with distinct
properties and methods.
And most importantly, there must be some sort of job management. I guess
installing role packages and deploying a role are long running
operations in general. In this case, the DeployPrimaryDomainController()
method should return a reference to a new object with Job interface, which:
- can be watched for progress [i.e. Cockpit draws a nice progress bar]
- reports any error messages [Cockpit shows an error alert]
- with possibility to cancel the job if such functionality is needed and
feasible.
There may be more than one running jobs, started by [in theory]
different Cockpit users, so all needs to be robust enough e.g. to queue
jobs and execute them serially.
As consequence, simple boolean for Role.Generic.loaded and .deployed may
not be enough, some 'in progress' would be nice.
I am afraid it's not _that_ simple DBus service as initially planned.
It's not particularly difficult either, it just needs a good design. And
the API should be reviewed by someone who really understands DBus and
knows its design patterns, so it fits well there. I am certainly not an
expert here, I just have played a bit with few services like UDisks and
storaged and I can spot only the most obvious issues.
Jan
10 years, 1 month
Call for Agenda for Server WG Meeting (2014-03-25)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Now accepting suggestions for the Server WG meeting on Tuesday. Right
now, I think most of my efforts (when I can spare them) are focused on
the D-BUS API. I'm not sure there's much value discussing that on a
meeting until they're in a more complete shape, so I'm not
recommending that for the agenda.
Anyone have other topics they'd really like to bring up? We haven't
had an opportunity to really talk rel-eng and QA needs yet. Maybe
those groups would like some space to talk?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMsSMMACgkQeiVVYja6o6Nc5ACfZf13jKmeuzMugpOFaM6+NPMd
6KcAn00LuTvm197q5eg06jEFwoIb8n8W
=EhWG
-----END PGP SIGNATURE-----
10 years, 1 month
Fedora Server WG Meeting Minutes (2014-03-18)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
===================================================================
#fedora-meeting-1: Server Working Group Weekly Meeting (2014-03-18)
===================================================================
Meeting started by sgallagh at 14:59:04 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-18/fedora-meeti...
.
Meeting summary
- ---------------
* roll call (sgallagh, 14:59:11)
* Server Role PoC (sgallagh, 15:02:44)
* mitr notes that firewalld 'services' are configurable using local
files (sgallagh, 15:14:17)
* ACTION: sgallagh to summarize API design discussion and start
discussion on the server list (sgallagh, 16:04:49)
* Open Floor (sgallagh, 16:04:59)
Meeting ended at 16:08:18 UTC.
Action Items
- ------------
* sgallagh to summarize API design discussion and start discussion on
the server list
Action Items, by person
- -----------------------
* sgallagh
* sgallagh to summarize API design discussion and start discussion on
the server list
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (109)
* simo (94)
* mitr (40)
* adamw (18)
* nirik (9)
* zodbot (8)
* tuanta (4)
* mizmo-out (1)
* jzb (1)
* Evolution (0)
* davidstrauss (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/
iEYEARECAAYFAlMob9EACgkQeiVVYja6o6OQBwCbBJcqymJWtaIpJJoz5VPWpLbV
AZoAoIo0EmJcGD4nL3ljlAN5D2v8d4WM
=eHj1
-----END PGP SIGNATURE-----
10 years, 1 month
