New version of mock working (I think)

[Michael_E_Brown at Dell.com]

<aside>Sorry for the format of the posts today, forced to use stupid webmail which is slow and ugly.</aside>

How about the old unix everything is a file concept? We could just have a --status_file parameter that could take a file or a named pipe as input, it would look the same to us, whether it was a pipe or a regular file. Either that, or we could even have a --status_fd parameter for people that might want to pre-open a file and pass it to us as an fd when they fork/exec.

We might want to consider removing the open()/close() and instead just flush() it. We still shouldnt really need locking.
--
Michael

-----Original Message-----
From: fedora-buildsys-list-bounces at redhat.com on behalf of Dan Williams
Sent: Tue 6/27/2006 9:12 AM
To: Discussion of Fedora build system
Subject: RE: New version of mock working (I think)
 
On Mon, 2006-06-26 at 16:19 -0500, Michael_E_Brown at Dell.com wrote:
> > -----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 4:07 PM
> > To: Discussion of Fedora build system
> > Subject: Re: New version of mock working (I think)
> > 
> > Ok, I can go with that. Probably the most convincing portion 
> > of the above argument is the idea of implementing a 
> > root-privilege server as opposed to pushing that back to the 
> > build system maintainers.
> > 
> > So I suppose it means that we should publish a call-out 
> > specification that says: if you invoke mock with the  
> > --server-mumble=X on the command line, mock will use X as a 
> > URL to make an XML-RPC call with the state  as an argument in 
> > <as yet to be determined> form.  We will then have to wrap 
> > that in a try/except and possibly some timeout logic to make 
> > sure that if the other end isn't speaking our language, we 
> > continue or fail in a controlled fashion.
> 
> I have some stock timeout and exception handling code that we can cut
> and paste in. It adds another 5-10 lines of code, and should make the
> code robust against what you describe.
> 
> First order of business would be to get Dan's opinion on the matter,
> then settle on an API. I can code this up, along with a test harness.

I hate to throw water on the fire, but to me XML-RPC seems like a
sledgehammer.  There's actually a ton of code in xmlrpclib.py and for
this specific instance of pushing status information back to a
controlling process, I think it's somewhat heavy-handed.

Stepping back a second, what are we trying to do with this?  We're only
trying to push a status string, and possibly a UID/PID, back to some
other process.  I don't have a good idea what might be functionality
might be wanted in the future here though, but having mock as a discrete
program that's fairly uncomplicated seems like a good thing to me.

XML-RPC is quite nice, especially from Python, but it doesn't feel like
the solution that fits the problem here.

So, either of the two other proposed solutions would work for me:

1) Status file with locking.  If there's locking, I can stat() the file
and find out how big it is before trying to read it.  Hence, no need for
non-blocking IO here, though the previous blocking problems could be a
stupid problem on my part in plague.

2) Unix socket provided by plague-builder, which mock writes to.  Pass
mock a --status-socket argument pointing to the location of a status
socket.  We can also use Unix socket peer credentials (like dbus and
gnome-keyring) here to verify that the writer to the socket is actually
the 'mock' user or whatever, in addition to setting permissions on the
socket itself.

I'd vote to #1 to start with since it's the simplest, then #2 if we have
issues with #1.

Either of these starts falling down fairly quickly if we want to push
more than a few items of status information to the controlling process
from mock.  But in that case, we should ask _why_ we're trying to push
so much info back, and if we need to.  If we decide we need to, then I
think we should investigate XML-RPC, possibly over TCP/IP, but most
likely over a local unix socket.  I just don't think mock needs to be
network-enabled.

Dan


--
Fedora-buildsys-list mailing list
Fedora-buildsys-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list