plainblack.com
Username Password
search
Bookmark and Share

    

Wobject install/upgrade infrastructure

User patspam
Date 7/10/2008 3:20 am
Views 1541
Rating 0    Rate [
|
]
Previous · Next
User Message
patspam
It strikes me that something similar to the WebGUI upgrade infrastructure would be really useful for deploying/upgrading my own custom Wobjects to my clients' servers. I'm interested to hear what automated scripts you guys are using before I run off and roll my own solution.

Here are my thoughts:

Installing a Wobject to a single site is similar to upgrading a single site in the following ways:
  • You want to make it happen from the command line
  • You want to set the site to maintenance mode during the process
  • You want to back up the site as the first step
  • You want to modify the site db, preferably through the WebGUI API
  • You want to add collateral (such as templates) to the site's importNode with packages
  • You want to modify the site's WEBGUI_CONFIG file (to enable your Wobject etc..)
  • You want to be able to upgrade old versions of your Wobject by applying one or more upgrades
  • You want to be able to apply all your changes under a Version Tag
However there are also some differences. Firstly, you need to install the Wobject "to the server" first:
  • Add your Wobject lib directory to preload.custom
  • Symlink your Wobject-specific static files to /data/WebGUI/www/extras/wobject/<WOBJECT> so that they are served by modproxy
  • Symlink your Wobject's icons to /data/WebGUI/www/extras/asset[/small] so that they show up in the admin console
Secondly, installing a Wobject is something that you probably want to do on a per-site basis rather than for all sites indescriminately as the upgrade script does. If you do want to install the Wobject for all sites, you're still going to have to install the Wobject manually for any new sites you add later because, unlike core upgrades, your db changes and package imports won't make their way into the skeleton for new sites (i.e. create.sql, WebGUI.conf.original and /data/WebGUI/www/uploads).

Patrick


Back to Top
Rate [
|
]
 
 
preaction

I wrote a mixin to the Asset class that installs an asset based on its definition.

There are some more features that I need to add, such as dependency-checking and installing packages, but it works to add the asset's table to the database and add the asset to the configuration file.

It's available in my experimental branch:

https://svn.webgui.org/svnweb/plainblack/view/branch/doug-experimental/lib/WebGUI/AssetMixin/Installable.pm

https://svn.webgui.org/svnweb/plainblack/view/branch/doug-experimental/sbin/installAsset.pl

This mixin requires the mixin.pm module to be installed from CPAN.

Then it's just a simple matter of putting "use mixin 'WebGUI::AssetMixin::Installable'" and running the installAsset.pl with your class as the first argument.

Patches are welcome.



Back to Top
Rate [
|
]
 
 
patspam
That looks really cool. I've had a think about the features I'd like to add to it to make it something that people can use to install/upgrade/remove their own Wobjects, as well as easily share them with other people. I'm sure there's lots of room to improve on this, so please don't hold back on the criticism..

Firstly, I suggest Wobjects be distributed as tarballs with the following structure:
  • /docs
    • changelog.txt, credits.txt, gotcha.txt, install.txt, legal.txt, license.txt (as per WebGUI distro itself)
    • collateral.wgpkg - most up-to-date exported package of your Wobject's importNode collateral folder
  • /upgrades
    • upgrade_x.x.x-x.x.y
    • upgrade_x.x.y-x.x.z, etc..
  • /lib -all of your custom Perl code, same directory structure as /data/WebGUI/lib
  • /script (optional) - utility scripts, e.g. a script to populate a site with demo Wobject data
  • /t - your Wobject's test suite
Just a note on Wobject collateral - older core Wobjects seem to use /data/WebGUIwww/extras/wobject to store static files. However newer Wobjects, and I feel the best practice for non-core Wobjects, is to store all collateral inside a single <WOBJECT> folder in the importNode. Static files includes files such as js, css, flash, images etc.. and also templates. This best practice should also be applied to your Wobject's asset image, which is normally stored in /data/WebGUI/www/extras/asset[/small]. To achieve this, you will need to override getIcon() in your Wobject. By doing this, it's easy to install or upgrade the latest version of your Wobject's collateral using the single /docs/collateral.wgpkg. As with core Wobjects, content managers should be encouraged to modify copies of templates rather than distributed templates, otherwise newer package releases will overwrite their changes.

I propose extending your installAsset.pl so that it performs the following steps:
  • Gets command-line options
    • --site
      • the name of a WebGUI site config file, or 'all'
    • mode
      • --install (default)
        • installs to specified site(s)
      • --remove
        • uninstalls from specified site(s)
      • --upgrade
        • upgrades all sites that have Wobject installed (implies --site=all)
    • options
      • --skipBackup
      • --skipMaintenance
  • Performs a dependency check
    • Check module dependencies (Including WG version)
    • Check that Wobject lib has been added to preload.custom
  • [Optional: Run Wobject test suite. Would need to be told what test site to run tests against]
  • Site backup (unless disabled)
  • Maintenance Mode on (unless disabled)
  • Depending on mode, for each site..
    • --install
      • $wobject->install()
    • --uninstall
      • $wobject->uninstall()
    • --upgrade
      • detect Wobject version (Wobjects need to know their version number)
      • launch all appropriate upgrade scripts in /docs/upgrades
      • import collateral.wgpkg (upgrades only need latest version, just like install)
  • Maintenance Mode off (unless disabled)
  • Tell user to restart web server
