Closed matofeder closed 8 months ago
The ideal case is that the node images are part of the cluster stack and their build information provided in the node-images/ folder of the cluster stack configuration. Then the csctl can handle this flow natively and would set the appropriate node image version in e.g. the metadata.yaml file. Then CSPO can read this and find the images appropriately.
All other solutions would go against the idea of cluster stacks that node images are part of them (de facto they are not for the current OpenStack ones right now)
The ideal case is that the node images are part of the cluster stack and their build information provided in the node-images/ folder of the cluster stack configuration. Then the csctl can handle this flow natively and would set the appropriate node image version in e.g. the metadata.yaml file. Then CSPO can read this and find the images appropriately.
All other solutions would go against the idea of cluster stacks that node images are part of them (de facto they are not for the current OpenStack ones right now)
Based on our internal discussion, we want to filter node images similarly to CAPO. That means if ID
of the image is specified in node-images.yaml
at openStackNodeImages.createOpts.id
we will filter the image by its ID(e.g. this can be useful when the user has already uploaded an image and has several images with the same name).
When ID
is not specified, we want to filter by image name and tag. We also do not want to add custom tags using the CSPO. As the node-images are provider specific and we talked about the openstack plugin for the csctl
. This plugin could also add node image version into the node-images.yaml
file.
I'm not 100% understanding this use case. We can maybe discuss this in the Hackathon? This is also what I discussed with @jschoone just now
I'm not 100% understanding this use case. We can maybe discuss this in the Hackathon? This is also what I discussed with @jschoone just now
The use case is that in OpenStack you can have two node images with the same name but with different specifications. In the latest release CAPO version v0.9.0
if this case happens it fails(filtering is done only by the name of the image). But in the main
branch(not released yet), they add filtering images by their image-name and tags, which currently solves this issue if images have different tags. We want to just implement a similar approach.
Sure, we can discuss this use case at the Hackathon as well.
Hi @michal-gubricky and @matofeder, I think it's a good idea to use the approach of filtering by tags, because I also think it makes sense to offer similar experience for users who come from CAPO environments and are interested in Cluster Stacks.
As @janiskemper said we discussed this this morning and talked about the csctl
provider plugin which should also be (at least) discussed at the KaaS Hackathon. Then we can cover both approaches.
/kind feature
Current state
OpenStackNodeImageRelease controller filters images based on their names only.
Background :
OpenStackNodeImageRelease resource name is composed as follows:
release tag without version
-image name
-node-image-version
(e.g.:openstack-ferrol-1-27-ubuntu-capi-image-v1.27.8-v2
). When the OpenStackNodeImageRelease resource is created, the controller will search for the node image in the OpenStack project based on itsimage name
only. If the OpenStack project does not contain a node image with the given image name, then the image is imported.If the ClusterStack version is changed (e.g., the addon version has been updated), it is expected that the node image could be reused. This ensures that multiple versions of one ClusterStack can share one node image.
An issue could occur when the
node-image-version
is changed as well, e.g., some image create-options are changed, but theimage name
remains the same. In this case, the controller finds the givenimage name
in the OpenStack project and does not import the new version of the image. This causes an inconsistent state because the node image in the OpenStack project was not created with the desired create-options and we end with one imported image and two OpenStackNodeImageRelease resources (two node-image-versions).Desired state
OpenStackNodeImageRelease controller filters images based on their names and tags.
We should allow the creation of multiple images with the same name in the OpenStack project and distinguish them by unique tags. Consequently, one ClusterStack, across multiple versions and importantly with multiple node-image-versions, could use the same image name. Therefore, the creator of the ClusterStack does not need to introduce a unique node-image name when the node-image-version is changed. However, the creator of the ClusterStack should ensure that the unique tag (node-image-version) is passed to the CAPO resources.
CAPO
The latest released version of Cluster API OpenStack Provider
v1alpha7
does not support image tag filtering.In Cluster API OpenStack Provider
v1beta1
(not released yet) the node image could be filtered based on its ID or based on a combination of name, and tags (see here). The combination of name and tags must return a single matching image. Filtering by tags is new and allows to have images with the same name, that should be recognized by tags.