We want to have a mechanism in cloud images to pass information like cloud name, region, availability zone to snapd. Our base case has cloud-init. Ideally the information needs to be available/been passed before snapd attempts the first refresh.
The motivation of having cloud placement information in snapd is being able to choose an in-cloud proxy/cache together with the general store.
As I learned most of cloud-init runs in a cloud image based on systemd before snapd starts.
This is because
snapd.service doesn’t specify
DefaultDependencies=no so gets an implicit
cloud-init.service itself is configured as
Type=oneshot, Before=sysinit.target, DefaultDependencies=no. Because cloud-init collects the kind of information we need about cloud placement very early in its
cloud-init.service part run, by the time snapd runs or is invoked by cloud-init itself the information should be available. Moreover cloud-init writes this information into
/run/cloud-init/instance-data.json under the
I think we have more or less this spectrum of options for snapd to get this information, some more specific to cloud-init and some that would be more general:
- snapd could simply check for
/run/cloud-init/instance-data.jsonwhen it starts and get the information from there. This hard-codes cloud-init details into snapd.
We could instead define a snapd specific file under
[snapd-]cloud.yaml?) with the information structured along snapd wishes.
- We could define a more general mechanism of files/a file to convey runtime information to snapd before it starts (this ought to be limited to information whose effects should be ok written by root but without a brand signature on them though), then cloud placement information would be using this. Would such information be a subset of core config/reflected as core config while snapd runs to anchor the concept/not multiply concepts here?
- A cloud-init plugin could write a
/etc/systemd/system/snapd.service.d/cloud.confsetting envar(s) to pass the information.
- A cloud-init plugin could use
snap set coreto set the information under a (strawman)
proxy.cloud-placementnamespace. We have a race here with the first refresh that could potentially happen before the config is committed. snapd would need to know by other means that this information is forthcoming. Strawman could be a default config value from the gadget like
proxy.cloud-placement=wait. This requires the presence of a gadget. Or some other bit of information set by ubuntu-image when building a cloud image.
- A gadget hook (called when? In which situations?) that would instead call
snapctl seton its config to transmit the information. Again snapd might need to know to wait (until timeout) before the first refresh for this forthcoming information. Again a gadget hook implies the presence of a gadget.
Question: are there some image migration scenarios where is important for snapd to pick up a change in this information? Is this supported? Would be next boot be enough? This issue also could influence the preferred mechanism.