Hi Mark,
-----Original Message----- From: Mark Goddard [mailto:mark@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-iron... Regards, Madhuri