Skip to content

6593 improve usability of deploy new script - #7606

Open
ca61688 wants to merge 63 commits into
developfrom
6593-improve-usability-of-deploy-new-script
Open

6593 improve usability of deploy new script#7606
ca61688 wants to merge 63 commits into
developfrom
6593-improve-usability-of-deploy-new-script

Conversation

@ca61688

@ca61688 ca61688 commented Jul 6, 2026

Copy link
Copy Markdown
Collaborator

Make sure you have checked all steps below.

Issue

  • My PR fully resolves the following issues. I've referenced an issue in the PR title, for example "Issue 1234 - My
    Feature". Note that before an issue is finished, you can still make a pull request by raising a separate issue
    for your progress.

Tests

  • My PR adds the following tests based on our test strategy OR does not need testing for this extremely good reason:
    • Manual testing including quick system test suite run

Documentation

  • In case of new functionality, my PR adds documentation that describes how to use it, or I have linked to a
    separate issue for that below.
  • If I have added new Java code, I have added Javadoc that explains it following our conventions and style.
  • If I have added or removed any dependencies from the project, I have updated the NOTICES file.

@ca61688
ca61688 force-pushed the 6593-improve-usability-of-deploy-new-script branch from 227e99c to a1411a6 Compare July 7, 2026 08:03
@rtjd6554 rtjd6554 assigned patchwork01 and unassigned ca61688 Jul 29, 2026
void setUp() throws IOException {
createTempDirectory(tempDir, null);
instancePropertiesFile = tempDir.resolve("instance.properties");
Files.writeString(instancePropertiesFile, instanceProperties.saveAsString());

@patchwork01 patchwork01 Jul 31, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a lot more properties that are set in createTestInstanceProperties that won't be set in a file provided by the user. It's still using a simulated pre-deployed instance, when what we want is something a user would write. We expect a user will set as few properties as possible. I think we can start from new InstanceProperties()?

Here's a link to the original thread: #7606 (comment)

return builder().command(command).configurationDirectory(configurationDirectory).arguments(arguments).build();
}

public CdkCommand withNetworkConfiguration(String instanceId, String vpcId, String subnets) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This name seems slightly misleading, since the instance ID isn't part of the network configuration. I don't mind if you'd rather leave it as it is. Another option would be a toBuilder method.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving as is

String subnetIds = args[3];
Path instancePropertiesFile = optionalArgument(args, 4).map(Path::of).orElse(null);
boolean deployPaused = "true".equalsIgnoreCase(optionalArgument(args, 5).orElse("false"));
public DeployNewInstance(Builder builder) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By our coding conventions, the constructor should be the first method in the file, as it was before.

It looks like the constructor can be private.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Order corrected and constructor set to private

return config;
}

public static Arguments readArguments(CommandArguments arguments) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be nice to keep this function right next to the usage constant, because you'll want to check it agrees with that about the names of the parameters. I think loadConfiguration can be below this.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Order corrected

deployPaused = builder.deployPaused;
public DeployNewInstance(InstanceDeployer deployInstance,
StoreFactory storeFactory,
SleeperInstanceConfiguration deployInstanceConfiguration,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is easier to follow now, but I think it's still a bit confusing.

The InstanceProperties object is currently used as an intermediate data structure just to set the instance ID, VPC and subnets in the CdkCommand. I think that indirection is misleading, and I don't think there's a reason to mix that with the configuration from the files. Is it possible to build the CdkCommand directly from the Arguments object?

The InstanceProperties object is also used when we create the tables, but it's reloaded fresh from the deployed instance. I think it's confusing to reuse the same object for that, when it will contain very different data. We could use InstancePropertiesLoader instead of a reloadInstanceProperties.

That also means I don't think we need to load the whole configuration from the files, just the table properties. I think the only thing we're using the whole configuration for right now is to validate it, but the CDK will do that anyway.

There's also a tension with the original contract where DeployNewInstance is used elsewhere, because previously it was taking a DeployInstanceConfiguration and writing it to disk, but now it doesn't do that any more. We still need the callers to work. We can either just write it to disk if it was provided, or update the callers to write it to disk before they call this class.

Here's a link to the original thread: #7606 (comment)

config.getInstanceProperties().set(SUBNETS, subnets);
}

private DeployInstanceRequest buildExpectedCDKCommandWithPropertyFile(SleeperInstanceConfiguration config, boolean deployPaused) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is duplicating the implementation. Please make the asserted value explicit.

.build();
}

private DeployInstanceRequest buildExpectedCDKCommandWithConfigDir(SleeperInstanceConfiguration config, boolean deployPaused) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is duplicating the implementation. Please make the asserted value explicit.

assertThat(deployRequests.size()).isEqualTo(1);
DeployInstanceRequest lastDeployRequest = deployRequests.get(0);
assertThat(lastDeployRequest).usingRecursiveComparison()
.isEqualTo(buildExpectedCDKCommandWithPropertyFile(config, false));

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This two assertions can be one, with assertThat(...).containsExactly.

I don't think usingRecursiveComparison is necessary? CdkCommand is a record.

This also applies to the other tests.

@rtjd6554 rtjd6554 Aug 4, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed here and elsewhere in tests.
Equals and hashCode methods also required as part of change.

.storeFactory(StoreFactory.withAwsClients(s3Client, dynamoClient, accountName))
.deployInstanceConfiguration(config)
.cdkApp(SleeperInternalCdkApp.DEMONSTRATION)
.cdkApp(SleeperInternalCdkApp.STANDARD)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is setting the wrong CDK app.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed, back to demonstration

.deployInstanceConfiguration(config)
.cdkApp(SleeperInternalCdkApp.DEMONSTRATION)
.cdkApp(SleeperInternalCdkApp.STANDARD)
.configDir(configurationPath)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not correct. The code above is deriving the instance configuration from templates, but this is pointing to the original configuration file instead. I think this script still needs to write the files to a generated directory and point to that.

@patchwork01 patchwork01 assigned ca61688 and unassigned patchwork01 Jul 31, 2026

@patchwork01 patchwork01 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the demonstration deployment is broken right now, and I'm struggling to review the tests.

My comments on the use of DeployInstanceConfiguration and InstanceProperties in DeployNewInstance are less important, but it would be good to see some of that addressed.

@patchwork01 patchwork01 assigned rtjd6554 and unassigned ca61688 Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Improve usability of deployNew.sh

3 participants