Announcing Ubuntu Ensemble, mediawiki community feedback requested

[Clint Byrum]

Excerpts from Platonides's message of Sat Jun 11 15:14:13 -0700 2011:
> Ahmed Kamal wrote:
> >> So, when you add a second demo-wiki, how is the second mediawiki
> >> configured? A simple copy ? How are further changes synced?
> >
> > The same hooks that configure the first instance, are triggered to
> > configure the second instance. Since hooks should be written in an
> > idempotent manner, all instances reach the same configuration state
> > driven by the provided Ensemble variables. I'm not sure what you mean by
> > sync'ed. All MW instances use the same DB, thus get the same data. If
> > you're talking about a shared file-system, I don't believe the formulas
> > have that yet, however, there is work to do a glusterfs formula (and
> > other shared FSs) to enable that. If that is something that interests
> > anyone here, you can write that formula, it's really quite simple
> 
> A really simple case: you want to change the wiki name. The process is 
> that you edit $wgSitename at LocalSettings.php. But if you have several 
> copies floating around...

Config settings will necessitate a set of code that is shared between
the various hooks that can configure a service. Basically there is a
matrix of things that the formula can change, and it will be fed to
the template.  If install.php can handle this, w00t. If not, we'll work
around it. Either way, generating a PHP file with the settings is not
really rocket science.  Doing it the way you guys recommend will likely
reduce the amount of maintenance and bugs long term.

> 
> >> What about optional packages? If you are installing for a large scale
> >> cloud deployment of mediawiki you probably also want php-apc, or
> >> wikidiff2 extension.
> > Well if you want php-apc, just add it to the apt-get line of the install
> > hook. Very soon, formulas will be configurable as well, so having
> > php-apc as an "optional" install will be possible. I have no idea what
> > wikidiff2 is, but can't see a reason why it cannot be installed as well.
> > It really depends on what you (the expert community) define as best
> > practice
> 
> wikidiff2 is a php module written in C++. It calculates the same diffs 
> that the php code provided in mediawiki does, but faster.
> 
> Sure, if you have the know-how, you know that php apps should have a 
> bytecode accelerator, that MediaWiki is better with wikidiff2...
> But in that case you may prefer to do things manually instead of using 
> ensemble.

Doing things manually is certainly easy w/ Ensemble. You can take our
formula, and just replace our super-opinionated defaults with your
default settings, or with a hook that just does exactly what you want.
There will still be documentation required to make the more complicated
formulas really shine when deployed. But if there's no good reason to
disable APC other than "its hard to deploy", then it should be enabled
by default, and likewise w/ wikidiff2.

> 
> >> I recommend you to plan and test with 1.17 and tell us if you need
> >> some additional feature. It still could enter in the release, if it's
> >> simple enough.
> >> http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_17/phase3/
> >>
> >
> > Thanks! I don't think we should need any modifications to MW (or any
> > other package for that matter). At least I hope we don't! Regarding
> > testing and tweaking for 1.17, I'd love to do that, however since
> > Ensemble is on its way to supporting all cloud deployable software, the
> > only scalable model I can see is for the expert community of each
> > respective package to step-up and start tweaking the formulas.
> 
> Note that those communities may not be interested in suporting your "pet 
> system" (no offense intended). Maybe they would if it becomes the new 
> standard for cloud configuration. But back to point #1 for that you need 
> the configurations to be supported.

No doubt. We're reaching out to every community that we're interested in,
and making it known that we would appreciate your input. Hopefully this
will scratch an itch for somebody and they'll pick up maintenance. If
not, we'll still carry the things users ask for and that we feel are
useful as best we can.

Its not unlike the Debian process where people who package something may
just be packaging experts, not experts in what they're packaging. With
a little help here and there from upstream, the package will be loved
by users and by upstream. If the packager goes off on their own little
packaging adventure, the package usually becomes the bane of the
upstream community. See Debian's ruby woes up until recently for an
example of this.

> I think you should start supporting very well just a few apps. When it 
> is "good and reliable" for X,Y,Z support for more projects will easily 
> come. OTOH a half-solution for many projects is unlikely to be found 
> acceptable by most developers.

Agreed. Our intention is to provide a few examples of end user apps like
MediaWiki and Wordpress, and then make sure the common tools people are
using to build apps are available, like MySQL, haproxy, memcached, etc.

Thanks again for taking a look and engaging with us as we step out into
this somewhat uncharted territory.