console patching requirements
emuckenhuber Jul 5, 2010 9:38 AMIn a different thread we had a discussion about the InstalledImage, where especially the requirements for patching were unclear. Here a few points we gathered from a discussion with the console team.
1) AS to fully support applying patches, e.g.
- easily updating jars without needing to delete/backup the old ones
As mentioned in a different thread, we could simply have overlay directories and having the core module system taking care of using the correct libraries.
In general we currently have - the actual release and the cumulative patches against the original version (as far as i understood that) and one off patches against the actual modules. Where if a CP is a diff zip against the original version, it's mostly an unzip operation into a separate overlay directory per CP version. For one off patches there should most likely be just one directory, in case one-off patches are against a specific module version it is valid as long as there is no newer version of the module.
Although the question is if it should be possibility to rollback arbitrary one-off patches or if we can simply rollback to the CP? Which could only mean removing the one-off patch?
This could also work for having the repository shared across domains, where we would need to also maintain the version a server is running on - but we might need to do that in general?
Additionally what about patching things like "client/", "docs/", "examples/"? I guess this should not be versioned anyway, so a rollback would be harder and we might not need that for docs/ and examples/. For the client i'm not sure, maybe we can use the class-path element in the manifest to point to the actual .jars and have the module system to export that as well? - easily update configuration settings
Updating configuration settings should be easier with the domain model in general. Where i see basically 2 use cases:- patching default values:
Since default values are going to be separate from the actual configuration, this should be coved by a normal module repository update. - patching the actual domain configuration values:
Where the question is if we need this is a patch, or if this is more something like a reference for management clients to check whether components would need to be updated. Since it most likely will require a user interaction.
- patching default values:
2) A client for applying patches to AS
The "client" for applying a patch would be the SM? However it most likely should also exist at the domain model level, otherwise this means that there would need to be a jon agent per host?