"advanced" partitioning layouts

[MaxRink]

Currently CAPI-Images build from ISOs use a very simplistic partition layout which makes them more prone for certain failures, like an overfull /var and /var/log.
We mitigated that by adding /var and /var/log partitions, but this currently breaks the cleanup-steps in sysprep as /var/log cant be deleted at this point.
We've also build autoexpansion of the OS to the disksize specified in vmware/OpenStack.
Would there be a general Interest to include such things in Image-builder, because if so i would invest time to refactor them a bit.

[detiber]

@MaxRink my initial thoughts are that yes, we should likely support more advanced partitioning layouts, especially as we are looking to support things like using a separate volume for etcd, and trying to take advantage of ephemeral disks where possible for performance reasons.

I suspect @voor, @codenrhoden, @randomvariable, @CecileRobertMichon, and possibly others might have additional thoughts.

/cc @voor @codenrhoden @randomvariable @CecileRobertMichon

[voor]

So I think the idea here was that these new partitions would exist at creation time of the actual instance as provided by the underlying IAAS rather than at time of the base image being built by image-builder. If anything, image builder should make sure those directories are ready to be mounted over. Am I misunderstanding that approach? This is related to an issue in CAPI already:

• CABPK: Support disk_setup and mounts in cloud-init cluster-api#2994
• Improved access to the cloud-init interface cluster-api#3064
• 📖 Etcd on data disk CAEP cluster-api#3048

[moshloop]

I think this problem is cross-provider - it would be nice to have a solution (or at least interface) that is agnostic and takes an existing image and converts it into a specific layout

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[voor]

Just want to chime in on this issue if anybody finds it, with the new support for overriding where images are coming from, I highly encourage an approach that partitions the image prior to running it through image builder. The requirements around partitions are vastly complex.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.