Cannot determine boot-finished state reliably

Bug #1258113 reported by Robie Basak on 2013-12-05
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
cloud-init
Medium
Unassigned

Bug Description

From outside an instance, ssh becomes available before cloud-init is done. If I ssh in, I'd like to be able to automatically wait until cloud-init has finished, so as not to collide with anything it is doing.

I'd like to be able to do this independently of any userdata. I think this makes for a cleaner separation between components, and makes everything easier to develop and test. For example, I'ld like uvtool to allow the user to completely override everything that is passed through to cloud-init, but for uvtool to still be able to detect when the instance is ready "from the outside". This is why I don't like the idea of having to make my own arrangement for this via userdata.

/var/lib/cloud/instance/boot-finished works, but only for the first boot, since it is persistent. Another point of unreliability is if somebody boots a machine in order to modify it, shuts it down, and then clones it. In this case, each clone has a boot-finished file before it has started booting.

We discussed doing something in /run instead.

I can't think of any other mechanism that can be used "from the outside", independent of userdata, that is not horribly obtuse or racy.

Could whatever we end up doing please be added in time for Ubuntu Trusty, so that tools that boot Trusty images will be able to use it? Otherwise we'll need to wait another two years I think. Thanks!

Scott Moser (smoser) wrote :

We can make final_modules write a marker file in /run.
I think jst adding a different 'final-marker' module (cc_final_marker) would be best.

We cna make it write to /run/cloud-init/finished.
and also try to figure out how we can make it mark "all passed" or some indication of pass/failed there too.

patches are most definitely welcome.

Changed in cloud-init:
status: New → Triaged
importance: Undecided → Medium
Thomas Bechtold (toabctl) wrote :

I think the bug is done. See http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/status.txt for description howto check if cloud-init run finished.

Robie Basak (racb) wrote :

That looks good - thanks!

I have one more related request that I didn't think of when I originally wrote this report. I'd like to be able to detect that an installed system _will_ write to the new path in /run if nothing is there right now, so that I can detect when I can wait for that file and when I must fall back to my previous hacks. Maybe a test for a file, or a way to run --version against something? dpkg-query seems a bit too Debian/Ubuntu -specific to me. Is running "cloud-init --version" acceptable to use with a no API breakage guarantee?

Alternatively any other way to fix my hack so detection works for both cloud-init with this new feature and on old releases using older cloud-init using the same script in both cases would be fine.

Right now my hack looks like this: http://bazaar.launchpad.net/~uvtool-dev/uvtool/trunk/view/head:/remote-wait.sh

No rush as I won't try and make Vivid for this since the current hack works OK. I can fix this next cycle though.

Vincent Legoll (vincent-legoll) wrote :

Is this bug finished, I skimmed through the doc, but did not find the way I should check for c-i to be done.

Did I miss it ?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers