-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/03/2014 07:39 AM, Miloslav Trmač wrote:
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
<mailto:twoerner@redhat.com>>:
org.fedoraproject.ServerRoleManager1
------------------------------__------
version:s # server role manager version
This is a string, how does the application compare them?
Good point; we probably only need this to be an integer.
state:s # active/inactive/dead?
How could the D-Bus service return anything but “active”?
Hmm, good question. That may indeed be superfluous.
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?
"active" includes installed-but-not-configured roles.
(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.)
Yeah, we probably need getAvailableRoles()
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?
See above.
Version /of what/? Of a role-specific API, of the implementation of
the role, of the underlying upstream project, of the persistent
data format?
The implementation of the role, which includes the role-specific API
and persistent data format. The underlying upstream project(s) should
explicitly NOT be referenced here. (And in fact, they could even
change in the future).
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.
See the other branch of this thread for discussion of states.
activate_time:i (ro) # time of activation
Why is this necessary?
Informative, not necessary.
deploy_time:i (ro) # time of deployment
Why is this necessary?
Informative, not 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.
This is something we want clients to be able to get, in case they want
to manage packages themselves (e.g. Cockpit).
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.
Yes, Cockpit will need this for display purposes.
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?)
"53/udp" and similarly useful for Cockpit display/monitoring.
#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?
Yeah, good point. We can base it on type rather than trailing slash.
(I thought about that after we had the discussion as well, but didn't
follow up).
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?
No interactivity. You give it all the necessary data, then watch the
Job for completion.
decommission() # decommision (example: moved to another
machine, ipa-server-install -u ), stop if started
What does this do to configuration and data?
<handwave>Role-specific</handwave>
I'd suggest that we might want to copy any data referenced by
'backup_paths' (when implemented) to a recovery directory, just in case.
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)?
I'd say make that an input value, default to persistent.
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?
Given the nature of open-source projects, the only safe assumption is
that *every* updateRole includes a non-reversible data migration. Thus
the client tools should just always warn of this. I realize this isn't
a good answer.
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?
They are exposed as the * properties of the role object.
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.
Doesn't need to know what?
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.
Same question.
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?)
Thomas?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlONt78ACgkQeiVVYja6o6OtogCgitrIedysf0ZtftQeHaZzjZ4o
ZpIAoJeThgYJq1Yivypu5muZczxdyh7A
=HlPw
-----END PGP SIGNATURE-----