Open Stack

Hi Mark,

>>-----Original Message-----
>>From: Mark Goddard [mailto:mark at stackhpc.com]

>>I was talking with Madhuri in #openstack-ironic about this today [1].
>>While talking it through I raised some concerns about the nova resize-based
>>design, which I'll try to outline here.
>>
>>When we deploy a node using deploy templates, we have the following
>>sequence.
>>
>>* user picks a flavor and image, which may specify required traits
>>* selected traits are pushed to ironic via instance_info.traits
>>* ironic finds all deploy templates with name matching one of the selected
>>traits
>>* deploy steps from the matching templates are used when provisioning the
>>node
>>
>>The deploy steps could include RAID config, BIOS config, or something else.
>>
>>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.
>>

Mark and I had discussion about this yesterday[1]. A possible way to fix this issue is by restricting deploy_steps from specific interface such as allow bios but restrict raid.
However there could be some deploy_steps with bios interface which we might not want to allow during a resize. I don't have an example now. So I think it's better to restrict individual deploy_steps rather than a driver type.

[1] http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2019-06-25.log.html#t2019-06-25T08:32:30

Regards,
Madhuri