You are currently browsing the category archive for the ‘Deployment’ category.
Nick Ager just published the instructions (and a screencast) for creating a free Micro EC2 instance for Seaside, Pier, and GLASS:
Amazon’s offer of a free micro instance for a year grabbed my attention:
[Updated: 1/4/2010] If you are interested, you should also check out the discussion on the Seaside list.
Photo by http://www.flickr.com/photos/chechipe/3821497127/ / CC BY NC ND 2.0
Not long after shipping the SOAP update for GLASS, I started working on Metacello. With the SOAP update, it became obvious that the GLASS ‘umbrella’ package was going to have to be replaced, and soon. Well, 7 months later I am reaching the point were I am finally ready to replace the GLASS package with a Metacello configuration .
I’m going to phase in the use of Metacello with GLASS. With the initial release, we’ll use Metacello for bootstrapping GLASS into a virgin extent. This way folks starting a greenfield project can use Seaside 2.8.4 or Pier 1.2 right away. Other releases that are in the pipeline:
- GemStone/S 64 2.4.x with partial continuations for Seaside3.0.
- Metacello configuration for bootstrapping Seaside 3.0 (ConfigurationOfSeaside30). A Squeak/Pharo version of this configuration is available now.
- final release of GLASS.230 package that will boot Metacello into an existing GLASS installation and allow for upgrading to GLASS 1.0-beta.0 and beyond.
GLASS 1.0-beta.0
ConfigurationOfGLASS version 1.0-beta.0 is based upon GLASS.230-dkh.231, with the following additions:
- Seaside 2.8.4
- Pier 1.2
- Metacello support
- VB-Regex loaded as part of ‘core’
- Scriptaculous updates from Ken Treis
- GemTools updates from Gerhard Obermann
- optional auto abort performed before commands
- add remove method (without any checks) renamed “remove method …” to “safe remove method …”
- add command “browse class history”
- add class history index to class browser title
- browse changes fixed … reversed comparison direction so that ”Install” will install repository version. the strike-out text is what is in current image.
- supports bootstrapping of code into virgin extent (see Bootstrapping Instructions).
Read the following sections to gain an understanding of the 1.0-beta configuration structure. If you are impatient and just want to load and go, then you can skip to the Bootstrapping Instructions.
1.0-beta Configuration Structure
With release 1.0-beta.0 there are 9 different loadable configurations defined in ConfigurationOfGLASS. If you read the code in the method ConfigurationOfGlass>>baseline10beta00:, you can see the Metacello specification summarized in the following sections.
Primary GLASS Projects
Any one (or combination) of the following projects and groups may be used as a load configuration for bootstrapping
Each of these projects is managed by it’s own ConfigurationOfxxx class.
- Core project. ConfigurationOfGsCore manages the Core, Base-Bootstrap, Bootstrap, GemStone-Exceptions (2.x only), GemStone-Indexing-Extensions, GsRandom, Sport, Squeak and VB-Regex packages. The Core packages are fundamental to the operation of GLASS and is always loaded.
- FastCGI project. ConfigurationOfGsFastCGI manages the FastCGIPool and FastCGI packages. The FastCGI packages are optional and are used to support FastCGI packages for Seaside2.8 and Seaside3.0.
- Hyper project. ConfigurationOfGsHyper manages the OpenSkills and Hyper packages. The Hyper packages are optional and are used to support the Hyper packages for Seaside2.8 and Seaside3.0.
- Magritte project. ConfigurationOfGsMagritte manages the Magritte-Model, Magritte-Tests and Magritte-Seaside packages. The Magritte packages are optional and represent the GemStone/S port of Magritte. By default only Magritte-Model and Magritte-Tests packages are loaded. To load Magritte-Seaside, it must be explicitly referenced.
- Metacello project. ConfigurationOfMetacello manages the Metacello packages and is imported from the Metacello project. By default the Metacello-Core, Metacello-MC and Metacello-Platform packages are loaded. The Metacello packages are fundamental to the operation of GLASS.
- Misc project. ConfigurationOfGsMisc manages the MockGemStone, SMTPMail, Utf8Encoding, Announcements, XML-Parser, SIXX, SmaCC, System-Digital-Signatures, and GemStone-Release-Support packages. The Misc packages are represent useful pieces of functionality that are contained in a single package and depend only upon the Core project. The Misc project is rarely loaded in it’s entirety. Typically individual packages are loaded from the project.
- Monticello project. ConfigurationOfGsMonticello manages the Change-Notification, PackageInfo-Base, and Monticello packages. The Monticello packages are fundamental to the operation of GLASS.
- OB project. ConfigurationOfGsOB manages the OmniBrower, OB-GemStone-Platfrom, OB-Monticello, OB-SUnitIntegration, OB-SUnitGUI, OB-Stanadard, OB-Tools and JadeServer packages. The OB packages are optional and provide the implementation for the GemTools.
- Pier project. ConfigurationOfGSPier manages the Pier-Model, Pier-Blog, Pier-DesignChooser, Pier-Design, Pier-Documents, Pier-EditorEnh, Pier-Google, Pier-Links, Pier-Randomizer, Pier-Slideshow, Pier-TagCloud, and Pier-Twitter packages. The Pier packages are optional and represent the GemStone/S port of Pier.
- Scaffolding project. ConfigurationOfGsScaffolding manages the GemStone-Scaffolding package. The Scaffolding packages are optional and representing the implementation of Scaffolding for GemStone. Even though this project consists of a single primary package, the fact that it depends upon Magritte and Scriptaculous warrants the creation of separate Metacello configuration.
- Seaside2.8 project. ConfigurationOfGsSeaside28 manages the Seaside2.8, SeasideAsync, Scriptaculous, RSRSS2, CallDemo, CheckboxExample, CSSDock, ErrorHandler, HelloWorld, ImageDemo, LogoutDemo, MarqueeDemo, menuDemo, ScreenResolution, Store, GemStone-Store, GemStone-Examples, FastCGISeaside and HyperSeaside packages. The Seaside2.8 packages are optional and represent the GemStone/S port of Seaside. By default only the Seaside2.8 pacakge is loaded. All of the other packages must be explicitly referenced.
- Seaside2.8 Testing project. ConfigurationOfGsSeasideTesting28 manages the SeasideTesting and PierTesting packages.
- SOAP project. ConfigurationOfGsSoap manages the SoXML, SOAP-CORE, SOAP-Client SOAP-Server, SOAP-Example and SOAP-TestCases packages. The SOAP packages are optional and represent the GemStone/S port of SoapCore.
Convenience GLASS Projects
- FastCGISeaside is a project based on a specialization of ConfigurationOfGsSeaside28 and references the FastCGISeaside package.
- HyperSeaside is a project based on a specialization of ConfigurationOfGsSeaside28 and references the HyperSeaside package.
- Metacello Tools is a project based on a specialization of ConfigurationOfMetacello and references the OB-Metacello package.
- Release Support is a project based on a specialization of ConfigurationOfGsMisc and references the GemStone-Release-Support package.
- Pier Testing is a project based on a specialization of ConfigurationOfGsPier and references the PierTesting package.
Groups
The following groups have been defined for the common load configurations.
- Dev group is made up of the Core, Monticello, Metacello, Release Support, OB and Metacello Tools projects.
- Magritte Dev group is made up of the Dev and Magritte projects.
- SOAP Dev group is made up of the Dev and SOAP projects.
- Seaside Dev group is made up of the Dev, Seaside2.8, FastCGISeaside and HyperSeaside projects.
- Seaside Testing Dev group is made up of the Seaside Dev, Seaside2.8 Testing projects.
- Scaffolding Dev group is made up of the Dev, Scaffolding, FastCGISeaside and HyperSeaside projects.
- Pier Dev group is made up of the Dev, Pier, FastCGISeaside and HyperSeaside projects.
- Pier Testing Dev group is made up of the Pier Dev and Pier Testing projects.
- ALL group is made up of all of the projects defined in ConfigurationOfGLASS.
As you become familiar with Metacello and the GLASS configurations, you can define your load configuration. although you probably want to become more familiar with Metacello first.
Bootstrapping Instructions
Please comment to this post or send mail to the GLASS Beta Mailing List if you have trouble or the instrcutions are not clear. The bootstrap should work for the appliance or any version of GemStone/S 2.3 or greater.
- Start a stone using a virgin extent copied from $GEMSTONE/bin/extent0.dbf into $GEMSTONE/seaside/data. Don’t forget to shut the stone down before copying extents around and don’t forget to make the extent writable using ‘chmod +w extent0.dbf’.
- Download and unzip bootstrap_1.0-beta.0.zip.
- cd to the bootstrap_1.0-beta.0 directory
- Edit the .topazini file to match your stone.
- Launch topaz: ‘topaz -l -T50000’
- ‘login’ and ‘input installMaster.topaz’
- Exit topaz. The ‘installMaster.topaz’ script installs the Dev Group which includes the GemTools.
- Launch a GemTools Client 1.0-beta.1 image and login.
- [Updated: later that day] Due to some bugs discovered in 1.0-beta.0, it is recommended that you update to 1.0-beta.1 by executing the following expression:
ConfigurationOfGLASS project updateProject. (ConfigurationOfGLASS project version: '1.0-beta.1') load: 'Dev'. System commitTransaction. - Choose a configuration to load by executing one of the following expressions:
(ConfigurationOfGLASS project version: '1.0-beta.1') load: 'Magritte Dev'. (ConfigurationOfGLASS project version: '1.0-beta.1') load: 'SOAP Dev'. (ConfigurationOfGLASS project version: '1.0-beta.1') load: 'Seaside Dev'. (ConfigurationOfGLASS project version: '1.0-beta.1') load: 'Seaside Testing Dev'. (ConfigurationOfGLASS project version: '1.0-beta.1') load: 'Scaffolding Dev'. (ConfigurationOfGLASS project version: '1.0-beta.1') load: 'Pier Dev'. (ConfigurationOfGLASS project version: '1.0-beta.1') load: 'Pier Testing Dev'. (ConfigurationOfGLASS project version: '1.0-beta.1') load: 'ALL'. - Make a backup and have fun!
—–
[1]http://www.flickr.com/photos/dawilson/ / CC BY-NC-ND 2.0
[Updated: 6/5/2010] For the latest documentation and information about Metacello, see the Metacello project pages.
Metacello is a package management system for Monticello. A package management system is…
A package management system provides a consistent method of installing software…
Last April I finally became fed up with the lack of a decent package management system for Monticello and decided to write my own from scratch. I wanted a package management system for Monticello that was consistent with the important features of Monticello:
- Declarative modeling. A Metacello project has named versions consisting of lists of explicit Monticello package versions. Dependencies are explicitly expressed in terms of named versions of required projects. A required project is a reference to another Metacello project.
- Distributed repositories. Metacello project metadata is represented as instance methods in a class therefore the Metacello project metadata is stored in a Monticello package. As a result, it is easy for distributed groups of developers to collaborate on ad hoc projects.
- Optimistic development. With Monticello-based packages, concurrent updates to the project metadata can be easily managed. Parallel versions of the metadata can be merged just like parallel versions of the code base itself.
Additionally, the following three points are important considerations for Metacello:
- Cross platform operation. Metacello must run on all platforms that support Monticello: currently Squeak, Pharo and GLASS.
- Conditional Monticello package loading. For projects that are expected to run on multiple platforms, it is essential that platform-specific Monticello packages can be conditionally loaded. At the moment, conditional loading is specified based upon the following attributes:
- #common. Code that is common across all platforms.
- #squeakCommon. Code that is common to Squeak and Pharo.
- #squeak. Code that is specific to Squeak.
- #pharo. Code that is specific to Pharo.
- #gemstone. Code that is specific to GemStone.
It should be possible to inject project-specific attributes, so code that is dependent upon attributes not covered by the standard list can be conditionally loaded. For example, in GLASS, different Monticello package versions are loaded based on which version of GemStone/S is running (i.e., version 2.0 versus 3.0).
- Compatible with MC2. It must be possible to manage Metacello projects that are based on alternate Distributed Source Code Management systems like Monticello2.
- MIT license.
[Update: 10/14/2009] Note that with the release of version 1.0-beta.3 of Metacello, some of the following sections are no longer valid . Please read this post for up-to-date information. The outright invalid entries have been struck out.
In the following sections I hope to give a taste of what Metacello can do along with instructions on loading Metacello into Squeak or Pharo, so you can run through the Metacello tutorial:
The VersionSpec
[Update: 10/14/2009] the following section is not completely accurate for the newer versions of Metacello (1.0-beta versions). Please see this discussion for up-to-date information.
Click on the image below to get a full depiction of a version spec.
The metadata for a Metacello project version is kept in a versionSpec which has the following atributes:
- blessing. A version can be tagged with a blessing like #alpha, #beta, #release, #development (or any other tag that is deemed useful). The blessing is used as a version filter. For example the latest version of a Metacello project is currently defined as the latest version whose blessing is not #development.
- description. Useful information about the version.
- packages. A list of Monticello package versions (or project references via required projects) that make up the project.
- repositories. A list of Monticello repositories from which the packages can be loaded.
- groups. An alias for a collection of packages. See Bootstrapping Metacello for some examples of using groups.
- doits. A collection of blocks associated with a Monticello package that are evaluated before and/or after a package is loaded.
- project package. A definition of the Monticello package name and Monticello repository from which the latest project metadata is be loaded.
- required projects. A list of projects that the Metacello project depends upon. A required project spec includes such information as the version of the project, the name of the Metacello project class, the package and repository from which the project metadata is loaded (note the similarity to the project package specification). Heres’ an example of a required project specification:
Any one of the versionSpec attributes may be conditionally modified. Here’s an example package specification that adds a new Monticello package version for the package ‘Example-Core’ when the #testPlatform attribute is present:
In the #common version spec, the package version ‘Example-Core-anon.14’ is associated with the ‘Example-Core’ package . When the #testPlatform attribute is present, ‘Example-Core.testplatform-anon.15’ overrides ‘Example-Core-anon.14’ in the version spec.
Metacello Tools
[Update: 10/14/2009] Note some of the entries in this section are invalid for later versions of Metacello. Please read this new section for more up-to-date information.
I have developed a minimal set of menu items for working with Metacello.
I started out thinking that I would completely avoid the tools issues and instead rely on workspace scripts, the Class Browser and Monticello Browser for the bulk of the tools support. Over time, I found a handful of operations that deserved to be easier to use, so I whipped up a handful of OB commands and attached them to the MetacelloProject class.
Select a MetacelloProject class and bring up the Class menu:
Save Packages
Finds the dirty Monticello packages that are members of the selected version of the Metacello project and saves them, prompting you for version name and commit comment. After the packages are saved you are prompted to Update Package Methods.
Update Package Methods
Automatically updates the package spec metadata for the selected version (i.e., modifies and compiles the methods with the #packages:attribute: pragma for the appropriate version to match the currently loaded Monticello package versions). After the methods are update you are prompted to Save Project.
Update Package Repositories
Updates the repository group for each Monitcello package associated with the selected version of the Metacello project to include the repository for that package as specified in the version spec.
[Update 8-26-2009 … more information, if not clearer explanation] When I use Metacello to bootstrap the GemStone Seaside extent, I have TrueRepositories turned off, because I am loading from a disk-based repository (using repositoryOverrides in the loader) so that we don’t _have_ to hit the http repository for every GemStone product build (and for folks using GLASS behind corporate firewalls that don’t have direct access to HTPP repositories). As a result the repositoryGroup is empty for each of the packages. This is a real pain when you start doing development.
‘Update Package Repositories’ scans every package and adds the project repository to the repositoryGroup for each package, so that one doesn’t have to manually do so.
Current Project Version
Displays the current version of the selected Metacello project. The version is calculated by comparing the currently loaded Monticello packages to those specified in the version spec. A leading ‘~’ means that the version is partially loaded (i.e., not all of the packages associated with the project have been loaded into the image).
Load Project Version
Prompts for the version of the selected Metacello project to be loaded. If there are groups associated with the selected version, you are prompted for the group that you would like loaded. When in doubt choose ‘ALL’.
Save Project
Saves the selected Metacello project to the repository specified by the project package of the selected version. You are prompted for version name and commit comment.
Update Project
Loads the latest Monticello package version from the repository specified in the project package of the selected version of the Metacello project. Remember that you are simply loading the Metacello project metadata, so it doesn’t hurt to have the latest metadata loaded. Once the latest version is loaded, you are prompted to Load Project Version.
GLASS Configuration
[Update: 10/14/2009] Note that the information is out-of-date in this section relative to newer versions of Metacello. Please see this post for more up-to-date information.
With Metacello, the configuration of the GLASS appliance goes from this incomprehensible (and pratically uneditable) list of packages:
to a manageable list of Metacello project references:
Best of all, it becomes possible to load a project like Pier into a minimal base image (with only Monticello, Metacllo and OB loaded) using something like the following expression:
(GsPierMetacelloProject version: '1.2') load: { 'Pier Core'. 'Pier AddOns'. }
Not only does Pier get loaded, but all of the projects that Pier depends upon (i.e., Magritte, Seaside, Scriptaculous, etc.) get loaded along with the projects that they depend upon.
For the curious, here are the definitions of the ‘Pier Core’ and ‘Pier AddOns’ groups:
Bootstrapping Metacello
[Update: 10/14/2009] Please see this new section for loading Metacello into an image.
To use Metacello in GLASS, modifications to some base classes are needed, so you will have to wait until I publish a GLASS package to bootstrap Metacello into GLASS.
To bootstrap Metacello into Squeak or Pharo:
- Load Metacello-All-dkh.10 from http://seaside.gemstone.com/ss/metacello (loads
Metacello-Core, Metacello-MC, MetacelloProject and OB-Metacello – note that
Metacello-All needs to have a fairly recent version of OB loaded. - Delete the Metacello-All package. It’s only needed to bootstrap Metacello.
- Execute the following expression in a workspace to load the latest version:
MetacelloMetacelloProject updateProject. MetacelloMetacelloProject latestVersion load.
The #updateProject method performs an Update Project to ensure that you have the most recent Metacello project metadata. The #latestVersion method finds the latest non-development version of Metacello (currently 0.15). The #load method then loads the ‘DEFAULT’ packages for the latest version.
The ‘DEFAULT’ group specifies the bare minimum of packages needed to use Metacello (‘Metacello-Core’, ‘Metacello-MC’, ‘Metacello-Platform’, and ‘OB-Metacello’).
The ‘Tests’ group specifies the unit test packages for Metacello.
The ‘Samples’ group specifies the package containing some sample Metacello projects including samples for Seaside2.8 and Seaside2.9.
The ‘Tutorial’ group specifies the package containing the Metacello tutorial.
To load the whole Metacello enchilada, you’d execute the following expression:
MetacelloMetacelloProject updateProject.
MetacelloMetacelloProject latestVersion load: 'ALL'.
Tutorial
[Update: 10/14/2009] Please see this new section for loading the Metacello tutorial into an image.
The tutorial covers all of the important Metacello features in some detail. To load the tutorial, execute the following expression:
MetacelloMetacelloProject updateProject.
MetacelloMetacelloProject latestVersion load: 'Tutorial'.
Then open two class browsers on the MetacelloTutorialProject class. In the left hand browser view the methods in the ‘lessons’ category. In the right hand browser view the ‘–all–‘ category. Read the comments in lesson01 through lesson16OtherExamples.
Current Status
[Update: 10/14/2009] Please see this new section for the current status of the Metacello project.
Version 0.15, the curent version of Metacello, is feature complete, but I’m chasing down infant mortality bugs while I am creating the Metacello projects for GLASS. Once I’m happy, I will release a beta version of Metacello along with the final GLASS package which will boot Metacello into GLASS.
A Metacello Users Guide is also in the works and should be available soon.
—–
[1]Photo by kruemi (Creative Commons).
Andreas Brodbeck has announced Seashell:
Coming from the Rails world, I clearly see that there is yet missing some proven best practices for the hosting of a Gemstone powered seaside application server. Progress on GemTools is moving fast, that’s super fantastic! And I always felt that there should be a bare access to the deployment, a more basic direct access from the shell, too.
In the world of Rails there is a solid tool called capistrano, which you can use as a deployment servant.
Andreas makes a good point, the production deployment and stone management tools for GLASS leave a lot to be desired. Just ask Danie Roux. Not long ago, he blogged about using Rake to manage multiple GemStone database instances.
I haven’t had a chance to look at either of these tools in detail, but I am glad that the community is stepping in to fill a void.
BTW, there are github repositories for both tool sets: Seashell and GemStone Management scripts.
—–
[1] Photo by florriebassingbourn (Creative Commons).
(gem)Stone Soup 