Can you please describe the goal of of use case that you outlined in bug description? I mean, bootstrap a node, shutdown a node, remove storage options from node, bring it back up. Do you need it for some partner integration scenario? If not - what for?
I'm asking because, while the hack that blocks volumes update with empty data can indeed lead to inconsistent pre-deployment state (e.g. Fuel will expose disks to user that are not present in the node anymore, user will partition/allocate them, the whole thing will fail while provisioning Host OS), I need to understand how often this can be exposed in real world. So far my assumption is that in case of such changes user will rather repeat PXE boot => discovery flow for a particular node instead when the HW config was changed (instead of just booting it back up)
Oleksandr,
Can you please describe the goal of of use case that you outlined in bug description? I mean, bootstrap a node, shutdown a node, remove storage options from node, bring it back up. Do you need it for some partner integration scenario? If not - what for?
I'm asking because, while the hack that blocks volumes update with empty data can indeed lead to inconsistent pre-deployment state (e.g. Fuel will expose disks to user that are not present in the node anymore, user will partition/allocate them, the whole thing will fail while provisioning Host OS), I need to understand how often this can be exposed in real world. So far my assumption is that in case of such changes user will rather repeat PXE boot => discovery flow for a particular node instead when the HW config was changed (instead of just booting it back up)