Thanks for the comments!
There does seem to be a difference in how network: is handled versus filesystem:. network: is a complete pass through to netplan (which is great) where as the filesystem: is not a complete pass through to curtin the installer used under the hood.
So maybe I’ve been unclear here. The idea is very much that anything that is valid curtin storage config can go under filesystem: and just be passed through. What’s different to network/netplan is that the syntax is extended to allow other things (basically, netplan supports some degree of wildcarding natively, curtin does not). BTW, exactly how this extension of curtin syntax will work is the part of all this I am fuzziest on, if people have thoughts on how it should work in detail I’m all ears.
While I do like that filesystem: allows the layouts and the automated server installer will then build a simple curtin layout, it would be nice to support a passthrough method just like network: passes through to netplan.
As above, that’s the plan.
Curtin uses the key storage: to define the storage layout could the automated server installer support either storage: or filesystem: for those wanting to provide very specific storage layout configuration. In the case that both are provided it could be an error or storage could take precendence over filesystem: with a warning about that choice.
Do you mean the difference between
block-meta simple and
block-meta custom here? Subiquity currently always generates a config that puts curtin into custom mode. And hmmmmm I’d forgotten that simple and custom are configured by different top-level keys (“storage” for custom and “block-meta” for simple) so I think I see what you meant above now (and we can’t do a neat thing of just transplanting what’s under a key in the autoinstall file to some key in the curtin config). So let me brain dump for a bit:
There are three broad types of filesystem configuration we might expect the user to supply:
- configuration for the curtin’s block-meta simple mode
- configuration for curtin’s block-meta custom mode (actually probably some extension of this)
- one of the guided layouts such as lvm or lvm-luks
We could do this just by looking at which keys are present under the filesystem: top-level key: ‘block-meta’ for block meta simple, ‘config’ (and version?) for block-meta custom, ‘layout’ for a guided layout (and handle more than one of these being present by either defining a precedence or erroring). This seems simple enough.
Would you want the configuration for block-meta simple to support wildcarding in any sense?