ssh key mismatch occurred when booting more than one instance

Bug #1858024 reported by Liron Kuchlani
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Shared File Systems Service (Manila)
Fix Released
Low
Liron Kuchlani

Bug Description

Description of problem:
When I ran manila scenario tests, some tests failed due to ssh key authentication.
I noticed that tests with single instance pass, however, tests with more than
one instance (e.g. "test_read_write_two_vms" test) fail.
I figured out that there is a mismatch between both instance keys.
I tried to use a single key for both instances and the test passed.

Version-Release number of selected component (if applicable):
puppet-manila-12.5.1-1.el7ost.noarch
python2-manilaclient-1.21.2-1.el7ost.noarch
python2-manila-tests-tempest-0.3.0-1.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. python -m unittest manila_tempest_tests.tests.scenario.test_share_basic_ops.TestShareBasicOpsNFS.test_read_write_two_vms

Actual results:
Unable to login, password is requested

Expected results:
Login with ssh key succeeded

Additional info:

Traceback (most recent call last):
  File "manila_tempest_tests/tests/scenario/test_share_basic_ops.py", line 161, in test_read_write_two_vms
    remote_client_inst1 = self.init_remote_client(instance1)
  File "manila_tempest_tests/tests/scenario/manager_share.py", line 169, in init_remote_client
        remote_client.exec_command("sudo umount %s" % target_dir)
    private_key=self.keypair['private_key'])
  File "manila_tempest_tests/tests/scenario/manager_share.py", line 263, in get_remote_client
    linux_client.validate_authentication()
  File "manila_tempest_tests/common/remote_client.py", line 51, in wrapper
    six.reraise(*original_exception)
  File "manila_tempest_tests/common/remote_client.py", line 32, in wrapper
    return function(self, *args, **kwargs)
  File "manila_tempest_tests/common/remote_client.py", line 92, in validate_authentication
    self.ssh_client.test_connection_auth()
  File "/home/stack/tempest-auto/.venv/lib/python2.7/site-packages/tempest/lib/common/ssh.py", line 207, in test_connection_auth
    connection = self._get_ssh_connection()
  File "/home/stack/tempest-auto/.venv/lib/python2.7/site-packages/tempest/lib/common/ssh.py", line 121, in _get_ssh_connection
    password=self.password)
tempest.lib.exceptions.SSHTimeout: Connection to the 10.0.0.218 via SSH timed out.
User: manila, Password: None

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to manila-tempest-plugin (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/700833

Changed in manila:
status: New → Confirmed
Tom Barron (tpb)
Changed in manila:
importance: Undecided → Low
assignee: nobody → Liron Kuchlani (lkuchlan)
milestone: none → ussuri-2
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to manila-tempest-plugin (master)

Reviewed: https://review.opendev.org/700833
Committed: https://git.openstack.org/cgit/openstack/manila-tempest-plugin/commit/?id=0cd6c999d4985e10be2566c631312720efe8413c
Submitter: Zuul
Branch: master

commit 0cd6c999d4985e10be2566c631312720efe8413c
Author: lkuchlan <email address hidden>
Date: Wed Jan 1 15:56:52 2020 +0200

    Use a single keypair for multiple instances

    When I ran manila scenario tests, some tests failed due to
    ssh key authentication. I noticed that tests with single
    instance pass, however, tests with more than one instance
    (e.g. "test_read_write_two_vms" test) fail.
    I figured out that every instance initialization creates a
    unique keypair.
    An unnecessary resource duplication, when a single user boots
    more than one instance. Depending on test flow this may also
    cause keypair mismatch.

    Change-Id: Ic685d1b9574daf7e6c9b90d5636f1b614a70b0da
    Related-bug: #1858024

Changed in manila:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.