storage: add part number to butane example

[prestist]

Fixes: COS-1706

[travier]

https://docs.openshift.com/container-platform/4.15/installing/installing_bare_metal/installing-bare-metal-network-customizations.html#installation-user-infra-machines-advanced_vardisk_installing-bare-metal-network-customizations does not mention the number unless I'm missing something

[travier]

Note that I'm not saying that this is invalid. Only that I don't understand it.

[prestist]

@travier Yeah it does not mention it either, and needs to be updated. openshift/openshift-docs#74419

[prestist]

1 through 4 are reserved for specific purposes, and so var would be 5.

Ugh Just noticed butane is wrong too.

Filesystems and partitions https://coreos.github.io/butane/examples/
coreos/butane#524

[travier]

Isn't the partition number automatically picked-up by Ignition?

From https://coreos.github.io/ignition/configuration-v3_4/:

number (integer): the partition number, which dictates its position in the partition table (one-indexed). If zero, use the next available partition slot.

[prestist]

Isn't the partition number automatically picked-up by Ignition?

From https://coreos.github.io/ignition/configuration-v3_4/:

number (integer): the partition number, which dictates its position in the partition table (one-indexed). If zero, use the next available partition slot.

Yeah, the thought was to include the number like the root part above. While its not necessary, it gives some context, and consistency

[jlebon]

The difference with the root one is that it's modifying an existing partition (so it needs to refer to it), whereas the /var one is new. And actually, ideally that root stanza wouldn't be necessary at all. The problem is without it, the next partition will trap it and prevent the rootfs from getting enough space.

Adding the partition number for /var seems OK though it's also totally fine to omit it, so ideally we do have examples that showcase that too.

[prestist]

Ok, I went and added an example with a number and notes. I hope this is fine lmk.

[jlebon]

I'm not sure I understand. Can you clarify: did a user hit a bug somehow related to this? How did this come on your radar?

[prestist]

@jlebon, it was something I stumbled across with an old co-worker, and we made a ticket for it. Im not sure I captured enough details at the time. I am willing to close this if you think its not worth it. No need to spin wheels on something that negatively impacts the project.