On 06/02/2014 08:51 AM, Marius Vollmer wrote:
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? :)
This one is not needed. I am removing it.
> 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"?
Yes, active was meant for started state.
We might extend this to getRoleByState(state:s)→ao. What do you think?
> 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.)
$n is a number, because D-Bus only supports a limited character set here.
> ---------------------------------------------
>
> 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.
The full set of states need to be defined still.
> 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?
The user has added configuration options. This was mentioned after the
proposal from Stephen.
Please define all properties, that might be useful.
> 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.
Stephen, do you have a solution for this?
> Methods
>
> deploy() # deploy role (i.e. running initial setup
> post-package-install, ipa-server-install)
How can I cancel?
Cancel while deploying? It was not planned for this now. Otherwise see
decommission.
> 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?
The updateFirewall call will for example be used if there is an role
update. There is no mechanism to detect updates for now. Please define it.
> 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).
As far as I know interactive configuration is not a goal for now.
> 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.
I do not know. Stephen?
Thanks!
_______________________________________________
server mailing list
server(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/server
Thomas