On Monday 03 February 2014 16:32:46 Bo Maryniuk wrote: > Hello everyone. > > We are developing here Action Chain feature, where you can add some actions > (install/remove/verify/etc package or other things) to the Chain, making > sort of one-shot batch. These actions won't be executed, until you execute > the entire chain. > > We are also developing the XML-RPC API for it and they are already working > in our branch. :) > > Here how do they look like. For example, in Python you could call: > > client = xmlrpc.... > sid = client.login.... > > # To list them > for chain in client.actionchains.listChains(): > print chain.get("name") > > # Add some package removal. > # Note: the IP is optional, IPv6 accepted too > > client.actionchains.addPackageRemoval(sid, > "myfantasticserver", "12.34.56.78", > [{"name" : "alsa-lib", "version" : "1.0.22",}, > {"name" : "some-name", "version" : "1.2.3.4",},], > "My Chain") > > # Remove actions from some chain: > client.actionchains.removeActions("My Chain", ["Package Install", "Reboot"]) > > # Remove the whole chain > client.actionchains.removeChains(["My Chain"]) > > > You may ask: Why no 10000010000 for system instead? Why no 23445323 instead > for a package? It is simple: you, as an admin in the datacenter, you have an > RPM database, and you can --queryformat it and AWK it the way that your > XML-RPC Python script will understand it right away. > > Adding IDs is possible too, but mainly we looked to operate the packages and > systems at human-compatible way. > > What you think?
Implementing XML-RPC API for this feature? Absolutely. Using "myfantasticserver" and {"name" : "alsa-lib", "version" : "1.0.22",} to identify server and package? Please no. It's not uncommon to have the same machine registered with Spacewalk multiple times and use the same profile name / hostname / IP address for all these registrations. "myfantasticserver" simply won't be enough to uniquely identify the desired server -- only server id will be. Similarly, it's perfectly OK to have two packages with the same NEVRA pushed into one organization (for example RHEL + CentOS). In these situations, your concept would not be able to realiably identify desired packages -- only package id would be. While I understand that the thought of operating with human-compatible data seems appealing, I'm afraid it won't work with API, where we need to model functions in an orthogonal manner -- i.e. one function will give you system id(s), another one will give you package id(s) and a third one will take these two ids and instruct a specific chain to remove packages from a specific system. -MZ _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel