Web based interface for custom spins

[Jeroen van Meeuwen]

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