Open Stack

On 02/17/2017 02:28 PM, Artom Lifshitz 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.

Yeah, config drive should, IMHO, be static, readonly. If you want to 
change device tags or other configuration data after boot, use a 
configuration management system or something like etcd watches. I don't 
think Nova should be responsible for this.

Best,
-jay