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.
However, I would consider it probably unsafe for the hypervisor to read the current config drive to get values, and persisting things like the instance root password in the Nova DB sounds like a bad idea too. Michael On Feb 18, 2017 6:29 AM, "Artom Lifshitz" <alifs...@redhat.com> wrote: Early on in the inception of device role tagging, it was decided that it's acceptable that the device metadata on the config drive lags behind the metadata API, as long as it eventually catches up, for example when the instance is rebooted and we get a chance to regenerate the config drive. So far this hasn't really been a problem because devices could only be tagged at instance boot time, and the tags never changed. So the config drive was pretty always much up to date. In Pike the tagged device attachment series of patches [1] will hopefully merge, and we'll be in a situation where device tags can change during instance uptime, which makes it that much more important to regenerate the config drive whenever we get a chance. However, when the config drive is first generated, some of the information stored in there is only available at instance boot time and is not persisted anywhere, as far as I can tell. Specifically, the injected_files and admin_pass parameters [2] are passed from the API and are not stored anywhere. This creates a problem when we want to regenerated the config drive, because the information that we're supposed to put in it is no longer available to us. We could start persisting this information in instance_extra, for example, and pulling it up when the config drive is regenerated. We could even conceivably hack something to read the metadata files from the "old" config drive before refreshing them with new information. However, is that really worth it? I feel like saying "the config drive is static, deal with it - if you want to up to date metadata, use the API" is an equally, if not more, valid option. Thoughts? I know y'all are flying out to the PTG, so I'm unlikely to get responses, but I've at least put my thoughts into writing, and will be able to refer to them later on :) [1] https://review.openstack.org/#/q/status:open+topic:bp/virt- device-tagged-attach-detach [2] https://github.com/openstack/nova/blob/master/nova/virt/ libvirt/driver.py#L2667-L2672 -- Artom Lifshitz __________________________________________________________________________ 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
__________________________________________________________________________ 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