Ignacio Vazquez-Abrams wrote: > On Sun, 2007-06-10 at 14:06 +0200, Jeroen van Meeuwen wrote: >> Ignacio Vazquez-Abrams wrote: >>> What about having the web-based interface generate a set of scripts that >>> could be used to pull down the packages (with wget or curl, and using >>> mirrormanager for the package base), create the administrivial files >>> (initrd, modules.cgz, etc.), and create the .iso (with mkisofs et al)? >>> That way all they'd need is tools that are available on any distro (I'm >>> sure we can toss rpm2cpio.sh in). Heck, they might even be able to do it >>> under cygwin. >> It wouldn't make sense to me to do things this way. Basically, we have >> the application in place, all it needs is a web interface to get some >> configuration file or settings, and trigger the build. It sounds simpler >> then it is though ;-) > > True, but then they don't have to chew up the bandwith of the web server > or whatnot downloading the iso once it's done. > > Yes, they could deploy the web service locally, but then they would need > to have a rpm/yum-capable system. And if they use a remote system then > they'll be using that remote system's bandwidth. And it's not likely > that the respins will be mirrored anywhere; it will most likely be a > "use once and destroy" situation. > > By supplying them with only the scripts we reduce the bandwidth from the > single server and spread it around to the mirrors. Yes, the respinner > will still have to do a bit of work, but it's probably *far* less than > setting up another system and deploying the application. And most of the > scripts will be the same from user to user anyways, with only the > package list changing. > > Basically, the web-interface driven model is in. Frankly I don't care if anyone wants to do a "public" build server with it. From my perspective a web-interface helps those who want to do (multiple) builds but don't have the workstation to run the Revisor client (assuming the XML-RPC client/server model gets in place). Whether that build server faces the public or is a private, local build server, is not for me to decide, I just do the coding. About possibly eating bandwidth: it's not my choice or problem either. We can do "dump-some-scripts-and-binaries-rather-then-fully-run-the-build-so-that-users-can-build -off-line-not-eating-the-web-server's-bandwidth', but to me it has no added value compared to a fully web-interface driven build-server, so expect it to get a low priority. Feel free to request the enhancement at our ticketing system; the more open everything is, the better. That includes porting (some of) the scripts or distributing binary stuff from a build server so that workstation can do builds themselves. Also, feel free to submit the code or assist us in getting things done if you feel we're getting behind ;-) Kind regards, Jeroen van Meeuwen -kanarip -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
