On Mon, 24 Jun 2019 at 17:13, Eric Fried <openstack@fried.cc> wrote:
If we now resize the instance to a different flavor which has a different set of traits, we would end up with a new set of traits, which map a new set of deploy templates, with a new set of steps.
How do we apply this change? Should we execute all matching deploy steps, which could (e.g. RAID) result in losing data? Or should we attempt to execute only those deploy steps that have changed? Would that always work? I don't think we keep a record of the steps used to provision a node, so if templates have changed in the intervening time then we might not get a correct diff.
Not being intimately familiar with the workings, the approach I've been advocating is to only support the changes you support, and fail on anything else.
In other words, compare the old flavor to the new flavor. If the diff contains anything other than this "hyperthreading" gizmo, fail.
Hmm, I hadn't realised it would be quite this restricted. Although this could make it work, it does seem to be baking more ironic specifics into nova. There is an issue of standardisation here. Currently we do not have standard traits to describe these things, instead we use custom traits. The reason for this has been discussed earlier in this thread, essentially that we need to encode configuration key and value into the trait, and use the lack of a trait as 'don't care'. We did briefly discuss an alternative approach, but we're a fair way off having that.
Ironic resize is a special snowflake, and only supports a very limited set of changes done in a very limited way. At first, it's just one thing. You can add other pieces as demand arises, but by default you're rejecting big complicated things like your RAID example.
efried .