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@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