Interesting Idea The first thing that pops into my mind is where is the task sequence number. this looks all well and good but there are going to be times when for one reason or an other some one will need to update a task or add a new task in the middle.
Additionally I disagree with the simplified names and my reason is here https://bugzilla.redhat.com/show_bug.cgi?id=834569 incidentally this is still a valid bug in 2.1 nightly when I last checked. while it might be nice to give the user a simplified version it can cause unforeseen problems down the line especially when you mix multiple distros which may have packages with identical NERVA so its critical that the programer be able to exactly set the package ID The same goes for the profile name because in multi-org configurations you may wind up with multiple hosts with the same name in different organizations. you need to make the programer specify the org name or number. The thing you need to keep in mind is in the future I know many of the people who have deployed multi-org configurations want the ability to create mulit-org (or muilti-tenant in cloud speak ) because its often discussed on the list and I am fairly positive there is at least on RFE on the subjects. users for example most of my users only need access to their org which is mapped to their business unit but since I support them all along with a few others I need access to every org along with a few colleagues of mine so what we are doing right now is creating users unique users for our selves in each org which is not ideal to say the least. also I have other users who provide support for the systems in two business units because one is a subsidiary of the other but they still want every thing divided into their own org's so they at least give the appearance of not having any interdependence in case they decide to sell or spin off the subsidiary in the future. If the you add the org id or name now its not a big deal but if you do not it may force us to preform a root canal on the code later. Finally my last question is why write a whole task chain scheduler from scratch? why not consider making a plugin API to integrate with existing schedulers like JobScheduler for example or any thing similar. On Mon, Feb 3, 2014 at 10:32 AM, Bo Maryniuk <b...@suse.de> 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? > > -- > Bo Maryniuk > > SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer > > I find television very educating. Every time somebody turns on the set, I go > into the other room and read a book. > > _______________________________________________ > Spacewalk-devel mailing list > Spacewalk-devel@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-devel _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
