<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Michael</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Feb 18, 2017 6:29 AM, "Artom Lifshitz" <<a href="mailto:alifshit@redhat.com">alifshit@redhat.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Early on in the inception of device role tagging, it was decided that<br>
it's acceptable that the device metadata on the config drive lags<br>
behind the metadata API, as long as it eventually catches up, for<br>
example when the instance is rebooted and we get a chance to<br>
regenerate the config drive.<br>
<br>
So far this hasn't really been a problem because devices could only be<br>
tagged at instance boot time, and the tags never changed. So the<br>
config drive was pretty always much up to date.<br>
<br>
In Pike the tagged device attachment series of patches [1] will<br>
hopefully merge, and we'll be in a situation where device tags can<br>
change during instance uptime, which makes it that much more important<br>
to regenerate the config drive whenever we get a chance.<br>
<br>
However, when the config drive is first generated, some of the<br>
information stored in there is only available at instance boot time<br>
and is not persisted anywhere, as far as I can tell. Specifically, the<br>
injected_files and admin_pass parameters [2] are passed from the API<br>
and are not stored anywhere.<br>
<br>
This creates a problem when we want to regenerated the config drive,<br>
because the information that we're supposed to put in it is no longer<br>
available to us.<br>
<br>
We could start persisting this information in instance_extra, for<br>
example, and pulling it up when the config drive is regenerated. We<br>
could even conceivably hack something to read the metadata files from<br>
the "old" config drive before refreshing them with new information.<br>
However, is that really worth it? I feel like saying "the config drive<br>
is static, deal with it - if you want to up to date metadata, use the<br>
API" is an equally, if not more, valid option.<br>
<br>
Thoughts? I know y'all are flying out to the PTG, so I'm unlikely to<br>
get responses, but I've at least put my thoughts into writing, and<br>
will be able to refer to them later on :)<br>
<br>
[1] <a href="https://review.openstack.org/#/q/status:open+topic:bp/virt-device-tagged-attach-detach" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/status:open+topic:bp/virt-<wbr>device-tagged-attach-detach</a><br>
[2] <a href="https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2667-L2672" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>nova/blob/master/nova/virt/<wbr>libvirt/driver.py#L2667-L2672</a><br>
<br>
--<br>
Artom Lifshitz<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div>