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
2. 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
3. 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
4. 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
5. The idea of Reference Configurations
Source
Installation
Destination
Installation
Capture Deploy
Configuration
Control
6. 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
7. 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
8. Reference Configurations management
Centralised
Repository
Local File System
Assemblies
Reference Configurations
Unit Configurations C_TMTCS C_GSTVi
<<Deployment
TMTCS Descriptor>>
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
capture_configuration script
Unit Specific Configuration I/F
deploy_configuration script
9. Implementation Workflow
Central
CCM
S2K
NIS
GSTVi
…
ccm.capture
S2K
NIS
GSTVi
…
ccm.deploy
Scripts repo
ccm Config repos
ccm
ccm
ccm
Capture executed from
local ccm account.
Ops account are only
read, no trace of ccm
access
Capture executed from
local deploy account.
11. Repository Organisation
RTE_repo
– One repository per Reference
Configuration
– Stored with original paths
S2K
NIS
GSTVi
DARC
…
GAI_repo
…
…
RTE_repo/
admin
NIS/…
DARC/…
12. 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
…
16. 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
