NOTE: This description is in the early stage of being written

Assignment - Rewrite deploy based on settings overwrite

Action(print,Printer friendly version) TableOfContents

References

Reference documents

• ["Glossary"]

Dependencies

• All the tasks below need to be done in the order they are specified.
• all of the tasks is required to be done in the same iteration, although they can be implemented and tested in parallel with other developments.

Terminology

• ...

Bugs

...

Feature Requests

Basic idea behind new deploy

History of deploy

In the previous NetarchiveSuite there have already existed a deploy module. However this module had the following inconviniences:

• It was tightly connected to the setup of the Danish intallation of NetarchiveSuite

• It was based on a configuration file consisting of XML where the connection between configuration settings and NetarchiveSuite settings were far from obvious.

• It was based on the assumption that all settings had to be specified in a settings file for NetarchiveSuite

Now since the assumption of specified in a settings file for NetarchiveSuite is no longer valid becuse of resent changes. The NetarchiveSuite has now been changed to have in-build default settings where only local overwrites of defaults has to be set for the individual applications.

Furthermore, resent analysis and assignment description (assignment B2) for the archive has revealed the most obvious connections to the setup of the Danish intallation of NetarchiveSuite. This is mainly based on the interpretation of Location, which have both meant "location of bitarchive to be used" and "physical location of this instance of this application". As part of the assignment B2 as well as part of this assignment is a change of naming of the old location settings into distinc terms of physical location and replica. This change will mean that the new deploy no longer needs to be connected to the Danish intallation of NetarchiveSuite.

Lastly, the definitions in the new configuration file will in the new deploy be named precisely the same way as settings for NetarchiveSuite in cases where there are a direct connection. Only few definitions will be for deploy only, and in these cases the definitions will follow the naming convention of being prefixed with "deploy_".

Override settings structure

The idea is that the new deploy will be based on the default settings in NetarchiveSuite. A configuration file is then used for specifications of where the different applications are placed and which settings overrides is needed for the applications.

The default settings can be overwritten at different levels in the configuration settings file. this is illustrated in the below figure:

attachment:layers.gif

Documentation

Deployment Manual with reference to existing sections in Installation Manual

• Preparation
  • make it-config file
  • get netarchivesuite zip file
  • get and adjust configuration files
• deploy
  • how to
  • what is happening
• installation
  • how to (including modifications)
  • what is happening
• start and kill

Settings documentation should only consist in references to xml files in repository.

Questions

• Should we include creation of directories based om default settings?
• ...

New definition of IT-config

explation of settings overwrite structure and special deploy configuration settings (levels, install dir etc.)

Rewrite deploy

Reuse deploy code from kb-doms (Royal Library Digital Object Managemnt System code):

• machine definition class (for different os)
• hirarchy modules at machine and application level

Use follwing design:

• check input
• read minimum default settings that are needed for deploy (e.g. baseDirs)
• make physical location objects with from global level in it-config overwritten by specific physical location settings
• for each physical location
  • make machine objects specified for the location correspong to the mashine OS
  • overwrite/add settings for maschine
  • for each machine
    • make application objects specified for the machine
    • overwrite/add settings for application
• make consistency checks on known listed dependencies (e.g. bitarchives defined as common replicas)
• use methods on objects in hierarchy to produce various scripts