2013 10 gsrf - reference configurations management - draft (1)
-
Upload
tiago-carvalho -
Category
Documents
-
view
163 -
download
2
Transcript of 2013 10 gsrf - reference configurations management - draft (1)
GSRF Reference Configurations Management
Status Presentation – October 2013
M. Pecchioli, H. Dreihahn, T. Carvalho, HSO-GI
J.C. Berton, HSO-G
G. Di Girolamo, HSO-GD
Terminology (1/2)
– Ground Segment: the ‘control ground segment’ i.e. all ground systems under ESOC control that support the execution of spacecraft operations
– Unit: the smallest element of the ground segment that can be independently installed and configured (e.g. S2K, DARC, NIS)
– Subsystem: a coherent set of units running in the same environment and serving a well defined operational purpose (e.g. the MCS, the FDS, the G/S)
– Configuration: the set of items defining the behaviour of a given item (unit, interface or subsystem) at run-time, in addition to the system installation
– Configuration Item: any item (e.g. a file) contributing to the configuration
– Version: the unique identifier of a specific release of a given configuration item (e.g. a unit, a subsystem, a document, a configuration)
– Installation: the specific instance of a specific release of a given unit/subsystem, customised according to a specified configuration
Terminology (2/2)
– Integration: the process of assembling various units and subsystems together and exercising the interfaces between them
– Test Assembly: the definition of the various units or subsystems required to perform a specified set of validation operations
– Configuration control: the process of defining, documenting and managing all changes of configuration items
– Reference Configuration: a named set of configuration items determining the configuration of a unit, subsystem or test assembly
– Reference Installation: the installation of a specified set of units which exercises a given Reference configuration
– Configuration Baseline: a specific version of a Reference configuration which is proven to work in a relevant Reference installation and documented for future re-use
Background
– Infrastructure systems are not validated in sufficiently representative configurations
– Many problems with infrastructure systems are first detected by missions when exercising them in realistic operational environments
– Problems reported by missions cannot be easily reproduced and trouble-shooted in infrastructure systems
– In the GSRF, there is no coordination among the configurations adopted by various units/subsystems
– The deployment of Test Assemblies in realistic configurations currently implies a significant effort
– Lack of centralised configuration control of infrastructure (but also of mission) installations
The idea of Reference Configurations
Source Installation
DestinationInstallation
Capture Deploy
ConfigurationControl
Objectives of Reference Configurations
– Introduce control in the management of configuration items for Reference Installations (in the GSRF)
– Enable distribution/re-use of proven Configuration Baselines in multiple Reference Installations
– Simplify the deployment of Test Assemblies involving multiple units or even multiple subsystems
– Enable the adoption of mission configurations in infrastructure installations
– Rationalise/harmonise the procedures to maintain Configuration control across domains/subsystems
– Provide the missions with the capability to capture and trace the configuration of all Ground Segment units in a centralised repository
Reference Configurations management
– Tool suite enabling centralised management of configuration items (based on Mercurial)
– Generic scripts to capture/deploy Configuration Items driven by unit-specific XML based descriptors (defining the name and location of the configuration files):
• Organised in blocks for installation/configuration/operational files
• Name of a specific script to be executed
• List of items to be captured/deploy (with wildcards)
• List of items to be ignored
• List of folders to be created
– Support of automated push (distribution) of applicable Configurations to registered machines (one dedicated account/installation per machine)
– Capability to automatically adapt to the target installation environment
– Harmonised approach among units e.g. distinction between Installation, Configuration and Operational items
– Minimal set of actions to capture/deploy unit configurations
Reference Configurations management
Local File System
CentralisedRepository
Assemblies
Reference Configurations
Unit Configurations C_TMTCS C_GSTVi
<<Deployment Descriptor>>TMTCS
Configuration File
ST_TMTC
ST_TMTC_GAIA
Unit Configuration(at the example of TMTCS)
TMTCS Configuration File
<<Deployment Descriptor>>
TMTCS Configuration File
Generic Reference Configuration I/F
Unit Specific Configuration I/F
capture_configuration script
deploy_configuration script
Implementation Workflow
Central CCM
S2K
NIS
GSTVi
…
ccm.capture
S2K
NIS
GSTVi
…ccm.deploy
Scripts repoConfig reposccm
ccmccm
ccm
Capture executed from local ccm account.
Ops account are only read, no trace of ccm access
Capture executed from local deploy account.
Implementation Architecture
git
ccm.captureccm.deploy
s2k.captures2k.deploy
nis.capturenis.deploy
Descriptor file
…repoApi xmlParseApi
Capture/deploy wrapper *
* for automatic update of ccm scripts and descriptor files
Descriptor file
mercurial
Repository Organisation
RTE_repo
– One repository per Reference
Configuration
– Stored with original pathsS2K
NIS
GSTVi
DARC
…
GAI_repo
…
…
RTE_repo/ admin NIS/… DARC/…
Repository Management
– Tags are for incremental changes
– Branches for parallel snapshots of
not related views
reference
periodic
week1 week2 week3
working
myTest MarkTest optiTest
merge
…
Capture/Deploy Scripts
Capture
Deploy
ccm.capture-R <reference config>-T <type>-t <tag>-a <account>[-b <branch>]
GAI_repo
reference
periodic
week1 week2
working
myTest MarkTest
1.0
ccm.Deploy-R <reference config>-T <type>
Test Assemblies Infrastructure
Test Assemblies Missions
Next steps
– Implementation:
– Migrate from Mercurial to Git
– Finalise the definition of Capture/Deploy for all MICONYS units (DARC, EDDS, MATIS, SMF)
– Enable ‘sharing’ of Reference Configurations with GIMUS teams
– Support the capability to Capture/Deploy the Configuration Items for multiple units (e.g. all units involved in the “End-to-end TM/TC data flow” Test Assembly)
– Utilisation:
– Create Reference Configurations based on selected missions and deploy them on a MICONYS 6.1 Reference Installations (on-going for Gaia)
– Consolidate end-to-end process to transfer mission configurations into pure MICONYS installations
– Ensure consistent use of the centralised repository for GI Reference Installations
– Expand use to mission installations