[ostf] Assign floating IP failed in test, but actually assigned

Bug #1449946 reported by Kyrylo Romanenko
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Won't Fix
Medium
Unassigned
7.0.x
Confirmed
Medium
MOS QA Team

Bug Description

Run OSTF test "Check network connectivity from instance via floating IP" separately from others.
Target component: Neutron

Can not assign floating ip to instance Please refer to OpenStack logs for more details.

Scenario:
1. Create a new security group (if it doesn`t exist yet).
2. Create router
3. Create network
4. Create subnet
5. Uplink subnet to router.
6. Create an instance using the new security group
in created subnet.
7. Create a new floating IP
FAILED on this step: 8. Assign the new floating IP to the instance. -
...

Actually Floating IP assigned to instance:

# nova floating-ip-list
+--------------+--------------------------------------+----------+-----------+
| Ip | Server Id | Fixed Ip | Pool |
+--------------+--------------------------------------+----------+-----------+
| 172.16.57.26 | 3cf8e90f-b344-4345-a09d-7057f1196f53 | 10.0.7.2 | net04_ext |
+--------------+--------------------------------------+----------+-----------+

ENV:
Juno on CentOS 6.5, Neutron with VLAN segmentation, QEMU, no additional components.
1 Controller
1 Compute
1 Cinder with LVM

VERSION:
  feature_groups:
    - mirantis
  production: "docker"
  release: "6.1"
  openstack_version: "2014.2.2-6.1"
  api: "1.0"
  build_number: "354"
  build_id: "2015-04-27_09-17-29"
  nailgun_sha: "2efc207e7156e362c2506b66e63b8bfa745d1153"
  python-fuelclient_sha: "2b311b3b82a1e2df1dc3484a0f37e282273cd988"
  astute_sha: "c1793f982fda7e3fc7b937ccaa613c649be6a144"
  fuel-library_sha: "6bdf783e2bffdce80ecffcca2915e6d32a8ccdd7"
  fuel-ostf_sha: "b38602c841deaa03ddffc95c02f319360462cbe3"
  fuelmain_sha: "01288380950bc89d572cf5902141c9a393ada950"

Diagnostic Snapshot: https://drive.google.com/file/d/0B6E70aHvCcRQOVZEVXNBMEQ4cE0/view?usp=sharing

Changed in fuel:
assignee: nobody → Fuel QA Team (fuel-qa)
Changed in fuel:
importance: Undecided → Critical
status: New → Confirmed
milestone: none → 6.1
Revision history for this message
Kyrylo Romanenko (kromanenko) wrote :

Also reproduced this bug on another configuration of the same 6.1 ISO ( build_number: "354").
3 controllers
1 compute
1 cinder
Juno on Ubuntu 14.04.1, Neutron with GRE segmentation.

Diagnostic snapshot: https://drive.google.com/file/d/0B6E70aHvCcRQb2tDRUhKamFTakk/view?usp=sharing

Changed in fuel:
assignee: Fuel QA Team (fuel-qa) → MOS QA Team (mos-qa)
Revision history for this message
Tatyanka (tatyana-leontovich) wrote :

Actually test failed with timeout error(ostf send post request to assign ip and then timeout error happens), and Actually it is not critical issue (According to seems it is reproduced on slow environments in my env and during swarm testing issue is not reproduces)

Changed in fuel:
importance: Critical → Medium
Revision history for this message
Tatyanka (tatyana-leontovich) wrote :

@Kyrylo Romanenko could you provide the env where issue is reproduced to understand configuration and la that lead to such kinds of error?

Revision history for this message
Nastya Urlapova (aurlapova) wrote :

Was increased to High, we are waiting env.

Changed in fuel:
importance: Medium → High
assignee: MOS QA Team (mos-qa) → Kyrylo Romanenko (kromanenko)
Revision history for this message
Tatyanka (tatyana-leontovich) wrote :

I've looked on env, and there is slow env( high la, and almost all the memory is in use) so that it ts really medium status

Changed in fuel:
importance: High → Medium
Mike Scherbakov (mihgen)
no longer affects: fuel
no longer affects: fuel/6.1.x
Changed in fuel:
status: New → Won't Fix
importance: Undecided → Medium
milestone: none → 6.1
Revision history for this message
Dennis Dmitriev (ddmitriev) wrote :

Issue was resolved in https://bugs.launchpad.net/fuel/+bug/1466853 , so mark this one as duplicate

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.