FUDCon website

[Paul W. Frields]

On Mon, Jul 18, 2011 at 12:13:30PM -0700, Toshio Kuratomi wrote:
> 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.

I was the one from whom Toshio heard that, I believe. ;-)  I referred
here:

http://drupalcode.org/project/cod_support.git/tree

This seems to be the area where COD's own code is kept.  It looks like
it's stored as managed Drupal Features (leveraging the contrib
Features module), which is a good sign.

> 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.

The deployment stuff for COD is here:

http://drupalcode.org/project/cod.git/tree/refs/heads/6.x-1.x

This looks to be programmatic deployment through Drupal itself.  In
other words, you would download the code and then you would install
the COD app profile through the installation process in a Web browser,
similarly to how one installs Drupal in a sandbox now.

> 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.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com