Open Stack

Excerpts from Artom Lifshitz's message of 2017-02-18 08:11:10 -0500:
> 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.
> 

Up until now, there's also been a precedent that config drive won't
change. So you'd need to define a new config drive API version that is
allowed to change (people may be relying on them not changing).

But I believe Michael is not saying "it's unsafe to read the json
files" but rather "it's unsafe to read the whole config drive". It's
an ISO filesystem, so you can't write to it. You have to read the whole
contents back into a directory and regenerate it. I'm guessing Michael
is concerned that there is some danger in doing this, though I can't
imagine what it is.