yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1392134@xxxxxxxxxxxxxxxxxx>]

[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1392134

Title:
  nova rescue fails if connection made before RESCUE state

Status in OpenStack Compute (Nova):
  Expired

Bug description:
  Issue reported by one of our users in our Trusty/Icehouse controller +
  Precise/Havana compute + nova-network cloud:

  ---
  If I put the instance into rescue mode:
   $ nova rescue 598ec2ba-9d87-484d-ae3a-4661b4be3d91

  And then *immediately* try to ssh in:
   $ ssh ubuntu@xxxxxxxx -i ~/.ssh/some_key.pem

  I get no errors, but even if I get a connection refused message, the
  instance does not go into rescue mode properly.

  However, if I put the instance into rescue mode:
   $ nova rescue 598ec2ba-9d87-484d-ae3a-4661b4be3d91

  And then wait until Nova list tells me that the instance is in rescue mode:
   $ nova list
  +--------------------------------------+---------+--------+------------+-------------+-------------------+
  | ID                                   | Name    | Status | Task State | Power State | Networks          |
  +--------------------------------------+---------+--------+------------+-------------+-------------------+
  | 598ec2ba-9d87-484d-ae3a-4661b4be3d91 | tester2 | RESCUE | -          | Running     | public= |
  +--------------------------------------+---------+--------+------------+-------------+-------------------+

  & only then ssh in, everything is sweetness and light.

  So to my untrained eye, it would appear that eagerly ssh'ing in to the instance is affecting the rescue operation.
  ---

  
  Console log for the instance shows:

  An error occurred while mounting /mnt.
  keys:Press S to skip mounting or M for manual recovery

  Looks like it failed to mount the rescue disk partition at /dev/vda1
  and instead mounts /dev/vdb1 as the root disk, which is the disk from
  the original instance being rescued:

  Filesystem      Size  Used Avail Use% Mounted on
  /dev/vdb1       9.8G  833M  8.4G   9% /

  I can mount /dev/vda1 to /mnt manually and it looks like an untouched
  ubuntu image.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1392134/+subscriptions