gchq / gchq/sleeper

Prevent accidentally switching a Sleeper instance between a local built version and a pre-published version

Open
#8,183 0 comments 0 reactions 0 assignees View on GitHub
cdk-module clients-module enhancement
Dominant language
Java
Stars
107
Forks
29
Avg merge
19h 46m
Merged PRs (30d)
141

Description

### User Story

As a user of Sleeper, I want a CDK deployment of Sleeper to fail if it was deployed with a pre-published version and I'm running a locally built version, so that I don't accidentally replace an instance with one built in a different way.

### Description / Background

We'd like to ensure that if a Sleeper instance was deployed from a pre-published version, it should refuse being re-deployed from a locally built version, unless this is forced.

### Technical Notes / Implementation Details

The configuration for whether to deploy a locally built or pre-published version is in DeployConfiguration.

We can introduce a CDK-defined instance property to state whether the artefacts have been built locally or retrieved from a repository. We can set that based on a CDK context variable, which can be set by the deployNew.sh and deployExisting.sh scripts.

We can check this in two places:
- The deployExisting.sh script (DeployExistingInstance class)
- The uploadArtefacts.sh script (UploadArtefacts class)

#### Setting the CDK-defined instance property

We can create a CDK-defined property and set it in SleeperInstanceProps, similar to how `sleeper.cdk.app` is set.

This can be an enum property based on DockerImageLocation. We can move that enum to the core module.

#### Setting the CDK context variable

The deployNew.sh and deployExisting.sh scripts both set the CDK context variables against the CdkCommand that is passed to DeployConfiguration in a DeployInstanceRequest.

Both of these already read the deployment configuration with `DeployConfiguration.fromScriptsDirectory`, but this is currently done inside a factory method for DeployInstance. We may need to adjust that wiring.

#### Checking the instance property matches

The deployExisting.sh and uploadArtefacts.sh scripts both load DeployConfiguration indirectly. We may need to adjust that wiring.

In uploadArtefacts.sh we'll only be able to do this check if the instance properties are loaded.

The check can be an equality check on a DockerImageLocation.

Both of these scripts will need new options to force deployment even if the artefacts source does not match.

Contributor guide

Open the contributing guide

Research direction

Start with DeployConfiguration, SleeperInstanceProps, and the DeployInstanceRequest wiring, then trace deployNew.sh and deployExisting.sh through DeployExistingInstance. Review uploadArtefacts.sh and UploadArtefacts to see how instance properties are loaded. Done means deployments reject mismatched local and pre-published artefact sources, while both scripts provide a force option to bypass the check.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, shell
Domain
cloud, devops, infrastructure
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.