Annotation: Describes how to upgrade a distributed system that is specified in Conic, i.e., as a set of modules and connections between them. Messages between modules may be one-way (asynchronous) or request-response (RPC-like). Upgrades are specified as declarative change commands (link, unlink, create, delete, etc); a Configuration Manager (CM) translates these into operating system commands and executes them. Declarative commands allow the CM to select the best ``change strategy,'' e.g., to minimize downtime (cf. upgrade schedule). The CM checks that any changes obey module interface type signatures. The upgrader must specify change commands directly; the system does not attempt to infer change commands from before and after versions of the configuration (e.g., Hicks, 2001 and Tewksbury, 2001). The CM itself is specified in Conic, but is not upgradable. System does not quiesce modules, and so cannot guarantee state consistency. System does not support state transfer or translation between versions. System does not provide atomic upgrades, i.e., an upgrade may fail and leave the system in an inconsistent state.
BibTeX entry:
@article{kramer85dynamic, author = {J. Kramer and J. Magee}, title = {Dynamic Configuration for Distributed Systems}, journal = {{IEEE} Transactions on Software Engineering}, volume = {11}, number = {4}, pages = {424--436}, month = apr, year = {1985} }
Sameer Ajmani