New version of mock working (I think)

[Michael_E_Brown at Dell.com]

> -----Original Message-----
> From: fedora-buildsys-list-bounces at redhat.com 
> [mailto:fedora-buildsys-list-bounces at redhat.com] On Behalf Of 
> Clark Williams
> Sent: Monday, June 26, 2006 1:52 PM
> To: Discussion of Fedora build system
> Subject: Re: New version of mock working (I think)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael_E_Brown at Dell.com wrote:
> >>
> >> Does it really have to be a server?  Could it be a push 
> rather than a 
> >> poll?  Mock could make xml-rpc calls to whatever wraps around it.
> >
> > Just catching up on weekend traffic here. XMLRPC is a great idea. I 
> > have implemented several xmlrpc servers in the past, and this is an 
> > idea that could work out well. Given the nature of mock, it would 
> > probably be best if it made calls into plague, rather than 
> the other 
> > way around, but it wouldn't be _too_ much overhead to have a server 
> > that could be polled for status.
> >
> > I have mock hacking on my todo list for this week, so after 
> I finish 
> > catching up with list traffic and get the latest prototype 
> downloaded 
> > and building, I'll take a look at this.
> 
> Ugh. I get the feeling that this is a case of "Oooo shiny!".
> 
> What benefit is it to mock to add either client or server RPC 
> capabilities so that someone can determine mock's state? Are 
> we talking about communicating something besides a string? 
> XML-RPC works GREAT as a marshaling/unmarshaling mechanism to 
> describe complex data structures. In this case however we're 
> talking about telling someone that we're in the "prep" state, 
> or in the "cache_unpack" state.
> 
> If there is a wealth of information that we're not making 
> available to the outside world (i.e. distributed build 
> systems) then yeah, lets set up a series of remote procedure 
> calls and publish them; I'll gladly work on client/server 
> code in the mock codebase if it's justified. But if we're 
> only changing state and not allowing the outside world to 
> interact with us to change our behavior while building, then 
> let's keep it simple.

It is simple, we can do an xmlrpc client in about 7 lines of code and
add it to the status() function. Here are all the lines that I can think
to add that would fully enable this:

In setup_default_config_opts():
	config["status_server"] = None

In command_parse():
      parser.add_option("--statusserver", action="store", type="string",
dest="status_server",
           default=None, help="server to contact for status info.")

In set_config_opts_per_cmdline():
	if options.status_server is not None: config["status_server"] =
options.status_server

In state():
	if self.config["status_server"]:
		import xmlrpclib
		server = xmlrpclib.Server(config["status_server"])
		server.set_mock_status(some_string)
	
A server would probably take another 10-20 lines of code.

An additional argument could probably be made for shared mem or a named
pipe, but I havent coded those, so I don't know. As for simplicity,
another file descriptor pre-opened by plague, or a named pipe passed via
command line would probably be "simpler", but probably not in terms of
lines of code.
--
Michael