-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/30/2014 07:52 AM, Thomas Woerner wrote:
On 06/27/2014 05:29 PM, Stephen Gallagher wrote: On 06/26/2014
03:12 PM, Miloslav Trmač wrote:
>>> Hello, 2014-06-20 21:10 GMT+02:00 Thomas Woerner
>>> <twoerner(a)redhat.com <mailto:twoerner@redhat.com>>:
>>>
>>> org.fedoraproject.rolekit1.roles.$name
>>> -------------------------------------- services:as (ro)
>>> # service list: services to be enabled and started
>>>
>>> Where “service” means “systemd unit”?
>>>
>>>
>>> firewall:a{sas} (ro) # firewall settings: ports and
>>> services dict { "ports" => array (
>>> portid:s["-"portid:s]"/"__protocol:s ),
"services" => array(
>>> name:s ), } ports are similar to firewalld port definitions
>>> firewall_zones:as (rw) # firewall zones to apply the
>>> firewall settings to custom_firewall:b (rw) # custom
>>> firewall: firewall settings will not be applied if set to
>>> true errorlog:s (ro) # errorlog string
>>>
>>> A single string? Is there some kind of formatting involved?
>>> Is this supposed to be a facade over/replacement for
>>> querying journald, or would the callers be expected to get
>>> the list of systemd units and query journal themselves?
> The errorlog is only meant to provide (some) information about
> the last error that occured.
> Maybe a rename to lasterror would be good than to make it more
> clear, what it is.
This should be a starting point, yes. (Something for a UI to
report easily). Callers wanting more information should be calling
journald directly (eventually using the theoretical messageid or
service descendent tracking mechanism I just brought up in the
"Proposal: Implementation of Server Roles" thread.
>>>
>>> deploy() # deploy role (i.e. running initial
>>> setup post-package-install, ipa-server-install)
>>>
>>> How does rolekit get the configuration necessary to deploy a
>>> role?
Ah, looks like Thomas forgot to include the dbus codes here. All
of the methods will take arguments. CCing Thomas to get that
corrected so we can discuss this meaningfully.
> The configuration should go into the "role specific settings".
> For which the role can add additional methods into the API.
> There have not been arguments in the proposal before.
Thomas and I discussed this on IRC today. He'll be sending revisions
shortly.
>>>
>>>
>>> updateRole() # update role: yum update;
>>> restartServices; updateFirewall
>>>
>>> How does the caller know that an update is available?
Good question. We should probably have a signal and an attribute
for this.
> Ok, yes.. the only question is: where is rolekit getting this
> information from? Is it actively polling for this information?
> How does this work with the daemon, that is only started, when
> needed? In this case it either has to stay alive all the time or
> wake up every few seconds/minutes/hours automatically or it can
> not provide a signal for this.
Let's defer the signal for now. Let's leave this as a
manually-initiated operation at the moment. It's certainly
nice-to-have functionality, but I think it can wait for F22, since
we're getting down to the wire at this point.
>>>
>>>
>>> getFirewallZones() # get firewall zone list from
>>> firewalld, add used ones to firewall_zones
>>>
>>> How does this differ from just reading firewall_zones?
This one I'm going to defer to Thomas.
> I have added this method because Stephen asked about it.. I would
> just propose to use the mathing method in the firewalld D-Bus API
> to get this information. Stephen, maybe I got you wrong on this
> one?
I've completely paged out why we added this. If it's easy enough to
just get it from the firewalld D-BUS API, then I see no reason to
reimplement it here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlOxYBgACgkQeiVVYja6o6MPYQCfUqTrhjK1sIOy473YEnwsf6sf
amEAnRaP1hySpk3Zrjo1ksLNmdVJwnWI
=HRpS
-----END PGP SIGNATURE-----