Custom UEFI certificates - API change proposal about xen-api

[psafont]

This looks like the design we discussed last week. It's adding a new field, which is not used when the per-host setting is false, and it even simplifies the case. This looks good to me, and I'd be glad to review PRs implementing this, @mg12 might want to add comments before implementation starts

[edwintorok]

If you add a new field then is the xapi.conf entry still needed, can it be completely removed to reduce the combinatorial matrix of codepaths to test?
By default that new field would be empty, and as long as the user doesn't override it, they'll be fine.

If they make an API call (or 'xe' cli call) then we'll apply the semantics of that field (maybe for a short while we need to do something on upgrades to still recognize the old xapi.conf field).
i.e. treat 'allow_custom_uefi_certs' as always true even in XenServer, it is just that in xenserver we'd leave the field to be empty.

That seems to match the semantics you wanted? i.e. these 2 options are the same

If allow_custom_uefi_certs is false:
Ensure /var/lib/varstored is a symlink to /usr/share/varstored (unchanged from previous behaviour)
If allow_custom_uefi_certs is true AND Pool.custom_uefi_certificates is empty or is not a valid value:
Ensure /var/lib/varstored is a symlink to /usr/share/varstored (no custom certs: keep/restore the symlink)

[stormi]

@edwintorok Yes. The reason why this setting exist is because XenServer didn't want to allow installing custom certificates and XCP-ng needed to. I'm fine with either keeping or removing the setting.

[edwintorok]

I thought the difference was that we installed some certificates by default (and the method that we used to install them changed over time), whereas xcp-ng got 0 certificates by default and the user had to install them.

I don't think that having the ability to install custom certificates in XenServer would be bad, it might be a useful feature, but it isn't something we'd advertise in the UI, or (initially) support customers to do, and because we don't strictly need it, we likely wouldn't test it.
But just like with all the other experimental and unsupported features in XAPI if someone from the CLI does it then if they break it is their responsibility to fix.

If we can keep the code simpler by having just 2 code paths (XenServer default and Xcp-ng default) instead of 3 or 4, then that might be better

[edwintorok]

cc @mg12 who worked on the original flag in XS for this.

[stormi]

maybe for a short while we need to do something on upgrades to still recognize the old xapi.conf field

If it's just ignored when present, without causing XAPI to fail, that's enough for me. Only beta-testers of XCP-ng 8.3 are concerned on our side, and we override xapi.conf when the defaults change in it (this is because defaults in XAPI code are tailored for XenServer, so xapi.conf is our way to set our XCP-ng settings. Users are redirected to xapi.conf.d if they need to add or change a setting).