Proposal for the Server Role API

[Thomas Woerner]

On 06/02/2014 08:51 AM, Marius Vollmer wrote:
> Thomas Woerner <twoerner at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/server
>
Thomas