<br>On Wed, Jan 23, 2013 at 5:14 PM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, 2013-01-23 at 12:08 +0200, Marinescu, Bogdan A wrote:<br>
> Please review my fix of bug 3575 (Ensure windows hob client<br>> communication with bitbake backend via xmlrpc). I'd like to get<br>> feedback before uploading the patches. I've pushed my fix on<br>> poky-contrib:<br>
><a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=bogdanm/b3575" target="_blank">http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=bogdanm/b3575</a><br>><br>> Currently, the fix allows bitbake and hob to run on different machines<br>
> and "talk" to each other via XMLRPC (no windows version yet, but it<br>> can be tested in Linux). Hopefully the commit messages will tell the<br>> rest of the story.<br><br></div></div>First two commits are no problem.<br>
<br>Third Commit:<br><br>I don't like the merging of all the extra cache data. I think when a<br>given UI registers, it needs to call into cooker and inform bitbake it<br>requires the extra caches (if it does so). With your current code, we<br>
might as well throw away the extra cache code as it effectively works as<br>the greatest set. I see this only happens in server mode but I'm still<br>not 100% convinced its the right thing to do.<br></blockquote><div>
<br></div><div>I considered that. It would have been the most generic and elegant solution, but I decided against it mainly because currently only Hob uses an extra cache (and judging from its size, it doesn't appear to incur a large speed and/or memory penalty), which didn't seem to compensate for the amount of work needed to implement the extra-caches-load-on-demand feature. Plus, if we go for the load-on-demand, we'll probably want to implement unload-on-exit (when the client exits and the caches aren't needed anymore) for completion, which adds even more complexity. That said, I can start working on this if you think it is the right way to do. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>I also don't see why knotty can't work in server mode?<br>
</blockquote><div><br></div><div>I added my thoughts on that in the bug description page, I'll copy/paste them here:</div><div><br></div><div>=========================================================================================================</div>
<div><pre class="bz_comment_text" id="comment_text_3"><span class="quote">> There is no good reason knotty shouldn't work with a remote server over
> xmlrpc?</span>
There are a few that I've found. The main problem comes from the fact that the server is initialized like this:
server = server.BitBakeServer()
if configuration.bind:
server.initServer((configuration.bind, 0))
else:
server.initServer()
idle = server.getServerIdleCB()
cooker = bb.cooker.BBCooker(configuration, idle, initialenv)
cooker.parseCommandLine()
server.addcooker(cooker)
server.saveConnectionDetails()
server.detach()
As you can see, parseCommandLine is called when the server is initialized. If we switch to client/server model, the command line on the client side won't be taken into account, since it's not ever parsed. Fortunately, this is fairly easy to fix (by moving the command line parsing on the client side).
The real problem, which is related to the one above, comes from dealing with conf/local.conf. This is parsed early in the cooker (loadConfigurationData) and again, the cooker is "linked" with the server and initialized at server creation time. Even if we add a "reparseConfigurationData" method to the cooker, if the client 'bitbake' is started from a different build directory, we need access to that build's directory conf/ files. Hob works differently in this respect, since the user sets the required configuration data in the interface and then Hob calls setVariable on the server, thus setting the proper configuration. Of course, this can be done with knotty or any other user interface too, but it definitely needs some work and should probably be the subject of another bug.</pre>
</div><div>=========================================================================================================</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>Fourth Commit:<br><br>I have a strong opinion that we want to support multiple clients<br>connected to one server. I appreciate this complicates things and<br>currently would be chaotic. I think the easiest way to deal with this is<br>
to have some notion of a single "controller" which would perhaps be<br>represented by the token. We'd then have some kind of handoff process so<br>that a given UI could claim the token and then control the server. We<br>
might be able to lose the need for the manual reclaim option too if we<br>can tie this to the registered handlers somehow?<br><br>Any thoughts on that approach?<br></blockquote><div><br></div><div>I've considered this too, but I dismissed it quickly. I admit that my knowledge about bitbake/hob is still pretty basic and that must have scared me away, but still, there are some hard questions to be answered here. What happens if there is one server connected to two clients simultaneously, each client with its own set of configuration variables? When we switch from one client to the other, we'd need to "reset" the server to use the configuration variables of this last client. In fact, we probably need to restore the full previous _state_ of this specific server/client combination, which might be more than just the configuration variables. Implementing this would probably take considerable effort, but even if we do it, will it be worth from a performance standpoint? It seems like a lot of time and memory would be spend in these save/restore state operations. Of course, the problem will get progressively worse as the number of clients increases.</div>
<div>I had a different idea for this: leave bitbake alone and implement a "meta-server". In short, this meta-server would be a service listening on a specific port on the build machine. The meta-server keeps a "pool" of bitbake servers running on the build machine. The bitbake servers are separate processes, bound to separate build directories, but configured to share as much data as possible (shared state, downloads and everything else that can be shared). When the meta-server receives a request from a client, it would:</div>
<div><br></div><div>1. check if a bitbake server from its server pool is available (idle). </div><div>2. if not, create a new bitbake server (properly set to share data as described above). Add this sever to the server pool.</div>
<div>3. the result of steps 1 or 2 above will be a free bitbake server, ready to be connected to the client, so the meta-server will pass the host/port data of the bitbake server to the client, so they can talk directly.</div>
<div>4. when the client finishes, it sends a "release server" request to the meta-server, which will mark the server as "idle" (and maybe restart it to reset its internal state? not sure if this is needed).</div>
<div><br></div><div>To add knotty into the picture, step 3 above might be augmented with a file transfer step that would send the whole "conf/local.conf" directory on the client side to the (meta-) server. The server would then receive the client's configuration, interpret it, ignore what needs to be ignored (mostly the variables used to share various data with the other bitbake servers on the build machine) and start the build.</div>
<div>This is still quite a bit of work, but for someone with my basic level of understanding of the bitbake internals it sounds much easier to implement. For me, this is conceptually like chosing between modifying Python to remove its GIL restrictions versus simply using multiprocessing for fixing a problem that can be fixed with both approaches.</div>
<div><br></div><div>Thanks,</div><div>Bogdan</div><div><br></div></div><br><div class="gmail_quote">On Wed, Jan 23, 2013 at 5:14 PM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, 2013-01-23 at 12:08 +0200, Marinescu, Bogdan A wrote:<br>
> Please review my fix of bug 3575 (Ensure windows hob client<br>
> communication with bitbake backend via xmlrpc). I'd like to get<br>
> feedback before uploading the patches. I've pushed my fix on<br>
> poky-contrib:<br>
><a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=bogdanm/b3575" target="_blank">http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=bogdanm/b3575</a><br>
><br>
> Currently, the fix allows bitbake and hob to run on different machines<br>
> and "talk" to each other via XMLRPC (no windows version yet, but it<br>
> can be tested in Linux). Hopefully the commit messages will tell the<br>
> rest of the story.<br>
<br>
</div></div>First two commits are no problem.<br>
<br>
Third Commit:<br>
<br>
I don't like the merging of all the extra cache data. I think when a<br>
given UI registers, it needs to call into cooker and inform bitbake it<br>
requires the extra caches (if it does so). With your current code, we<br>
might as well throw away the extra cache code as it effectively works as<br>
the greatest set. I see this only happens in server mode but I'm still<br>
not 100% convinced its the right thing to do.<br>
<br>
I also don't see why knotty can't work in server mode?<br>
<br>
Fourth Commit:<br>
<br>
I have a strong opinion that we want to support multiple clients<br>
connected to one server. I appreciate this complicates things and<br>
currently would be chaotic. I think the easiest way to deal with this is<br>
to have some notion of a single "controller" which would perhaps be<br>
represented by the token. We'd then have some kind of handoff process so<br>
that a given UI could claim the token and then control the server. We<br>
might be able to lose the need for the manual reclaim option too if we<br>
can tie this to the registered handlers somehow?<br>
<br>
Any thoughts on that approach?<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br>