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:
[EMAIL PROTECTED]:/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 <[EMAIL PROTECTED]> wrote:
On Jan 17, 2008 2:00 AM, Steve McMahon <[EMAIL PROTECTED]> 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
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
