On Tue, Aug 23, 2011 at 06:26:18PM +0200, Bo Maryniuk wrote: > > The main core of the logger is a separate daemon that serves XML-RPC > listener to a localhost only. Then each software component in the > Spacewalk is going to send an logging event message through it.
Currently, every Spacewalk component talks to one datastore, the underlying database. Why cannot that component log directly to the database to which it already has open connection, rather than trying to log to another daemon which might be down? Logging to the underlying database has the additional benefit of being transactional if you need it to be -- if the action did not take place for whatever reason and it was rolled back, so will the logging event, unless you decide to explicitly commit it, potentially in an autonomous transaction. > Daemon is designed in a queue fashion, where request gets immediate > response, message is accepted inside an embedded database and then > processed accordingly. This way it won't impact software components > performance. What if the daemon is down? Will it stop Spacewalk components from working? > The API for XML-RPC are intentionally generic: they accept a login ID, > a string message and a key/value map. While first two parameters are > pretty obvious how to use, Nope. What is the login ID supposed to represent? > Impact on a Spacewalk > > Entire Spacewalk components are going to be altered, where each > audit-able action will perform a call. Please give me an example of three different events / code points that you would consider an auditable action. > Q: Why not AMQP or other messaging? > A: We considered that. But concluded that we rather want it small, > straightforward and simple, available everywhere: http://goo.gl/usti8 :) So, what is the size of that daemon and its plugins, compared to AMQP? I'd rather not have yet-another-message-queue system in Spacewalk to maintain when there are already multiple open-source project achieving similar task. If the architecture is generic enough, you should be able to use AMQP instead, shouldn't you? So why not start with using AMQP as the daemon, and making your daemon optional? > Q: Why not just another log appender? > A: We believe it should be generic, agnostic and reliable. Hence > the embedded database and thread black magic are involved among other > things. :) I'd consider embedded database and thread black magic to be in direct conflict with the reliable requirement. > We are going to open it under Apache Licence 2.0 and contribute back to If the patch should have any chance of being included in Spacewalk upstream, it has to be under GPLv2 as well, since according to http://www.apache.org/licenses/GPL-compatibility.html those two licences are not compatible. > the community along with a mega-patch for Spacewalk 1.2 base. it the patch should have any chance of being included in Spacewalk upstream, it has to be a stream of patches again Spacewalk master, not against Spacewalk 1.2. In other words, unless the patch applied without conflicts to Spacewalk master (in which case you'd probably make it a patch against master in the first place), I doubt there will be many people willing/capable of forward porting the changes. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
