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
