[WIP] Draft proposal for new image tomls#16184
[WIP] Draft proposal for new image tomls#16184realsdx wants to merge 3 commits intotomls/base/mainfrom
Conversation
realsdx
force-pushed
the
sudipta/image-delivery-tomls-poc
branch
from
32b5986 to
4df7dfd
Compare
| @@ -0,0 +1,4 @@ | |||
| [images.container-base] | |||
| description = "Container Base Image" | |||
| distro = "azurelinux" | |||
There was a problem hiding this comment.
we needed the distro metadata cause in future we want to support other distros like flatcar. If this is not good place we can remove, currently not used.
| @@ -0,0 +1,29 @@ | |||
| [images.vm-base] | |||
| description = "VM Base Image" | |||
| distro = "azurelinux" | |||
There was a problem hiding this comment.
Ditto regarding distro as well.
| version = "*" | ||
|
|
||
| [images.vm-base.delivery.vhd] | ||
| vhd_path = "*" |
There was a problem hiding this comment.
What's the * for? What does this mean?
There was a problem hiding this comment.
* means value is not hardcoded will be determined at runtime, as this will be a blob url with sas token.
| [images.vm-base.delivery.vhd] | ||
| vhd_path = "*" | ||
|
|
||
| [images.vm-base.delivery.shared_gallery] |
There was a problem hiding this comment.
I've also been working on drafting what publishing info looks like. Since these are going to need to look different across branches of the product, we're going to need to place that in the distro TOMLs.
Consider something like this:
[distros.azurelinux.versions.azl4-dev-stage1.outputs]
source-lookaside-caches = ["azl4-dev-lookaside-cache"]
package-repos = ["azl4-alpha1-rpms-base"]
image-stores = ["azl4-alpha1-acr", "azl4-alpha1-acg"]
[[resources.alpha1-acg]]
publish-labels = ["base-vm"]
interface-type = "azure-compute-gallery"
backend = "azure-compute-gallery"
resource-urn = "/subscriptions/e4ab81f8-030f-4593-a8f2-3ea2c7630a19/resourceGroups/azl-preview-publishing/providers/Microsoft.Compute/galleries/azlpubStagingGalleryoxz2o4gw"
images = [
{ name = "AzureLinuxAlpha1-x64", arch = "x86_64" },
{ name = "AzureLinuxAlpha1-arm64", arch = "aarch64" }
]The image itself just needs to indicate that it should be published to any targets with the base-vm label.
What do you think?
There was a problem hiding this comment.
So, a separate toml with all publishing info? what are image stores? what is backend here?
There was a problem hiding this comment.
I was thinking from a perspective of test/image owners, having the image definition and its related delivery/publishing methods at the same place would help with code/config locality IMO, what do you think?
|
|
||
| [images.vm-base.variants] | ||
| architectures = [ | ||
| "amd64", |
There was a problem hiding this comment.
Minor note: we should use x86_64 and aarch64 as the standard arch names.
| "amd64", | ||
| "arm64", | ||
| ] | ||
| hyperv_generations = [ |
There was a problem hiding this comment.
I'd expect gen1 and gen2 to be different kiwi image profiles. How would you anticipate this metadata be used? What's the reasons for/against the gen1 vs. gen2 images just being modeled as different images?
There was a problem hiding this comment.
If gen1/gen2 have different kiwi files, we need create different tomls for them in this model with only one gen hardcoded in it
| distro = "azurelinux" | ||
| definition = { type = "kiwi", path = "vm-base.kiwi" } | ||
|
|
||
| [images.vm-base.delivery.marketplace] |
There was a problem hiding this comment.
See below; for any publishing targets that need to be branch-differentiated/specific, the metadata needs to be split: some branch-specific distro metadata around publishing targets, and some per-artifact identification of which artifacts should be published.
2 participants
This PR proposes extending Azure Linux image definitions with delivery metadata so they can be consumed by TEE.
As part of that,
images.tomlis changed to a thin include based registry and image definitions are moved into per-image*.image.tomlfiles alongside their KIWI definitions. The new manifest shape introduces fields such as name, distro, delivery, and variants so image delivery mechanisms and constraints can be defined closer to the image itself.Scope: Introduce image delivery definitions
*means this field is intentionally unresolved in the manifest and must be filled in by a later delivery, publish, or fulfillment step. The key is still declared here so downstream tooling knows the field exists and can provide or validate it.Note: It has not been verified with azldev. Runtime support in azldev is still needed for the new image fields.