I also propose extending your AssetMixin::Installable so that the install() / uninstall() subroutines, which currently do:
  • Auto-creates asset table from Wobject definition
  • Adds/removes Wobject in WEBGUI_CONFIG file
..also do the following:
  • Perform the install/uninstall under a Version Tag
  • add an addPackage() helper subroutine, along the lines of addPackage() in upgrade.pl which developers can call from their overridden install subroutine
With all of that in place, manual (command-line) usage would be a simple matter of:

Manual Install
  • Download Wobject tarball
  • Extract to $FOLDER
  • Add $FOLDER/lib to preload.custom
  • installAsset.pl My::Wobject --site=<SITE>
Manual Upgrade
  • Extract new Wobject tarball over the top of $FOLDER
  • installAsset.pl My::Wobject --upgrade
Manual Uninstall
  • installAsset.pl My::Wobject --site=<SITE> --remove
  • if no other sites are using Wobject
    • delete $FOLDER
    • remove $FOLDER/lib from preload.custom
Down the track, it would be possible (and very convenient) to add this functionality to the wreconsole:

WREConsole Install
  • Give URL to Wobject tarball
  • Choose <SITE>
  • Choose options
  • Click Install
    • Downloads and extracts tarball to common 3rd-party Wobjects folder
    • Adds Wobject lib sub-folder to preload.custom
    • Runs installAsset.pl My::Wobject --site=<SITE>
WREConsole Upgrade
  • Give URL to new Wobject tarball
  • Choose options
  • Click Upgrade
    • Overwrites tarball to $FOLDER
    • Runs installAsset.pl My::Wobject --upgrade
WREConsole Uninstall
  • Choose Wobject from list of installed 3rd-party Wobjects
  • Choose options
  • Click Uninstall
    • installAsset.pl My::Wobject --site=<SITE> --remove
  • or click Delete
    • Deletes $FOLDER
    • removes $FOLDER/lib from preload.custom
What do you think?

Patrick

On Fri, Jul 11, 2008 at 12:28 AM, <doug@plainblack.com> wrote:
preaction wrote:

I wrote a mixin to the Asset class that installs an asset based on its definition.

There are some more features that I need to add, such as dependency-checking and installing packages, but it works to add the asset's table to the database and add the asset to the configuration file.

It's available in my experimental branch:

https://svn.webgui.org/svnweb/plainblack/view/branch/doug-experimental/lib/WebGUI/AssetMixin/Installable.pm

https://svn.webgui.org/svnweb/plainblack/view/branch/doug-experimental/sbin/installAsset.pl

This mixin requires the mixin.pm module to be installed from CPAN.

Then it's just a simple matter of putting "use mixin 'WebGUI::AssetMixin::Installable'" and running the installAsset.pl with your class as the first argument.

Patches are welcome.



http://www.plainblack.com/webgui/dev/discuss/wobject-install/upgrade-infrastructure/1


--

Plain Black&#44; makers of WebGUI
http://plainblack.com




Back to Top
Rate [
|
]
 
 
JT
Firstly, I suggest Wobjects be distributed as tarballs with the following structure:
  • /docs
    • changelog.txt, credits.txt, gotcha.txt, install.txt, legal.txt, license.txt (as per WebGUI distro itself)
    • collateral.wgpkg - most up-to-date exported package of your Wobject's importNode collateral folder
It should be more like /docs/Classname/  so that it doesn't mess with the normal webgui ones if someone extracts it right into the /data/WebGUI folder.

  • /upgrades
    • upgrade_x.x.x-x.x.y
    • upgrade_x.x.y-x.x.z, etc..

/upgrades/Classname here too
  • /lib -all of your custom Perl code, same directory structure as /data/WebGUI/lib
  • /script (optional) - utility scripts, e.g. a script to populate a site with demo Wobject data
  • /t - your Wobject's test suite
Just a note on Wobject collateral - older core Wobjects seem to use /data/WebGUIwww/extras/wobject to store static files. However newer Wobjects, and I feel the best practice for non-core Wobjects, is to store all collateral inside a single <WOBJECT> folder in the importNode. Static files includes files such as js, css, flash, images etc.. and also templates. This best practice should also be applied to your Wobject's asset image, which is normally stored in /data/WebGUI/www/extras/asset[/small]. To achieve this, you will need to override getIcon() in your Wobject. By doing this, it's easy to install or upgrade the latest version of your Wobject's collateral using the single /docs/collateral.wgpkg. As with core Wobjects, content managers should be encouraged to modify copies of templates rather than distributed templates, otherwise newer package releases will overwrite their changes.


I disagree. It should continue to be in /data/WebGUI/www/extras/wobject/Classname for static files. It's not as hard on the server loading them from here, plus they shouldn't be changed by an end user.
However, maybe we should move all the asset images into this folder instead of having one master folder for them all. 





I propose extending your installAsset.pl so that it performs the following steps:

I think I'm good with all the install things you mentioned. It would definitely be cool if we build a package structure with metadata so that we could load in custom plugins through the wre console.



JT Smithph: 703-286-2525 x810fx: 312-264-5382
Create like a god. Command like a king. Work like a slave.


Back to Top
Rate [
|
]
 
 
    



© 2012 Plain Black Corporation | All Rights Reserved