Hi there,
I run into an issue after the gadget snap got upgraded, which is expected to apply the new cloud.conf file in the new version of gadget snap, but it didn’t. After digging in, the file /etc/cloud/cloud.cfg.d/80_device_gadget.cfg still has the contents as the old version of the gadget snap. Have you run into the same issue?
Thanks,
Hao
Hmm, is this part of codes related? https://github.com/snapcore/snapd/blob/master/sysconfig/cloudinit.go#L114-L121 
We do not currently upgrade cloud.conf from the gadget when the gadget snap is updated. I will need to have a chat to look at whether we should do this or not, it’s a bit tricky, since cloud.conf could be considered a gadget asset, and so hypothetically maybe we should reboot to “try” the cloud.conf to make sure it keeps networking or what have you working, and revert to the previous state of the cloud.conf if things are broken.
Thanks @ijohnson for the updates. We use cloud.conf to update some system files so that all other snaps wouldn’t connect to system-files interfaces.
Hi @ijohnson, would you like me to create a ticket on Launchpad to follow up? Thanks
For a rollback, the old version of gadget should have the working cloud.conf so OS can start up.
Update: here is the ticket on Launchpad, Bug #1929722 “Gadget upgrade didn't apply the new cloud.conf” : Bugs : snapd
As a workaround, is it ok to copy the cloud.conf file from gadget snap folder to /etc/cloud/cloud.cfg.d/80_device_gadget.cfg in cloud.conf file?
@ijohnson a quick question for rollback, will uc20 roll back with the old working gadget snap if the new version cannot boot OS or I need to roll back the version on snap store? If the new version cannot boot OS, does someone have to access the uc20 machine and enter recovery mode manually? Thanks.
@snowsky if the refresh fails, snapd will automatically revert to the previous revision without you needing to do anything on the store side. We do not currently automatically go into recovery mode on UC20, but we will eventually do this if even the rolling back still does not work for example.
@ijohnson seems that the cloud.conf file will be updated here
https://github.com/snapcore/snapd/blob/master/sysconfig/cloudinit.go#L114-L121
That code is not run on gadget refresh, only on initial seeding of the device
hmm interesting, I just did a snap refresh and the file /etc/cloud/cloud.cfg.d/80_device_gadget.cfg got updated with the new version from gadget snap. Probably snap refresh from the new version of snapd make it happen?
@ijohnson, by the way after going thru some codes, a quick question, is there something different between dangerous and signed gadgets? So the cloud.conf file in dangerous assertion can be updated but other grades will not be able to do so?
Hmm it doesn’t seem it is the case, last time the gadget cloud.conf file got updated with signed grade.
Is it possible that this preseed variable is false? https://github.com/snapcore/snapd/blob/master/overlord/devicestate/devicemgr.go#L1190.
I’ve got one of the system parameters as below from snap get -d system:
Preseeding is not relevant since you are on Ubuntu Core, we don’t preseed anything or support preseeding at all on Ubuntu Core. It would be very wrong if your device was somehow “unseeded” to the point where seeded went from being true to being false.
Thanks @ijohnson for the details. Just to figure out why the cloud.conf file of some images got updated in an unexpected way, correct me if I’m wrong, seems to me that the only place to update the new version of cloud.conf file is under the above section and then in the function, https://github.com/snapcore/snapd/blob/a8fa4ce8b91645403a7f08e69e5f993a561a1bb4/overlord/devicestate/devicemgr.go#L928.
To trace into the function call stack, finally the above function will call configureCloudInit to copy the new version of cloud.conf file to the system folder. That is the place I feel a bit curious on the preseed variable, because there is no other place to call the function configureCloudInit again if m.preseed is true.
Thanks,
Sorry for raising the dead here, but I’m very interested to know if it is yet possible to somehow retrigger the cloud-init process for a gadgets cloud.conf
I can see I can remove the /etc/cloud/cloud-init.disabled and reboot, however an updated gadgets cloud.conf doesn’t get executed, if anything it was the version present during the install.
My current usecase is to configure SSHD more to our requirements which works fine once, but I’m unable to rotate CA keys or update configuration without reinstalling potentially 1000s of devices
