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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev