Open Stack

In reply to Michael:

> We have had this discussion several times in the past for other reasons. The
> reality is that some people will never deploy the metadata API, so I feel
> like we need a better solution than what we have now.

Aha, that's definitely a good reason to continue making the config
drive a first-class citizen.

> However, I would consider it probably unsafe for the hypervisor to read the
> current config drive to get values

Yeah, I was using the word "hack" very generously ;)

> and persisting things like the instance
> root password in the Nova DB sounds like a bad idea too.

I hadn't even thought of the security implication. That's a very good
point, there's no way to persist admin_pass in securely. We'll have to
read it at some point, so no amount of encryption will change
anything. We can argue that since we already store admin_pass on the
config drive, storing it in the database as well is OK (it's probably
immediately changed anyways), but there's a difference between having
it in a file on a single compute node, and in the database accessible
by the entire deployment.

In reply to Clint:

> Agreed. What if we simply have a second config drive that is for "things
> that change" and only rebuild that one on reboot?

We've already set the precedent that there's a single config drive
with the device tagging metadata on it, I don't think we can go back
on that promise.


So while we shouldn't read from the config drive to get current values
in order to afterwards monolithically regenerate a new one, we could
try just writing to the files we want changed. I'm thinking of a
system where code that needs to change information on the config drive
would have a way of telling it "here are the new values for
device_metadata", and whenever we next get a chance, for example when
the instance is rebooted, those values are saved on the config drive.