-
Notifications
You must be signed in to change notification settings - Fork 614
[WIP] Draft proposal for new image tomls #16184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: tomls/base/main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| [components.moby-engine.vm-tests] | ||
| test_lables = ["container"] | ||
| testcase_names = [ | ||
| "verify_docker_compose_wordpress_app", | ||
| "verify_docker_dotnet31_app", | ||
| "verify_docker_dotnet50_app", | ||
| "verify_docker_java_app", | ||
| "verify_docker_python_app", | ||
| "verify_docker_seccomp_profile" | ||
| ] | ||
|
|
||
| [components.containerd.vm-tests] | ||
| test_lables = ["container"] | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| <!-- FOR DRAFT REFERENCE ONLY --> | ||
|
|
||
| # Images | ||
|
|
||
| `images.toml` is the registry entry point for image manifests and should stay thin. | ||
| Each image directory owns its own `*.image.toml` manifest alongside the build definition (for example, a `.kiwi` file). | ||
|
|
||
| These per-image manifests now carry both azldev build registration and image metadata consumed by downstream tooling such as TEE. | ||
| The schema in `external/schemas/azldev.schema.json` has been extended accordingly, but azldev runtime support still needs to be implemented in the tool codebase. | ||
|
|
||
| # Notes | ||
| - 'distro` is a required field in the image manifest, but it is not used by azldev at this time. It is intended for use by downstream tooling such as TEE to categorize images by their base distribution. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,4 @@ | ||
| [images.container-base] | ||
| description = "Container Base Image" | ||
| distro = "azurelinux" | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we needed the distro metadata cause in future we want to support other distros like |
||
| definition = { type = "kiwi", path = "container-base.kiwi" } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,16 +1 @@ | ||
| [images.vm-base] | ||
| description = "VM Base Image" | ||
| definition = { type = "kiwi", path = "vm-base/vm-base.kiwi" } | ||
|
|
||
| [images.container-base] | ||
| description = "Container Base Image" | ||
| definition = { type = "kiwi", path = "container-base/container-base.kiwi" } | ||
|
|
||
| # NOTE: | ||
| # sudo dnf install -y kiwi-cli | ||
| # sudo kiwi --loglevel 10 \ | ||
| # --kiwi-file container-base.kiwi \ | ||
| # system build \ | ||
| # --description ./container-base \ | ||
| # --target-dir <output_dir> \ | ||
| # --add-repo='file:///home/username/some/dir/with/private/rpms,rpm-md,azl,1 | ||
| includes = ["**/*.image.toml"] |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| [images.vm-base] | ||
| description = "VM Base Image" | ||
| distro = "azurelinux" | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ditto regarding |
||
| definition = { type = "kiwi", path = "vm-base.kiwi" } | ||
|
|
||
| [images.vm-base.delivery.marketplace] | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
| publisher = "MicrosoftCBLMariner" | ||
| offer = "azure-linux-4" | ||
| sku_prefix = "azure-linux-4" | ||
| version = "*" | ||
|
|
||
| [images.vm-base.delivery.vhd] | ||
| vhd_path = "*" | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
|
||
| [images.vm-base.delivery.shared_gallery] | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 What do you think?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, a separate toml with all publishing info? what are image stores? what is
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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? |
||
| subscription_id = "*" | ||
| resource_group_name = "*" | ||
| image_gallery = "*" | ||
| image_definition = "*" | ||
| image_version = "*" | ||
|
|
||
| [images.vm-base.variants] | ||
| architectures = [ | ||
| "amd64", | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Minor note: we should use x86_64 and aarch64 as the standard arch names. |
||
| "arm64", | ||
| ] | ||
| hyperv_generations = [ | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If gen1/gen2 have different kiwi files, we need create different tomls for them in this model with only one gen hardcoded in it |
||
| "gen2", | ||
| ] | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For package-to-test mapping, we will prefer a label-based approach, similar to package publish labels.
Each package will be tagged with at least one label, with the option to also pin specific individual test cases.
Labels will be resolved on TEE's end, where the label-to-tests (group of tests) mapping will be defined.
As TEE is the sole owner of all test-related data and with all the context, If CT sends a test label that TEE cannot run on the specified image, it will return an error. In future, we can extend TEE to suggest the most suitable image/test-suite for the given tests, allowing CT/VS to select the appropriate one.