[Framework-Team] Testing for PLIP 209: Unified Installer Plus Buildout

[Raphael Ritz]

Steve McMahon wrote:
> Thanks for the great review and suggestions, Martijn!
>
> I'm pleased to report that the PID problem is taken care of. Nouri
> fixed it for zope2instance in:
>
> http://dev.plone.org/collective/changeset/55898
>
> and for zope2zeoserver in:
>
> http://dev.plone.org/collective/changeset/55899
>
> The other CLIENT_HOME problems are messier than they should be, but
> should be taken care of by the
>
> command =
>     ...
>     find ${buildout:directory} -type d -name var -exec chown -R
> ${client1:effective-user} \{\} \;
>
> section of buildout.cfg that's inserted for root-mode installs.
>
>   

Excellent news. Almost +1 on all of this from me as well
but (there's always a but, isn't it ;-) there is one issue
I currently consider a show-stopper (sorry, but it should
be easy to fix as you'll see):

When going to the 'prefs_install_products_form' of a
Plone site it says:

"To make new products show up here, put them in the directory
 */tmp/test_PloneUI/Plone-3.0.5-UnifiedInstallerBuildout/zinstance/parts/instance/Products* 

on the file system, and restart the server process."

The problem here is that we point people to *parts/instance/Products*
which is plain wrong! Update your buildout and your add-ons will be 
gone. :-(
This should rather point to zinstance/products instead.

Apart from that I've only two suggestions for eventually
improving the already excellent documentation:

(i) when describing start/stop/status we might want to add
'fg' (foreground) as a simple means to start in debug mode
without changing the configuration

(ii) maybe I screwed it up myself but I couldn't specify a
relative path when specifying the target as follows:

ritz at ritz-laptop:/tmp/test_PloneUI/Plone-3.0.5-UnifiedInstallerBuildout$ 
./install.sh --target=. standalone
Stand-Alone Zope Instance selected

Detailed installation log being written to 
/tmp/test_PloneUI/Plone-3.0.5-UnifiedInstallerBuildout/install.log

Rootless install method chosen. Will install for use by system user ritz
zlib installation: no
libjpeg installation: no

Installing Plone 3.0.5 + Buildout at .

Skipping zlib compile and install
Skipping libjpeg compile/install
Installing Python 2.4.4. This takes a while...
Install of Python 2.4.4 has failed.

Installation has failed.
See the detailed installation log at 
/tmp/test_PloneUI/Plone-3.0.5-UnifiedInstallerBuildout/install.log
to determine the cause.

(end of transcript)

Specifying an absolute path, however, worked like a brise.
Should there be a issue hidden here this could be fixed
or mentioned.

Anyway, this is all excellent work. I'm all for adopting
it as soon as possible (although I consider this quite
a drastic change for a x.1 release). But please fix the
wrong pointer in the 'prefs_install_products_form'.

Cheers,

    Raphael


> Ideally, though, we should work towards a setup where the server and
> client processes never write into parts.
>
> Thanks, Steve
>
>
> On 2/10/08, Martijn Pieters <mj at zopatista.com> wrote:
>   
>> On Jan 17, 2008 2:00 AM, Steve McMahon <steve at dcn.org> wrote:
>>     
>>> An implementation of PLIP 209: "Unified Installer Plus Buildout" is
>>> available for testing at:
>>>
>>> https://launchpad.net/plone/3.0/3.0.5/+download/Plone-3.0.5-UnifiedInstallerBuildout-beta1.tar.gz
>>>       
>> You have since created a beta2:
>>
>>   https://launchpad.net/plone/3.0/3.0.5/+download/Plone-3.0.5-UnifiedInstallerBuildout-beta2.tar.gz
>>
>> :-)
>>
>> As there is no review bundle possible for this, I'll give my review
>> notes in this reply:
>>
>> I tested the full download and tested the different installation
>> options on both Mac OS X and Linux (Debian Etch). Everything worked
>> absolutely beautifully. In short, my verdict can be summed up as
>> 'absolutely ruddy brilliant!'. I am very impressed with the execution
>> and the polish on the buildout-version of the unified installer, and
>> I'll certainly be reusing the precompile recipe in production
>> buildouts.
>>
>> One remark about the as-root install using the effective user setup.
>> There is a problem with that setup which lies outside of the scope of
>> the Unified Installer, but which will perhaps come up in support
>> requests. Currently, zope2instance sets CLIENT_HOME as
>> $INSTANCE_HOME/var, which means on that this variable points to a
>> subdirectory of the part directory (usually parts/instance). This
>> means that this directory will get wiped and re-created when updating
>> the buildout settings for that recipe.
>>
>> That wouldn't be so big a problem if it weren't for the fact that
>> various things get written to the CLIENT_HOME, such as the zopectl
>> daemon PID (at least at some point, it may be that Florian Schulze has
>> fixed that one). Any files written there are of course written by the
>> effective user, meaning that a buildout update can perhaps not delete
>> these files, and/or that the effective user cannot write in the
>> directory afterwards.
>>
>> The solution is to create subdirectories of the buildout var/
>> directory (where filestorage and log live) for each Zope client and
>> for a zeo server, and setting these directories as the CLIENT_HOME for
>> each Zope instance. This is something that needs to be fixed in
>> zope2instance. Once that's done, PlacelessTranslationService has to be
>> fixed to use CLIENT_HOME instead of INSTANCE_HOME/var to write it's
>> translation files, as it does currently.
>>
>> So, in summary, this PLIP has my big thumbs up. Just be aware of
>> potential problems around the instance home part and the effective
>> user due to a misconfigured CLIENT_HOME.
>>
>> --
>> Martijn Pieters
>>
>>     
>
>
>