Hello,
First of all, this is more comprehensive that I imagined the first version
to be. So me having many questions is just because we haven’t been (at
least that I’ve seen) been exploring all of these areas.
2014-05-30 17:35 GMT+02:00 Thomas Woerner <twoerner(a)redhat.com>:
org.fedoraproject.ServerRoleManager1
------------------------------------
version:s # server role manager version
This is a string, how does the application compare them?
> state:s # active/inactive/dead?
How could the D-Bus service return anything but “active”?
> getActiveRoles()→ao # get active role object list
Why does this only allowing to list “active” roles? How does
one list
installed but not set up roles, and known but not installed roles? Or is
the idea that nobody would need these lists because any UI allowing to
install a role would know that role by name?
(getAllKnownRoles() + iterating over all roles would AFAICS be the most
general API, but we can always add more functions and having getActiveRoles
available doesn’t hurt at all, so perhaps we can just defer this.)
org.fedoraproject.ServerRoleManager1.roles.$n
> ---------------------------------------------
> name:s (ro) # role name
> version:s (ro) # role version
This is a string, how does the application compare them?
Version *of what*? Of a role-specific API, of the implementation of the
role, of the underlying upstream project, of the persistent data format?
state:s (ro) # deployed/started/inactive/dead?
Why is there “inactive“ but not “active”? I guess this would
all be helped
with a state diagram.
activate_time:i (ro) # time of activation
Why is this necessary?
> deploy_time:i (ro) # time of deployment
Why is this necessary?
> is_configured:b (ro) # is this role configured?
Again, missing the state diagram.
> packages:as (ro) # packages and @groups
The caller managing the server doesn‘t need to know that; this
is an
implementation detail of the role.
services:a{sas} (ro) # services to be enabled and/or started:
> "enable": [s] and "start": [s]
It seems to me that the caller managing the server doesn‘t need
to know
that; this is an implementation detail of the role, but I could be
persuaded that cockpit needs this for actionable status display.
firewall:a{sas} (ro) # firewall dict ports: [s] and service: [s]
How is a port described with a single unstructured string?
(And like
services, perhaps the caller doesn’t need to know?)
#backup_paths:as # backup files and directories (directory
> trailing slash it means "everything below here")
The trailing slash semantics seems superfluous; if the path
named a
directory without adding a slash, what would the backup program be expected
to do?
> deploy() # deploy role (i.e. running initial setup
> post-package-install, ipa-server-install)
How is interactivity, non-interactive kickstart-like
deployment, error
handling done?
decommission() # decommision (example: moved to another
> machine, ipa-server-install -u ), stop if started
What does this do to configuration and data?
start() # start the role (startServices,
> installFirewall), fails if not deployed
> stop() # stop the role (stopServices,
> uninstallFirewall), fails if not started
Does this have persistent effect (survive reboot)?
updateRole() # update role: yum update; restartServices;
> updateFirewall
If the update requires more information from the user (even if
just to
confirm a non-reversible data migration), how is interactivity and
non-interactive kickstart-like deployment done?
> reconfigureRole(a{sv}) # reconfgure role with new config settings as
> key value pairs
How do I get the full set of current settings to submit to this
call?
installPackages() # install packages and groups
> #uninstallPackages() # uninstall packages and groups, fails if
> deployed - not initially
The caller managing the server doesn‘t need to know that; this
is an
implementation detail of the role.
startServices() # start the services
> restartServices() # restart the services
> stopServices() # stop the services
The caller managing the server doesn‘t need to know that; this
is an
implementation detail of the role.
installFirewall() # install firewall ports/services
> updateFirewall() # update firewall ports/services
> uninstallFirewall() # uninstall firewall ports/services
The caller managing the server doesn‘t need to know that; this
is an
implementation detail of the role. (And what does “update” do and when
would I use it?)
Mirek