[Nova][Ironic] Reset Configurations in Baremetals Post Provisioning
madhuri.kumari at intel.com
Wed Jun 26 11:19:49 UTC 2019
>>From: Mark Goddard [mailto:mark at stackhpc.com]
>>I was talking with Madhuri in #openstack-ironic about this today .
>>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
>>* 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
>>* deploy steps from the matching templates are used when provisioning the
>>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
Mark and I had discussion about this yesterday. 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.
More information about the openstack-discuss