Web based interface for custom spins

[Jonathan Steffan]

On Sun, 2007-06-10 at 13:33 -0400, seth vidal wrote:
> On Sun, 2007-06-10 at 11:58 +0200, Nicolas Mailhot wrote:
> > Le dimanche 10 juin 2007 à 15:23 +0530, Rahul Sundaram a écrit :
> > > Nicolas Mailhot wrote:
> > > > Le dimanche 10 juin 2007 à 08:44 +0530, Rahul Sundaram a écrit :
> > > > 
> > > >> Having a web interface would allow anyone to select the package groups 
> > > >> and individual packages and get a ISO image for download. I posted to 
> > > >> fedora-infrastructure list before but we need a web app before talking 
> > > >> about deploying it.
> > > > 
> > > > Yay for killing bandwidth
> > > 
> > > Ignoring the obvious end user benefits?
> > 
> > There are no obvious end-user benefits if an infrastructure that could
> > handle lots of users melts under a few doing iso spins (I suppose you
> > want dvd images in there too right?)
> 
> I'm going to say something here which I'm sure will cause a bit of a fit
> but I'll say it anyway. The bandwidth and server costs of running a
> service like this would be huge. What has been discussed (briefly and
> without much detail is this)
> 
> 1. produce an open source tool to produce web-based respins of fedora
> (and related) distros.
> 2. release this tool so anyone could set up their own site to make
> respinds
> 3. setup a site so people can respin fedora with updates or with a
> different set of packages. There won't be much guarantee that the distro
> will work perfectly but its package set should produce dependency
> closure. 
> 4. charge a fee for access to the site we run. That would help us offset
> the costs and constrain the set of users a bit.
> 
> That's what has been discussed and only a little bit. Right now the
> important part is making a program work to do this, everything after
> that is extra.
> 
> let the angst and flames begin.
> -sv

I just want to step in a weigh in on this. Basically, a web based
front-end has already been planned. From the beginning, we had planned
on making multiple front-ends. Just because Revisor as it is seen now is
a gtk desktop tool, that does not mean we are not working to make
*everything* modular and allow *many* front-ends to be written. I hope I
don't step on toes when outlining this but I don't want things to be
over discussed. Right now what we need is coding. We know what needs to
be done, we have a good model. Now it is time to do it.

Basic Outline:

* Front-end: This will be anything. It will continue to be the gtk
client, it will be a web interface, it could be a Qt client, etc.
Basically, all this component is supposed to do is poop out a Revisor
"template" (as I have been calling it) that will then be moved onto the
next step.

* "Glue": This step is to take the Revisor "template" and go to action
on it. It will setup the needed tasks and do any additional work before
the actual tasks are run.

* Build Server: Ok, it seems we (as a collective) have misunderstood
what I would like Revisor to do at this stage. The current "Revisor",
being just a Gtk application, is misleading in the way that it actually
does all the work for the end-user. We tried to express our goal of
being able to run the Gtk application in "client" mode and define the
compose(s) and then send the definition off to a build server by
including elements in the application workflow that designate when we
would actually had off the process to a remote build server. From the
very first day, at the Redhat Summit, we have expressed we will be
working on multiple front-ends and will be designing around the fact we
want to see a Revisor client and a Revisor server. The build server code
will be FOSS, just like everything else has been (pungi, livecd-creator,
koji, revisor, etc) and anyone will be able to set one up. As to not go
into much implementation detail, *we are working on a web front-end, we
are working on a client server model, we are working on allowing anyone
to setup a full revisor build system*. This Revisor "build" system could
be a single machine running the Revisor gtk application in standalone
mode, it could be the Revisor gtk application running in client mode and
sending the "template" off to another machine (server) for actually
doing the build, it could be a user defining their build on the
web-based front-end and then downloading the template to build it
locally on their own build server or by feeding the template to the
Revisor Gtk application, it could be a user building everything via a
web front-end and then waiting for the notification their download is
ready. To try to keep it somewhat short -> etc. etc. etc.

* Archive Network: This will be like CPAN. Optionally, a user would be
able to submit their "template" to the archive so others can build it
later. There will be an archive network browser in all the front-ends I
am going to be involved with (and at this point that is all of them.)
These templates could be built by any of the methods available. A few
clicks in the Revisor application, a few clicks on a website, a few
clicks to submit the "template" build request off to a server.


In the interest of time, there is a brief outline. There are actually
5,000^9999 more things we want to do with the concept. We also welcome
ideas and additional "things" we should be doing. We are going to try to
be as transparent with Revisor as possible but there are some cases
where we are going to end up "just doing it". It seems we need to get
more information out to everyone. I will try to get everything we
displayed at the Redhat Summit onto the Revisor site.

Revisor Site: http://revisor.fedoraunity.org/

Jonathan Steffan
daMaestro