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