rolekit D-Bus API =================
org.fedoraproject.rolekit1 --------------------------
Properties
version:i # server role manager version roles:ao # role objects list
Methods
getNamedRole(name:s)→o # get role by name getRolesByState(state:i)→ao # get all roles with the given state
org.fedoraproject.rolekit1.roles.$name --------------------------------------
Properties (general) # role settings
name:s (ro) # role name version:i (ro) # role implementation version state:i (ro) # deployed/started/inactive/dead? packages:as (ro) # package list: packages and @groups (similar to kickstart) services:as (ro) # service list: services to be enabled and started firewall:a{sas} (ro) # firewall settings: ports and services dict { "ports" => array ( portid:s["-"portid:s]"/"protocol:s ), "services" => array( name:s ), } ports are similar to firewalld port definitions firewall_zones:as (rw) # firewall zones to apply the firewall settings to custom_firewall:b (rw) # custom firewall: firewall settings will not be applied if set to true errorlog:s (ro) # errorlog string
#backup_paths:as (ro) # backup paths (files and directories) # ... # role specific settings
Methods
start() # start the role (startServices, installFirewall), fails if not deployed stop() # stop the role (stopServices, uninstallFirewall), fails if not started restart() # stop and start deploy() # deploy role (i.e. running initial setup post-package-install, ipa-server-install) decommission() # decommision (example: moved to another machine, ipa-server-install -u ), stop if started
updateRole() # update role: yum update; restartServices; updateFirewall
getFirewallZones() # get firewall zone list from firewalld, add used ones to firewall_zones
Role States ===========
Nascent 0 Deploying 1 ReadyToStart 2 Starting 3 Running 4 Stopping 5 Decomissioning 6 Error 255
Hello, 2014-06-20 21:10 GMT+02:00 Thomas Woerner twoerner@redhat.com:
org.fedoraproject.rolekit1.roles.$name
services:as (ro) # service list: services to be enabled and started
Where “service” means “systemd unit”?
firewall:a{sas} (ro) # firewall settings: ports and services dict { "ports" => array ( portid:s["-"portid:s]"/"protocol:s ), "services" => array( name:s ), } ports are similar to firewalld port definitions firewall_zones:as (rw) # firewall zones to apply the firewall settings to custom_firewall:b (rw) # custom firewall: firewall settings will not be applied if set to true errorlog:s (ro) # errorlog string
A single string? Is there some kind of formatting involved? Is this supposed to be a facade over/replacement for querying journald, or would the callers be expected to get the list of systemd units and query journal themselves?
deploy() # deploy role (i.e. running initial setup
post-package-install, ipa-server-install)
How does rolekit get the configuration necessary to deploy a role?
updateRole() # update role: yum update; restartServices; updateFirewall
How does the caller know that an update is available?
getFirewallZones() # get firewall zone list from firewalld, add used ones to firewall_zones
How does this differ from just reading firewall_zones? Mirek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/26/2014 03:12 PM, Miloslav Trmač wrote:
Hello, 2014-06-20 21:10 GMT+02:00 Thomas Woerner <twoerner@redhat.com mailto:twoerner@redhat.com>:
org.fedoraproject.rolekit1.roles.$name -------------------------------------- services:as (ro) # service list: services to be enabled and started
Where “service” means “systemd unit”?
firewall:a{sas} (ro) # firewall settings: ports and services dict { "ports" => array ( portid:s["-"portid:s]"/"__protocol:s ), "services" => array( name:s ), } ports are similar to firewalld port definitions firewall_zones:as (rw) # firewall zones to apply the firewall settings to custom_firewall:b (rw) # custom firewall: firewall settings will not be applied if set to true errorlog:s (ro) # errorlog string
A single string? Is there some kind of formatting involved? Is this supposed to be a facade over/replacement for querying journald, or would the callers be expected to get the list of systemd units and query journal themselves?
This should be a starting point, yes. (Something for a UI to report easily). Callers wanting more information should be calling journald directly (eventually using the theoretical messageid or service descendent tracking mechanism I just brought up in the "Proposal: Implementation of Server Roles" thread.
deploy() # deploy role (i.e. running initial setup post-package-install, ipa-server-install)
How does rolekit get the configuration necessary to deploy a role?
Ah, looks like Thomas forgot to include the dbus codes here. All of the methods will take arguments. CCing Thomas to get that corrected so we can discuss this meaningfully.
updateRole() # update role: yum update; restartServices; updateFirewall
How does the caller know that an update is available?
Good question. We should probably have a signal and an attribute for this.
getFirewallZones() # get firewall zone list from firewalld, add used ones to firewall_zones
How does this differ from just reading firewall_zones?
This one I'm going to defer to Thomas.
On 06/27/2014 05:29 PM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/26/2014 03:12 PM, Miloslav Trmač wrote:
Hello, 2014-06-20 21:10 GMT+02:00 Thomas Woerner <twoerner@redhat.com mailto:twoerner@redhat.com>:
org.fedoraproject.rolekit1.roles.$name -------------------------------------- services:as (ro) # service list: services to be enabled and started
Where “service” means “systemd unit”?
firewall:a{sas} (ro) # firewall settings: ports and services dict { "ports" => array ( portid:s["-"portid:s]"/"__protocol:s ), "services" => array( name:s ), } ports are similar to firewalld port definitions firewall_zones:as (rw) # firewall zones to apply the firewall settings to custom_firewall:b (rw) # custom firewall: firewall settings will not be applied if set to true errorlog:s (ro) # errorlog string
A single string? Is there some kind of formatting involved? Is this supposed to be a facade over/replacement for querying journald, or would the callers be expected to get the list of systemd units and query journal themselves?
The errorlog is only meant to provide (some) information about the last error that occured.
Maybe a rename to lasterror would be good than to make it more clear, what it is.
This should be a starting point, yes. (Something for a UI to report easily). Callers wanting more information should be calling journald directly (eventually using the theoretical messageid or service descendent tracking mechanism I just brought up in the "Proposal: Implementation of Server Roles" thread.
deploy() # deploy role (i.e. running initial setup post-package-install, ipa-server-install)
How does rolekit get the configuration necessary to deploy a role?
Ah, looks like Thomas forgot to include the dbus codes here. All of the methods will take arguments. CCing Thomas to get that corrected so we can discuss this meaningfully.
The configuration should go into the "role specific settings". For which the role can add additional methods into the API.
There have not been arguments in the proposal before.
updateRole() # update role: yum update; restartServices; updateFirewall
How does the caller know that an update is available?
Good question. We should probably have a signal and an attribute for this.
Ok, yes.. the only question is: where is rolekit getting this information from? Is it actively polling for this information? How does this work with the daemon, that is only started, when needed? In this case it either has to stay alive all the time or wake up every few seconds/minutes/hours automatically or it can not provide a signal for this.
getFirewallZones() # get firewall zone list from firewalld, add used ones to firewall_zones
How does this differ from just reading firewall_zones?
This one I'm going to defer to Thomas.
I have added this method because Stephen asked about it.. I would just propose to use the mathing method in the firewalld D-Bus API to get this information. Stephen, maybe I got you wrong on this one?
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOtje0ACgkQeiVVYja6o6PFwQCgiFs5bXJCbF+t3HzmMEf5bsTs UOgAoKj2bfzOuAdfgxAAOTdo1Z0fjdLe =ni7Z -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/30/2014 07:52 AM, Thomas Woerner wrote:
On 06/27/2014 05:29 PM, Stephen Gallagher wrote: On 06/26/2014 03:12 PM, Miloslav Trmač wrote:
Hello, 2014-06-20 21:10 GMT+02:00 Thomas Woerner <twoerner@redhat.com mailto:twoerner@redhat.com>:
org.fedoraproject.rolekit1.roles.$name -------------------------------------- services:as (ro) # service list: services to be enabled and started
Where “service” means “systemd unit”?
firewall:a{sas} (ro) # firewall settings: ports and services dict { "ports" => array ( portid:s["-"portid:s]"/"__protocol:s ), "services" => array( name:s ), } ports are similar to firewalld port definitions firewall_zones:as (rw) # firewall zones to apply the firewall settings to custom_firewall:b (rw) # custom firewall: firewall settings will not be applied if set to true errorlog:s (ro) # errorlog string
A single string? Is there some kind of formatting involved? Is this supposed to be a facade over/replacement for querying journald, or would the callers be expected to get the list of systemd units and query journal themselves?
The errorlog is only meant to provide (some) information about the last error that occured.
Maybe a rename to lasterror would be good than to make it more clear, what it is.
This should be a starting point, yes. (Something for a UI to report easily). Callers wanting more information should be calling journald directly (eventually using the theoretical messageid or service descendent tracking mechanism I just brought up in the "Proposal: Implementation of Server Roles" thread.
deploy() # deploy role (i.e. running initial setup post-package-install, ipa-server-install)
How does rolekit get the configuration necessary to deploy a role?
Ah, looks like Thomas forgot to include the dbus codes here. All of the methods will take arguments. CCing Thomas to get that corrected so we can discuss this meaningfully.
The configuration should go into the "role specific settings". For which the role can add additional methods into the API.
There have not been arguments in the proposal before.
Thomas and I discussed this on IRC today. He'll be sending revisions shortly.
updateRole() # update role: yum update; restartServices; updateFirewall
How does the caller know that an update is available?
Good question. We should probably have a signal and an attribute for this.
Ok, yes.. the only question is: where is rolekit getting this information from? Is it actively polling for this information? How does this work with the daemon, that is only started, when needed? In this case it either has to stay alive all the time or wake up every few seconds/minutes/hours automatically or it can not provide a signal for this.
Let's defer the signal for now. Let's leave this as a manually-initiated operation at the moment. It's certainly nice-to-have functionality, but I think it can wait for F22, since we're getting down to the wire at this point.
getFirewallZones() # get firewall zone list from firewalld, add used ones to firewall_zones
How does this differ from just reading firewall_zones?
This one I'm going to defer to Thomas.
I have added this method because Stephen asked about it.. I would just propose to use the mathing method in the firewalld D-Bus API to get this information. Stephen, maybe I got you wrong on this one?
I've completely paged out why we added this. If it's easy enough to just get it from the firewalld D-BUS API, then I see no reason to reimplement it here.
rolekit D-Bus API =================
org.fedoraproject.rolekit1 --------------------------
Properties
version:i # server role manager version roles:ao # role objects list
Methods
getNamedRole(name:s)→o # get role by name getRolesByState(state:s)→ao # get all roles with the given state
org.fedoraproject.rolekit1.roles.$name --------------------------------------
Properties (general) # role settings
name:s (ro) # role name version:i (ro) # role implementation version state:s (ro) # deployed/started/inactive/dead? packages:as (ro) # package list: packages and @groups (similar to kickstart) services:as (ro) # service list: services to be enabled and started firewall:a{sas} (ro) # firewall settings: ports and services dict { "ports" => array ( portid:s["-"portid:s]"/"protocol:s ), "services" => array( name:s ), } ports are similar to firewalld port definitions firewall_zones:as (rw) # firewall zones to apply the firewall settings to custom_firewall:b (rw) # custom firewall: firewall settings will not be applied if set to true lasterror:s (ro) # last error string
#backup_paths:as (ro) # backup paths (files and directories) # ... # role specific settings
Methods
start() # start the role (startServices, installFirewall), fails if not deployed stop() # stop the role (stopServices, uninstallFirewall), fails if not started restart() # stop and start deploy(a{sv}) # deploy role (i.e. running initial setup post-package-install, ipa-server-install) # with the given parameters in key value pairs in a dictionary, these parameters should be # saved in the role configuration setings by the role after successful deployment decommission() # decommision (example: moved to another machine, ipa-server-install -u ), stop if started
updateRole() # update role: yum update; restartServices; updateFirewall
Role States ===========
NASCENT = "nascent" DEPLOYED = "deployed" READY_TO_START = "ready-to-start" STARTED = "started" RUNNING = "running" STOPPED = "stopped" DECOMISSIONED = decomissioned" ERROR = "error"
----
Changes to previous version:
- status is of type string - deploy method has argument - renamed errorlog to lasterror
Thomas Woerner twoerner@redhat.com writes:
org.fedoraproject.rolekit1.roles.$name
I don't understand the purpose of "$name" here. Why not "org.fedoraproject.rolekit1.role"? This is the one concrete interface that we want all roles to implement. It can have one concrete name, no?
deploy(a{sv}) # deploy role (i.e. running initial setup # post-package-install, ipa-server-install) # with the given parameters in key value # pairs in a dictionary, these parameters should be # saved in the role configuration setings by # the role after successful deployment
As a generic client that wants to discover and deploy roles, how do I determine the parameters? Is it OK to just pass an empty dictionary?
updateRole() # update role: yum update; restartServices; # updateFirewall
How can I see whether an update is available?
It would be nice to be able to show a localized description and an icon in the UI. Can we get that from somewhere?
STARTED = "started" RUNNING = "running"
What's the difference between these two? A description of the states would be helpful.
ERROR = "error"
I guess an interactive client will want to offer different actions depending on the state of a role. For example, when the state is "nascent", it would offer to deplpy the role, but not to "start" it. When it is "ready-to-start" or "stopped", it would offer to start it. Etc.
What should it offer in the "error" state? Nothing?
Marius Vollmer marius.vollmer@redhat.com writes:
How can I see whether an update is available?
Ahh, I see that you have decided to punt on automatic checking for now. I think manual checking should still be supported so that the user can review an update before deciding to install it. Should we defer to PackageKit for that?
----- Original Message -----
deploy(a{sv}) # deploy role (i.e. running initial setup # post-package-install, ipa-server-install) # with the given parameters in key value # pairs in a dictionary, these parameters should be # saved in the role configuration setings by # the role after successful deployment
As a generic client that wants to discover and deploy roles, how do I determine the parameters?
It’s probably not reasonable to have a generic client with zero knowledge about what is being deployed (if you “deploy PostgreSQL with no information given”, would it be localhost-only or internet-facing?). Something or someone needs to know about that specific role.
Though, it should be possible to have a generic _software_ with zero knowledge about what is being deployed (e.g. anaconda/puppet deploying a role when given a role-specific, knowledge-containing configuration file). That would also imply that it would be _highly desirable_ to provide an One and Only implementation for parsing the configuration file into the required a{sv} format.
STARTED = "started" RUNNING = "running"
What's the difference between these two? A description of the states would be helpful.
Actually, many of the states are rather different from the diagram Stephen sent earlier. Has this been redesigned?
ERROR = "error"
I guess an interactive client will want to offer different actions depending on the state of a role. For example, when the state is "nascent", it would offer to deplpy the role, but not to "start" it. When it is "ready-to-start" or "stopped", it would offer to start it. Etc.
What should it offer in the "error" state? Nothing?
Per the (now invalid?) proposal in the ”Server Role States” thread, the Error state is only reachable for already deployed roles; failure to deploy gets you back to Nascent. Mirek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/01/2014 03:10 AM, Marius Vollmer wrote:
Marius Vollmer marius.vollmer@redhat.com writes:
How can I see whether an update is available?
Ahh, I see that you have decided to punt on automatic checking for now. I think manual checking should still be supported so that the user can review an update before deciding to install it. Should we defer to PackageKit for that?
Yes, I think that's the only realistic solution in this time-frame.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/01/2014 02:56 AM, Marius Vollmer wrote:
Thomas Woerner twoerner@redhat.com writes:
org.fedoraproject.rolekit1.roles.$name
I don't understand the purpose of "$name" here. Why not "org.fedoraproject.rolekit1.role"? This is the one concrete interface that we want all roles to implement. It can have one concrete name, no?
deploy(a{sv}) # deploy role (i.e. running initial setup # post-package-install, ipa-server-install) # with the given parameters in key value # pairs in a dictionary, these parameters should be # saved in the role configuration setings by # the role after successful deployment
As a generic client that wants to discover and deploy roles, how do I determine the parameters? Is it OK to just pass an empty dictionary?
Roles are not meant to be "discoverable" (other than whether a particular role is available for installation). These are going to be a fixed, documented set of arguments unique to each role. We will do input validation in the role implementation, but I'm not sure how (or if) we could make those arguments discoverable (or if we'd want to). The expectation here is that a client of the API would know which attributes are needed for the role from the documentation.
updateRole() # update role: yum update; restartServices; # updateFirewall
How can I see whether an update is available?
It would be nice to be able to show a localized description and an icon in the UI. Can we get that from somewhere?
Again, these things aren't really supposed to be *discoverable*, but this is a reasonable request (for 2.0, IMHO).
STARTED = "started" RUNNING = "running"
What's the difference between these two? A description of the states would be helpful.
Those shouldn't be different. I wonder if he meant to have "starting" rather than "started" there.
ERROR = "error"
I guess an interactive client will want to offer different actions depending on the state of a role. For example, when the state is "nascent", it would offer to deplpy the role, but not to "start" it. When it is "ready-to-start" or "stopped", it would offer to start it. Etc.
What should it offer in the "error" state? Nothing?
Please see the attached image. (This was sent out previously in the "Server Role States" thread)
Stephen Gallagher sgallagh@redhat.com writes:
Roles are not meant to be "discoverable" (other than whether a particular role is available for installation). These are going to be a fixed, documented set of arguments unique to each role. We will do input validation in the role implementation, but I'm not sure how (or if) we could make those arguments discoverable (or if we'd want to). The expectation here is that a client of the API would know which attributes are needed for the role from the documentation.
Hmm, ok. So the role specific code would be pre-loaded into Anaconda and Cockpit somehow, and publishing a new role in a repository needs an update to both Anaconda and Cockpit?
On 02.07.2014 08:17, Marius Vollmer wrote:
Stephen Gallagher sgallagh@redhat.com writes:
Roles are not meant to be "discoverable" (other than whether a particular role is available for installation). These are going to be a fixed, documented set of arguments unique to each role. We will do input validation in the role implementation, but I'm not sure how (or if) we could make those arguments discoverable (or if we'd want to). The expectation here is that a client of the API would know which attributes are needed for the role from the documentation.
Hmm, ok. So the role specific code would be pre-loaded into Anaconda and Cockpit somehow, and publishing a new role in a repository needs an update to both Anaconda and Cockpit?
Yes, I think that's the case. We need role specific UI code. This is exactly the sort of thing we're building Cockpit module support for.
I really don't think we should try and reinvent debconf prompts.
Stef
Miloslav Trmač mitr@redhat.com writes:
It’s probably not reasonable to have a generic client with zero knowledge about what is being deployed (if you “deploy PostgreSQL with no information given”, would it be localhost-only or internet-facing?). Something or someone needs to know about that specific role.
Yeah, but that "something" could be installed together with the rest of the role during deployment, no? If not, we need to find another avenue for getting this "something" onto the system, which seems to be an unnecessary complication to me.
Doing configuration after deployment (and not as part of it), has its own issues, so I am happy to sit back and see how this unfolds. :)
That would also imply that it would be _highly desirable_ to provide an One and Only implementation for parsing the configuration file into the required a{sv} format.
Here are five dollars that say that people will just happily use dictionaries like
{ "/etc/foo.conf": "<contents of /etc/foo.conf>", "/etc/bar.conf": "<contents of /etc/bar.conf>" }
I know I would. :-)
Stef Walter stefw@redhat.com writes:
Hmm, ok. So the role specific code would be pre-loaded into Anaconda and Cockpit somehow, and publishing a new role in a repository needs an update to both Anaconda and Cockpit?
Yes, I think that's the case. We need role specific UI code. This is exactly the sort of thing we're building Cockpit module support for.
Sure, but how does the module get plugged into Cockpit? Would all these modules be installed by default? If a new role becomes available from rolekit, how do we make sure that Cockpit already has the necessary module for it?
This is all possible to solve, and not rocket science, but wouldn't it pretty much duplicate the machinery that we already have (*cough*) for role deployment? Couldn't we reuse it instead?
Anyway, it's just a API and it will change completey anyway once someone starts writing code, so maybe we should just do that. :-)
On 02.07.2014 08:42, Marius Vollmer wrote:
Stef Walter stefw@redhat.com writes:
Hmm, ok. So the role specific code would be pre-loaded into Anaconda and Cockpit somehow, and publishing a new role in a repository needs an update to both Anaconda and Cockpit?
Yes, I think that's the case. We need role specific UI code. This is exactly the sort of thing we're building Cockpit module support for.
Sure, but how does the module get plugged into Cockpit? Would all these modules be installed by default? If a new role becomes available from rolekit, how do we make sure that Cockpit already has the necessary module for it?
In our Fedora Server install of Cockpit we would probably include these role modules by default.
This is all possible to solve, and not rocket science, but wouldn't it pretty much duplicate the machinery that we already have (*cough*) for role deployment? Couldn't we reuse it instead?
Anyway, it's just a API and it will change completey anyway once someone starts writing code, so maybe we should just do that. :-)
Yup, it'd be naive to think otherwise. We're going to have to iterate the API once callers start using it. That was the case with every other DBus API that's been implemented for a system service so far.
Stef
----- Original Message -----
Miloslav Trmač mitr@redhat.com writes:
It’s probably not reasonable to have a generic client with zero knowledge about what is being deployed (if you “deploy PostgreSQL with no information given”, would it be localhost-only or internet-facing?). Something or someone needs to know about that specific role.
Yeah, but that "something" could be installed together with the rest of the role during deployment, no?
That “something” can be a person, not something to install :)
You’re right that there are in principle various stages: 1. only role name known 2. role configuration documentation or specialized UI available 3. role configured, ready to start 4. role running
We are currently calling 3 “deployed” and both 1 and 2 “nascent”, i.e. not making a distinction between the two. Cockpit may well need to know about the difference between 1 and 2, but I don’t think the user needs to know—when the user asks cockpit to deploy some role that is currently in 1, cockpit should transition to 2 transparently without asking. The 1->2 transition may need to be a rolekit facility, but then we end up with rolekit implicitly knowing about the existence of cockpit and a dependencly loop (which is a bit ugly but might nevertheless be the right thing to do).
For now I think we should be perfectly fine just pre-installing all specialized UIs by default.
Doing configuration after deployment (and not as part of it), has its own issues, so I am happy to sit back and see how this unfolds. :)
The way I think about it, only the user-visible activities really count; so “deployment” is an activity that involves user input or interaction. Any kind of package installation or file modifications necessary to make the “deployment” actually happen is invisible enough that we can shuffle it around arbitrarily (e.g. packagees default installed / installed exactly when needed / predictively installed based on Facebook posts / whatever), as long as the user interaction model is maintained.
So, configuration in a sense _is_ deployment. Getting the necessary packages to the server is an invisible activity that might just as well not exist (e.g. because we just preinstall all servers).
That would also imply that it would be _highly desirable_ to provide an One and Only implementation for parsing the configuration file into the required a{sv} format.
Here are five dollars that say that people will just happily use dictionaries like
{ "/etc/foo.conf": "<contents of /etc/foo.conf>", "/etc/bar.conf": "<contents of /etc/bar.conf>" }
I know I would. :-)
Oh yes. And here are five dollars that say that if we allow any two different programs (e.g. rolekit and puppet) to implement the text->dictionary parsing it will end up different in a way that affects semantics. Mirek
Miloslav Trmač mitr@redhat.com writes:
For now I think we should be perfectly fine just pre-installing all specialized UIs by default.
Ok, sounds good.
This also means that we could start banging on the FreeIPA server role UI right away without having to wait for rolekit to mature.
(Thinking loudly: We would bring the module machinery of Cockpit to a point where we can have add-on RPM packages that add a button in a specific place and one or more pages to the UI. We would make one such RPM that depends on freeipa-server and can run ipa-server-install in simple ways. As a second step, we might put some simple PackageKit support into Cockpit to so that freeipa-server can be installed on demand.)
On Mon, 2014-06-30 at 16:44 +0200, Thomas Woerner wrote:
rolekit D-Bus API
deploy(a{sv}) # deploy role (i.e. running initial setup post-package-install, ipa-server-install) # with the given parameters in key value pairs in a dictionary, these parameters should be # saved in the role configuration setings by the role after successful deployment decommission() # decommision (example: moved to another machine, ipa-server-install -u ), stop if started
Bit late, but - why don't the verbs match? "undeploy" is a bit of an awkward word, but you're more likely to guess it as the converse of "deploy" than you are to guess "decommission". or "deploy" could be "commission", of course.
On 09/09/2014 06:28 PM, Adam Williamson wrote:
On Mon, 2014-06-30 at 16:44 +0200, Thomas Woerner wrote:
rolekit D-Bus API
deploy(a{sv}) # deploy role (i.e. running initial setup post-package-install, ipa-server-install) # with the given parameters in key value pairs in a dictionary, these parameters should be # saved in the role configuration setings by the role after successful deployment decommission() # decommision (example: moved to another machine, ipa-server-install -u ), stop if started
Bit late, but - why don't the verbs match? "undeploy" is a bit of an awkward word, but you're more likely to guess it as the converse of "deploy" than you are to guess "decommission". or "deploy" could be "commission", of course.
Primarily because "decommission" is a real English word (and commonly used in enterprises to describe the behavior of tearing down a service).
server@lists.fedoraproject.org
-
Adam Williamson -
Marius Vollmer -
Miloslav Trmač -
Miloslav Trmač -
Stef Walter -
Stephen Gallagher -
Thomas Woerner