FUDCon website

[Toshio Kuratomi]

On Mon, Jul 18, 2011 at 02:04:20PM -0400, Paul W. Frields wrote:
> On Mon, Jul 18, 2011 at 08:19:15PM +0530, Rahul Sundaram wrote:
> > On 07/18/2011 08:17 PM, Paul W. Frields wrote:
> > > On Mon, Jul 18, 2011 at 06:16:03PM +0530, Rahul Sundaram wrote:
> > >> COD is basically a bundle of several Django modules and some
> > >                                        ^^^^^^ Drupal?
> > >> customization settings.   If we follow the usual Fedora packaging rules
> > >> and start unbundling and packaging each of the modules separately,  we
> > >> would not finish this work on time I suspect
> > > +1.
> > 
> > Yes,  Drupal  ( I am spending too much time with Django modules because
> > of Askbot)   I am not sure how to handle this.  I can do a quick and
> > dirty package for our purposes now and working on unbundling it slowly
> > if that is a option.   Otherwise,  there are dozens of modules to
> > individually review and there is a lot to work on. 

[...]

> It is possible to start with a distribution and then customize it
> further, just as with the Drupal core itself (or a Linux distro).
> This model gives the lie to the usual "We must unbundle and package to
> deploy this" strategy.  I recommend that if you want to include this
> on Fedora infrastructure, the infrastructure admins are going to need
> to consider the model and whether/how to support it.  (Hint: that
> model seems no less maintainable in the long term than writing our own
> apps from scratch.)
>
To go to production, the code would definitely need to be unbundled.

For playing around in early stages (not hooked to FAS, not being used for
real data/workflow/etc) it could be done on a publictest with the COD
distribution.

stickster raised concern over the config that integrates everything
together.  I don't see an issue with that being treated as data and configs
and we'd either just start with the DB from COD and make sure we have
constant backups of that and/or have it tucked into puppet to deploy.
Only the code needs to be unbundled and packaged.  I hear that COD likely
has some of its own code -- that would likely be something we'd want to ship
in a COD package.  The only thing I'd worry about here is if some bundled
code is getting patched by COD... that's a danger with any upstream that
bundles, though.

stickster also mentioned that there's a deployment script for COD that we
could look at.  It may be that the script knows how to take a box with
a collection of drupal modules and turn it into a COD deployment.  That
could either be used to isolate the things we need for puppet and to keep
backed up above, or we could potentially adapt it for use in a kickstart
script for bringing up a new machine if that makes more sense.

Note a couple things:
1) We haven't heard back from the people that are currently working on
a dynamic events app.  Need input from Nushio and the GSoC work.
2) Need to figure out hardware requirements for this -- insight lives on its
own box because we didn't think we could secure it as well as the apps we
have on our app servers.  ATM, I don't believe it's even load balanced.  If
we did the same thing for this, you'd have to know that it wasn't as
reliable as the wiki (with the wiki, we have removed some SPOFs).  If we
want to remove SPOFs from this as well, we'll have to start thinking about
how much hardware we need to do that.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/logistics/attachments/20110718/cfc5419e/attachment.bin