Persistent storage on nodes is not supported
Bug #1174154 reported by
Robert Collins
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ironic |
Fix Released
|
Medium
|
Lucas Alvares Gomes | ||
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Unassigned | ||
tripleo |
Fix Released
|
High
|
Unassigned |
Bug Description
At the moment nova baremetal resets the first disk partition when deploying, and even when that is worked around (e.g. using a second disk) you still can't guarantee the new image lands on a node that had appropriate persistent data (e.g. a swift node).
One long term plan is to teach the baremetal system about cinder volumes and use boot --with-volume to land on the same node. When this is done the partition table will be preserved on rebuilds / new instances.
However in the short term we want to use the ephemeral feature and make it possible to preserve the partition during update - http://
Changed in nova: | |
status: | New → Triaged |
importance: | Undecided → Medium |
description: | updated |
tags: | added: baremetal |
Changed in ironic: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Changed in ironic: | |
assignee: | nobody → Lucas Alvares Gomes (lucasagomes) |
status: | Confirmed → In Progress |
Changed in ironic: | |
status: | In Progress → Fix Committed |
milestone: | none → icehouse-3 |
Changed in ironic: | |
status: | Fix Committed → Fix Released |
Changed in ironic: | |
milestone: | icehouse-3 → 2014.1 |
Changed in nova: | |
status: | Triaged → Fix Released |
To post a comment you must log in.
Reviewed: https:/ /review. openstack. org/59468 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=a51ba1ce7d5 fce7aa1104b7c15 58934cb3998f27
Committed: https:/
Submitter: Jenkins
Branch: master
commit a51ba1ce7d5fce7 aa1104b7c155893 4cb3998f27
Author: Roman Podoliaka <email address hidden>
Date: Tue Dec 3 18:14:17 2013 +0200
Let drivers override default rebuild() behaviour
The rebuild compute method currently makes separate calls to destroy()
and spawn(), but this introduces race conditions with drivers where
another compute process could claim the VM resources between destroy
and spawn. This is a particular problem for baremetal where the
planned ephemeral preservation feature requires that the rebuild
happen on the same physical node.
Partial-Bug: #1174154 preserve- ephemeral
blueprint: baremetal-
Co-Authored-By: Robert Collins <email address hidden>
Co-Authored-By: Joe Gordon <email address hidden>
Change-Id: I5fadc27207ed57 25ecf0cf6bc34a5 2a95af42679