yahoo-eng-team team mailing list archive

[Ihar Hrachyshka <1753209@xxxxxxxxxxxxxxxxxx>]

So the reason of failure here is that one test case uses a network that
was temporarily shared with all tenants while running a RBAC test case.
When the network is for a short span of time shared with everyone, the
other test case -
VolumesSnapshotTestJSON:test_snapshot_create_delete_with_volume_in_use -
creates an instance with the following request body:

    Body: {"server": {"flavorRef": "e443576a-50cd-4023-88e0-574b1ec1726e", "name": "tempest-VolumesSnapshotTestJSON-instance-1302082485", "imageRef": "9a98ccb7-cd30-43da-85a9-5cfd8126c5ae"}}
which, as you can see, doesn't specify network to use, so nova then apparently picks one of available networks to boot the instance on, and it happens to be the network that was momentarily shared in RBAC test case.

I don't think that the Volumes test case should rely on nova to pick a
network for them, and instead pre-create a tenant network for this
specific test case and then boot the instance on it. By doing so, we
will avoid the race condition between those test cases b/c Volumes test
case won't touch the shared network and create VIF ports on it.

This is probably a bug for cinder folks to solve since the offending
test case is in VolumesSnapshot class.

One thing to mull over on neutron side though is whether the rbac test
case, as written, could reduce its impact. One thing to consider is that
the network that is momentarily shared with everyone will pop up for all
tenants, incl. those unaware of tempest running in background. Since
some operators execute tempest periodically against their cloud, they
probably don't want their customers to get random networks popping up
for a brief moment. Though the RBAC test case explicitly validates the
wildcard RBAC behavior so not sure if we can easily get rid of it w/o
loosing some coverage.

How does tempest core team look at such cases? Do we forbid any impact
on other cloud users? If so, we could probably shorten the neutron api
case to avoid it, even if it means a particular use case won't be
covered with tempest.

** Also affects: neutron
   Importance: Undecided
       Status: New

** Also affects: tempest
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1753209

Title:
  neutron_tempest_plugin.api.admin.test_shared_network_extension.RBACSharedNetworksTest,
  rbac policy in use across tenants.

Status in neutron:
  New
Status in tempest:
  New
Status in tripleo:
  Triaged

Bug description:
  neutron_tempest_plugin.api.admin.test_shared_network_extension.RBACSharedNetworksTest
  failure

  https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci-
  centos-7-ovb-1ctlr_1comp-featureset020-master/6cec620/tempest.html.gz

  Details: {u'message': u'RBAC policy on object 3cfbd0a7-84f2-4e3f-917e-
  bf51b5995e20 cannot be removed because other objects depend on
  it.\nDetails: Callback
  neutron.plugins.ml2.plugin.Ml2Plugin.validate_network_rbac_policy_change
  --9223372036850840529 failed with "Unable to reconfigure sharing
  settings for network 3cfbd0a7-84f2-4e3f-917e-bf51b5995e20. Multiple
  tenants are using it.",Callback
  neutron.services.network_ip_availability.plugin.NetworkIPAvailabilityPlugin.validate_network_rbac_policy_change
  --9223372036853400817 failed with "Unable to reconfigure sharing
  settings for network 3cfbd0a7-84f2-4e3f-917e-bf51b5995e20. Multiple
  tenants are using it.",Callback
  neutron.services.network_ip_availability.plugin.NetworkIPAvailabilityPlugin.validate_network_rbac_policy_change
  --9223372036853463713 failed with "Unable to reconfigure sharing
  settings for network 3cfbd0a7-84f2-4e3f-917e-bf51b5995e20. Multiple
  tenants are using it."', u'type': u'RbacPolicyInUse', u'detail': u''}

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