Everything within this section is only visible while editing. Use Page Properties ID "STUB", "REFACTURE", "PROGRESS", "rDEV", "rDOC", "rLANG" and "DONE".

Everything contained within the table is displayed in the (INTERNAL) Reports page.

Product Version
Report Note
AssigneeAntje

Resources & Remarks


Modification History

Add a new line to this table and fill it whenever you edit the page.

NameDateProduct VersionAction
Antje Oelschlägel18 AUG 20212021 Autumncreated
Agnieszka Nowacki19 AUG 20212021 AutumnrLANG
Antje03 MAR 20222021 Winternew behavior: synchronization every 5 min
Agnieszka04 MAR 20222021 WinterrLANG



This core service manages profile-related and other configuration files using git as storage backend.

Characteristics


Service Nameconfigservice
Port Range7281
Profilesprod,cloud,native
Helm Chartyuuvis

Function

Most of the yuuvis® Momentum core services are configured via profiles and corresponding configuration files. Following the basic concepts of Spring Boot, the configuration files are stored on a git server and are managed via the CONFIGSERVICE.
>> Configuring Services using Profiles

The CONFIGSERVICE cannot start without an active connection to the git server.

At runtime, the CONFIGSERVICE applies all changes to configuration files to its local resources first. At regular intervals of 5 minutes, the remote resources on the git server are synchronized according to the following procedure:

This procedure of collecting and summarizing changes reduces the number of commits that have to be managed by the CONFIGSERVICE in case of a high frequency of change requests.

Additionally, it is possible to synchronize the local resources of the CONFIGSERVICE and the remote resources on the git server via the endpoint POST <host>:<port_of_configservice>/manage/refresh at any time. This synchronization is additional and independent of the automated synchronization every 5 minutes.
>> POST /{host}:{port}/manage/refresh

Note: In case multiple instances of the CONFIGSERVICE are running, the synchronization of the individual local resources is done at regular intervals of 5 minutes as well. Thus, requests for resources that have been modified less than 5 minutes ago might lead to the retrieval of a deprecated version of those resources. Resources created less than 5 minutes ago might be not available.

In the Kubernetes environment, each instance of the CONFIGSERVICE additionally stores the resources in a separate persistent volume at /tmp/configservice. In the default configuration, changes in those resources are used for the service initialization. I.e., changes that are not yet included in the commit are calculated via git diff and considered during the synchronization procedure described above.

Configuration

The CONFIGSERVICE can retrieve the cached version of configuration files even if the git is temporarily not accessible. Thus, during a downtime of the git server, GET requests to the CONFIGSERVICE will be successful whereas requests for storing resources will not be successful. The behavior is controlled via the boolean value of the the service-internal parameter fail-if-git-not-available in case the git server is temporarily not accessible.

Value for 'fail-if-git-not-available'Behavior of CONFIGSERVICE during temporary downtime of the git server
false (default)Retrieval of cached resource files during git server downtime is enabled.
trueAny request for a resource file via CONFIGSERVICE will return an error. 


Per default, the CONFIGSERVICE uses the persistent volume at /tmp/configservice for initialization during a restart. Alternatively, the CONFIGSERVICE can delete and recreate the directory /tmp/configservice by cloning the remote resources during the initialization. This behavior can be applied by one of the following configurations:

Read on


SYSTEM Service

 Keep reading


AUTHENTICATION Service

 Keep reading


Basic Use Case Flows

 Keep reading