Patches and AS 7

Background / Introduction to AS 7

• AS 7 offers 2 startup modes, standalone and domain.
• Standalone is just the App Server instance.
• Domain starts a Process Controller, a Host Controller, and App Server instances.
• The Process Controller is very lightweight and should remain up for long periods of time.
  The Process Controller can re-start Host Controllers and App Server instances, it should be so simple that it doesn't ever need to be restarted itself.
• The Host Controller dictates whether this node is a domain 'Master' or 'Slave'. 
• There may be many App Servers. 

Configuration files

• Domain.xml - should be identical on all machines across the domain, but is read only by the single node acting as 'Domain Controller'.
• Host.xml - Unique for each host, this file tells this host if it's the Domain Controller or not.

Startup (Domain mode)

• domain.sh starts the Process Controller.
• Process Controller launches Host Controller.  (Might be Domain Controller, might not be).
• Host Controller, with Domain Controller, manage App Server lifecycles.
• The subdirectory /data/content is a working copy of deployed stuff.
• Note:  Domain mode does not currently support exploded directories for deployments.

Application Server

• To the app server, all the components are 'services'.
• A Service has two statuses, 'up' and 'down'.
• There is a subsystem API if you want to extend the capabilities of the application server.
• The Getting Started Guide describes several examples included in the source version of AS 7.  These examples show how the App Server's management API can be used to deploy components.  When a component is deployed, it causes the current Application Server configuration file (i.e. standalone.xml) to be re-written on the fly.
• The App Server is made up of a core and extensions.  The core contains parts like MSC (the service container), module class loading, and core management.  The rest are extensions.

Patching

We seek to make patching:

• Easy to produce
• Easy to audit
• Easy to test
• Easy to deploy
• Easy to roll back (perhaps.  Under discussion)
• Easy to view/understand the patches applied.
• We'd like to establish a patch directory, maybe under 'modules'.  This patch directory would have a sub-directory for each CP or patch that is applied.
• For this to work, we must produce a Patch-tool that will alter the path used to invoke modules.  It must update the path used find classes and put the latest patch's .jars ahead of what was there previously.  (The prior .jars may need to be removed, per security requirements.  This is under discussion.)
• Patching a domain is more challenging than patching a single App Server instance, as it might involve patching several hosts and app server instances.  A few interesting notes:
  • Only a domain controller can 'push' changes out.
  • The domain controller's modules must be at least as current as the latest version on subordinate nodes.

The Patch-tool must use the Application Server's management API to deploy patches.  We need to provide some scripting mechanism which will cause it to distribute the artifacts (perhaps to the above described directory structure for patches) and to cause updates to configuration files.

A possible patch-application scenario

1)  The Patch-tool talks to the Master Domain Controller, asking it for a list of subordinate hosts.
2)  The Patch-tool updates the modules on the MDC with the new artifacts.  This is because the MDC must be at least as current as the newest host.  The MDC is restarted. Repeat Loop for each Host:
3)  Patch-tool prompts the Host to reconnect to the MDC, because it has been bounced.
4)  Patch-tool puts the new modules in place on the Host, restarts the Host.
5)  The Patch-tool translates the configuration DSL into changes:
    - Domain level changes
    - Host level changes (1 per Host, so the Patch-tool can command Hosts to update, as was done in the loop above)