EKS bulk import in combined CDK app via SleeperArtefacts
- Dominant language
- Java
- Stars
- 107
- Forks
- 29
- Avg merge
- 19h 46m
- Merged PRs (30d)
- 141
Description
### Description / Background
For a custom CDK app, we expect the user to be able to implement SleeperArtefacts themselves and have those artefacts used everywhere in a deployment of Sleeper. We have a CDK app in an external repository that does this.
This does not currently work for bulk import on EKS, as it computes the image name with `DockerDeployment.EKS_BULK_IMPORT.getDockerImageName`.
We'd like to retrieve the image name through SleeperInstanceArtefacts instead.
### Acceptance Criteria
**Given** I create a custom CDK app
**And** I implement SleeperArtefacts myself
**And** I define a SleeperInstance in my CDK app using those artefacts
**When** I deploy my CDK app with EksBulkImportStack enabled
**Then** bulk import jobs running on EKS use my Docker images
### Technical Notes / Implementation Details
We can add a new method to SleeperContainerImages to retrieve an image name directly based on a DockerDeployment.
We then need to use this in EksBulkImportStack.
We probably need to update our custom CDK app in the external repository to use this.
Contributor guide
Research direction
Start by reading SleeperContainerImages and EksBulkImportStack, tracing where DockerDeployment.EKS_BULK_IMPORT.getDockerImageName is used. Check how SleeperInstanceArtefacts supplies images, then update the bulk import path so EKS jobs use the custom Docker images defined by the CDK app. Done means the stated custom-app deployment scenario uses those images.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, docker, java, kubernetes
- Domain
- cloud, infrastructure
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 76/100