Red Hat Bugzilla – Bug 1267598
nova: when attempted 'nova resize' on setup with two compute nodes the instance switched to ERROR state.
Last modified: 2017-11-28 14:19:53 EST
This is to ensure that nova resize works as expected when installation is driven by osp-director.
What we'd like to validate is that live migration and instance resize works after a director deployment.
Great that this is fixed in OSP?
To clarify on this, we are requesting a retest of live migration and instance resize on director-based deployments. There is a distinct possibility this will bounce back to development with specific issues that still need to be addressed but we want to re-validate the state of the functionality.
I marked this ticket as a blocker, if we try to deploy with 1000 compute nodes or more, customer will need to access each node and add the cert, this is unacceptable user experience.
The issue is that nova@compute is trying to do a passwordless ssh into nova@controller. However, nova@compute doesn't have a cert registered with nova@controller, so the passwordless login fails.
Given timeframe, this is not a blocker for 7.2, we can clearly document it and make sure to fix it in OSP8.
Can you clarify where and which certs are needed?
Controller nodes need certs for each nova/compute node? Inverse?
All nova nodes need certs for all other nova nodes?
Undercloud need certs for all overcloud nodes?
Also it looks like we will need to split this BZ into two.
One for documentation for OSP7 and one for actual fix for OPS8/OSP8-d.
This bug did not make the OSP 8.0 release. It is being deferred to OSP 10.
Since this is deferred to OSP 10, I'm moving it to the delljs7.0 tracker.
Note that versions of this BZ exist for OSP 5, 975014, OSP 6 1028186, and OSP 7 1292532.
Should some of those BZ's be closed, or should this BZ have been left for OSP 8, and cloned for OSP 10?
*** Bug 1221776 has been marked as a duplicate of this bug. ***
So does this BZ makes it for OSP10 or not?
I am seeing a lot of pointers to various BZs that are either closed but not fixed or re-targeted to OSP11.
(In reply to arkady kanevsky from comment #18)
> So does this BZ makes it for OSP10 or not?
> I am seeing a lot of pointers to various BZs that are either closed but not
> fixed or re-targeted to OSP11.
No, there are a number of issues in this area that the OOTB configuration does not currently support. The current documented workaround is the same as for live migration:
Correcting this will require director/tripleo to handle this additional configuration (which in some environments will not be desired, so it will need to be togglable but default to on - not all operators accept the hosts having access to each other in this fashion), we are exploring what this will look like in Ocata.
I've left a 10.0.z flag for now in the hope that it might be backportable but this will depend on the resolution.
Hi Steve, just checking in to see if there have been any further discussions on this since your November update in comment 19.
(In reply to Sean Merrow from comment #20)
> Hi Steve, just checking in to see if there have been any further discussions
> on this since your November update in comment 19.
We're still determining what whether we can offer an OOTB solution in 12, any opportunity for backport is obviously contingent on that, the priority is ensuring we have secure OOTB live migration - the cold migration setups (including resize) would need to be addressed after this. See also Bug # 1404294.
I did a test of Nova Resize after setting up the ssh keys to the computes (following the instructions in the link noted in Comment 19), and it was successful with OSP10.
This is now working OOTB in JS10.0.1.60 without the workaround of ssh keys.
According to our records, this should be resolved by openstack-nova-2015.1.4-46.el7ost. This build is available now.