Open Stack

On 28 July 2016 at 18:53, Matteo Panella <matteo.panella at cnaf.infn.it> wrote:
> Hi,
>
> On 28/07/2016 10:34, Marcus Furlong wrote:
>> I've been trying to find some information about using nova resize on
>> shared storage, without giving each compute node ssh access to every
>> other compute node. As the VM is on shared storage, the compute node
>> shouldn't need ssh access to another compute node?
>
> AFAIR, nova-compute uses ssh to check whether the source and target
> compute node are in fact sharing the underlying storage for resize (and
> migrate) operations so it can choose the best resize strategy (scp
> versus local copy).
>
>> Is this something that anyone has succeeded in doing?
>
> Yep, we have GPFS as our underlying shared filesystem and we had to
> setup cross-node ssh access for nova in order to get resize/migration
> working (live migration is another story: if you're using ssh-tunneled
> connections you're already set).
>
>> I've found the following documentation:
>>
>>    http://docs.openstack.org/mitaka/config-reference/compute/resize.html
>>    http://docs.openstack.org/user-guide/cli_change_the_size_of_your_server.html
>>
>> but it does not say what to do in the case of shared storage.
>
> You should do the same thing for non-shared storage: set up ssh access
> for nova across all compute nodes. nova-compute will recognize that the
> underlying storage is shared and bypass ssh for all image-related
> operations.

I'd like to avoid giving each compute node ssh access to every other
compute node, for security reasons. If one node is compromised, 1000
nodes are compromised, which is not good. The compute nodes have no
other reason to have ssh access to each other.

Looks like there is a bug open which suggests that it should be using
RPC calls, rather than commands executed over ssh:

https://bugs.launchpad.net/nova/+bug/1459782

Cheers,
Marcus.

-- 
Marcus Furlong