Automate production of CAPI VM images

[vomba]

Change description

• Is this change including a new Provider or a new OS? (y/n) ____
• If yes, has the Provider/OS matrix been updated in the readme? (y/n) ____
• If adding a new provider, are you a representative of that provider? (y/n) ____

Related issues

• Fixes #

Additional context

[elastisys-staffan]

Nice work! 🎉 This doesn't actually push or publish the artifact anywhere right?

[vomba]

Nice work! 🎉 This doesn't actually push or publish the artifact anywhere right?

The openstack part now, azure does, since it creates a VM on there and all (it's the default behaviour).

[HaoruiPeng]

Good job!
But I have a question concerning Openstack.
What would the the follow-up steps after the image is created? The workflow stops here, I assume that means the image is gone when the runner is destroyed if you don't upload it anywhere.

Does it make sense to upload the image to the dev projects of all our Openstack infra providers? So we can share the images to production projects from there during maintenance.

Another idea is to have a self-hosted runner that does not get destroyed after the actions finish.

[vomba]

Good job! But I have a question concerning Openstack. What would the the follow-up steps after the image is created? The workflow stops here, I assume that means the image is gone when the runner is destroyed if you don't upload it anywhere.

Does it make sense to upload the image to the dev projects of all our Openstack infra providers? So we can share the images to production projects from there during maintenance.

Another idea is to have a self-hosted runner that does not get destroyed after the actions finish.

We will need credentials to upload and share the openStack images, that part is on hold until a decision is made about it.

[elastisys-staffan]

Apologies for not being able to look at this sooner. Do you think we could break the jobs up so that building is one job and publishing is another? The logs are quite long so that would make it easier to follow the process. Also, I think it would add some flexibility.

[vomba]

Apologies for not being able to look at this sooner. Do you think we could break the jobs up so that building is one job and publishing is another? The logs are quite long so that would make it easier to follow the process. Also, I think it would add some flexibility.

That can be done for openStack. Once we decide on how to handle the credentials.
For Azure, there is no publishing job. as it builds on the platform and stores it there by default.

[elastisys-staffan]

Apologies for not being able to look at this sooner. Do you think we could break the jobs up so that building is one job and publishing is another? The logs are quite long so that would make it easier to follow the process. Also, I think it would add some flexibility.

That can be done for openStack. Once we decide on how to handle the credentials. For Azure, there is no publishing job. as it builds on the platform and stores it there by default.

Would it make sense to use qemu or similar to build the Azure VHD locally and then publish it in a separate job? As I understand it that is how the Openstack flow works, so if we can make it work for Azure too they would harmonize nicely.

[vomba]

Apologies for not being able to look at this sooner. Do you think we could break the jobs up so that building is one job and publishing is another? The logs are quite long so that would make it easier to follow the process. Also, I think it would add some flexibility.

That can be done for openStack. Once we decide on how to handle the credentials. For Azure, there is no publishing job. as it builds on the platform and stores it there by default.

Would it make sense to use qemu or similar to build the Azure VHD locally and then publish it in a separate job? As I understand it that is how the Openstack flow works, so if we can make it work for Azure too they would harmonize nicely.

I don't know actually, but it feels like adding more work to us.

[elastisys-staffan]

I don't know actually, but it feels like adding more work to us.

It might be worth the effort actually.

I see several benefits:

• increased consistency across provider implementations
• breaking up build and push/publish = separation of concerns
• separate push step gives us more flexibility to work out the authentication details
• if the azure image is identical to the openstack image, we might only need to build a single image (that's a big IF, but would be neat)

Imagine we build the images here and push them to object storage or similar. Then, pushing and publishing them can be tied to some other process, like creating a capi release. We could even keep the step manual if we want to.

[Xartos]

I don't know actually, but it feels like adding more work to us.

It might be worth the effort actually.

I see several benefits:

* increased consistency across provider implementations

* breaking up build and push/publish = separation of concerns

* separate push step gives us more flexibility to work out the authentication details

* if the azure image is identical to the openstack image, we might only need to build a single image (that's a big IF, but would be neat)

Imagine we build the images here and push them to object storage or similar. Then, pushing and publishing them can be tied to some other process, like creating a capi release. We could even keep the step manual if we want to.

I like this, and we could add it as artifacts of the action. Then some other job could just download the images as the output of this action and push it wherever it needs