Undercloud upgrade breaks due to IP range change
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tripleo |
Fix Released
|
High
|
Ben Nemec |
Bug Description
Since we changed the default IP range, upgrades for existing underclouds will break like this:
2016-11-28 09:48:24,849 INFO: + cidr=192.0.2.0/24
2016-11-28 09:48:24,850 INFO: + '[' 192.0.2.0/24 = 192.168.24.0/24 ']'
2016-11-28 09:48:24,850 INFO: + echo 'New cidr 192.168.24.0/24 does not equal old cidr 192.0.2.0/24'
2016-11-28 09:48:24,850 INFO: New cidr 192.168.24.0/24 does not equal old cidr 192.0.2.0/24
2016-11-28 09:48:24,850 INFO: + echo 'Will attempt to delete and recreate subnet 0fc641d3-
2016-11-28 09:48:24,850 INFO: Will attempt to delete and recreate subnet 0fc641d3-
2016-11-28 09:48:24,850 INFO: + '[' 1 -eq 1 ']'
2016-11-28 09:48:24,850 INFO: + neutron subnet-list
2016-11-28 09:48:24,850 INFO: + grep start
2016-11-28 09:48:26,202 INFO: | 0fc641d3-
2016-11-28 09:48:26,203 INFO: ++ neutron subnet-list
2016-11-28 09:48:26,204 INFO: ++ awk '{print $2}'
2016-11-28 09:48:26,206 INFO: ++ grep start
2016-11-28 09:48:27,464 INFO: + neutron subnet-delete 0fc641d3-
2016-11-28 09:48:28,877 INFO: Unable to complete operation on subnet 0fc641d3-
2016-11-28 09:48:28,877 INFO: Neutron server returns request_ids: ['req-f493524d-
2016-11-28 09:48:28,901 INFO: [2016-11-28 09:48:28,900] (os-refresh-config) [ERROR] during post-configure phase. [Command '['dib-run-parts', '/usr/libexec/
2016-11-28 09:48:28,901 INFO:
2016-11-28 09:48:28,901 INFO: [2016-11-28 09:48:28,901] (os-refresh-config) [ERROR] Aborting...
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/
_run_
File "/usr/lib/
_run_
File "/usr/lib/
raise RuntimeError('%s failed. See log for details.' % name)
RuntimeError: os-refresh-config failed. See log for details.
Command 'instack-
Although I support the change we made, I think we need a better user experience here - like at the start of the update we could check if the ip range will change, and if so we write a helpful message explaining what the user options are.
E.g, it seems clear that we can't support switching out the subnet, so probably we need to print an undercloud.conf fragment folks can cut/paste so they can continue using their deployment.
Long term, I guess we'll need to figure a migration plan, but I'm not sure how we do that given that the ctlplane IPs of all deployed nodes would change?
Changed in tripleo: | |
milestone: | none → ocata-2 |
status: | New → Triaged |
importance: | Undecided → High |
tags: | added: undercloud upgrade |
Changed in tripleo: | |
milestone: | ocata-2 → ocata-3 |
Changed in tripleo: | |
milestone: | ocata-3 → ocata-rc1 |
Not stopping early enough when the old range can't be deleted causes at least one issue with Swift, see bug 1646450.