Thomas Woerner <twoerner(a)redhat.com> writes:
Some question that I had on first reading. Hopefully they can help to
improve the API, although most of them are obvious and you probably have
thought of them already.
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
What is the input object? On first glance, this looks like the identity
function, no? :)
getNamedRole(name:s)→o # get role by name
getActiveRoles()→ao # get active role object list
What is "active", exactly? Is it the same as state == "started"?
org.fedoraproject.ServerRoleManager1.roles.$n
What is the $n here? Is it the version of the interface? (If we
specify a concrete API, we just need one name. Role specific APIs
should be separate interfaces on the same object.)
---------------------------------------------
Properties (general) # role settings
name:s (ro) # role name
version:s (ro) # role version
state:s (ro) # deployed/started/inactive/dead?
What is the state before the role is deployed?
Changing state is not instantanous. Can I see when a role is currently
being deployed (and how long that is still estimated to take)?
I guess a role can also be in a "failed" state, where it is supposed to
be active/started but something has gone wrong.
activate_time:i (ro) # time of activation
deploy_time:i (ro) # time of deployment
is_configured:b (ro) # is this role configured?
What does "configured" mean? It's not the same as "active" or
"started", right? Can I start a unconfigured role? Could this be a
state?
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
It might not a good idea to put sensitive data like passwords into
properties. The common practise seems to be to have a separate method
to return the secrets. This is probably done to make implementing
access control easier, but I am not sure.
Methods
deploy() # deploy role (i.e. running initial setup
post-package-install, ipa-server-install)
How can I cancel?
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
How can I see whether an update for the role is available?
reconfigureRole(a{sv}) # reconfgure role with new config
settings
as key value pairs
A role could specific which program to run to do a interactive
configuration. For terminal, for a graphical session, and for Cockpit
(by specifying a module that Cockpit will load).
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
Is there anything more to these than convenience? E.g., can I just take
the 'packages' properties and use it with the package management API of
my choice? If we already have a good UI for the package management API,
with highly polished progress reporting and error handling, say, it is
probably better to just use it instead of trying to polish this API to
the same level.
Thanks!