[openstack-dev] [nova] Device tagging: rebuild config drive upon instance reboot to refresh metadata on it

Artom Lifshitz alifshit at redhat.com
Sat Feb 18 18:54:11 UTC 2017


A few good points were made:

* the config drive could be VFAT, in which case we can't trust what's
on it because the guest has write access
* if the config drive is ISO9660, we can't selectively write to it, we
need to regenerate the whole thing - but in this case it's actually
safe to read from (right?)
* the point about the precedent being set that the config drive
doesn't change... I'm not sure I 100% agree. There's definitely a
precedent that information on the config drive will remain present for
the entire instance lifetime (so the admin_pass won't disappear after
a reboot, even if using that "feature" in a workflow seems ludicrous),
but we've made no promises that the information itself will remain
constant. For example, nothing says the device metadata must remain
unchanged after a reboot.

Based on that here's what I propose:

If the config drive is vfat, we can just update the information on it
that we need to update. In the device metadata case, we write a new
JSON file, overwriting the old one.

If the config drive is ISO9660, we can safely read from it to fill in
what information isn't persisted anywhere else, then update it with
the new stuff we want to change. Then write out the new image.



On Sat, Feb 18, 2017 at 12:36 PM, Dean Troyer <dtroyer at gmail.com> wrote:
> On Sat, Feb 18, 2017 at 10:23 AM, Clint Byrum <clint at fewbar.com> wrote:
>> But I believe Michael is not saying "it's unsafe to read the json
>> files" but rather "it's unsafe to read the whole config drive". It's
>> an ISO filesystem, so you can't write to it. You have to read the whole
>> contents back into a directory and regenerate it. I'm guessing Michael
>> is concerned that there is some danger in doing this, though I can't
>> imagine what it is.
>
> Nova can be configured for config drive to be a VFAT filesystem, which
> can not be trusted.  Unfortunately this is (was??) required for
> libvirt live migration to work so is likely to not be an edge case in
> deployments.
>
> The safest read-back approach would be to generate both ISO9660 and
> VFAT (if configured) and only read back from the ISO version.  But
> yuck, two config drive images...still better than passwords in the
> database.
>
> dt
>
> --
>
> Dean Troyer
> dtroyer at gmail.com
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
--
Artom Lifshitz



More information about the OpenStack-dev mailing list