Open anmazzotti opened 10 months ago
I think we can safely port the elemental-operator
SeedImage
functionality.
The logic can be exactly the same, so building the image in a container (able to serve it through HTTPS) and have the Elemental API
reverse proxying to such container.
I think some security is also needed to prevent unwanted parties from downloading the images directly from the pods, for example by defining a network policy.
Anyway, as proposed above we can have a new endpoint: GET /elemental/v1/namespaces/{namespaceName}/registrations/{registrationName}/seedimages/{seedImageName}?type={seedImageType}
.
The seedImageType
can be used to select raw
or iso
, and we also have the option to add an architecture
query parameter, if we can re-use the same SeedImage resource for multi-arch builds.
The endpoint must be authenticated with the Registration token, can follow the same logic of the GET GET /elemental/v1/namespaces/{namespaceName}/registrations/{registrationName}
endpoint, by using the Registration-Authorization
header.
The goal of this task should be to be able to download images from the Elemental API directly. Supporting integration with Rancher web UI can be added later and most likely will involve supporting CORS.
This issue is about porting the image building functionality from the current elemental-operator.
Due to the absence of the Rancher API, this will slightly change and images are most likely going to be served under a new Elemental API endpoint, like:
/elemental/v1/namespaces/default/registrations/my-registration/image
.This endpoint should be authenticated as well. The registration token should be required when downloading the image. This may add complexity to the Rancher UI extension, but assuming the UI is able to fetch the full ElementalRegistration resource, then it can be parsed to extract the token.
Where do we want to keep the image build settings? Should this be a separate custom resource? Should we just add new config variables to the
ElementalRegistration
spec?