Bug 1279503

Summary: config_tempest.py does not yield a functional networking environment with Packstack
Product: Red Hat OpenStack Reporter: David Moreau Simard <dmsimard>
Component: openstack-tempestAssignee: David Kranz <dkranz>
Status: CLOSED NOTABUG QA Contact: tkammer
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: apevec, dmellado, dmsimard, lhh, slinaber
Target Milestone: ---   
Target Release: 8.0 (Liberty)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-10 20:41:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
config_tempest.py run output none

Description David Moreau Simard 2015-11-09 15:22:00 UTC 
I am trying to get Packstack CI jobs driven by Khaleesi and config_tempest.py to pass 100% of smoke tests (and beyond). However, it looks like there are several bits missing from how Tempest provisions it's demo resources -- at least when compared with Packstack demo provision.

I am using the rebased-upstream branch which is our fork of Tempest rebased against Liberty upstream:
https://github.com/redhat-openstack/tempest/blob/rebased-upstream/tools/config_tempest.py

config_tempest.py will do several things like create the cirros images, create the demo user and tenant but it does not:
1) Create an internal network for the demo user
2) Create a virtual router for the demo user

The function that takes care of configuring the networks seems to be here:
https://github.com/redhat-openstack/tempest/blob/e01917ce84cc85c3cff084920532a8e6b076d9d6/tools/config_tempest.py#L581-L630

When provisioning the demo resources through packstack, it will take care of creating these:
https://github.com/openstack/packstack/blob/2aea06b913aef8bd5dec1e044d24941b2b6b22e9/packstack/puppet/templates/provision_demo.pp

and it will also setup not only the required ovs bridge but also the required firewall rules for NAT to work properly (although this is outside the scope of this bug - packstack should be able to configure these rules without having to provision demo or tempest):
https://github.com/openstack/packstack/blob/2aea06b913aef8bd5dec1e044d24941b2b6b22e9/packstack/puppet/templates/provision_demo_bridge.pp

There is also another problem, which might be within scope of this bug report - the default security groups do not allow TCP 22 (SSH) and ICMP (Ping) - this means that tests run from outside of the security group will fail.

Here is another example of how demo resources are provisioned in the context of CI: https://github.com/openstack/puppet-openstack-integration/blob/ccf9efb43ee8dcc233a4f6bad822ef8a96a6301b/fixtures/scenario001.pp#L353-L463
Comment 2 David Moreau Simard 2015-11-09 15:25:07 UTC 
Created attachment 1091798 [details]
config_tempest.py run output

This is the output of config_tempest.py through ./with_venv configure_tempest.sh.

Configure tempest.sh is below:

#!/bin/bash

python tools/config_tempest.py \
  --image http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img \
  --out etc/tempest.conf \
  --debug  \
  --create \
    identity.uri http://192.168.1.202:5000/v2.0/ \
  compute.allow_tenant_isolation true \
  object-storage.operator_role SwiftOperator \
  identity.admin_password redhat \
  identity.password secrete
Comment 3 David Kranz 2015-11-09 15:34:18 UTC 
The code that creates demo tenants was designed in the nova network world and has never worked with neutron. However, the demo tenant is never used by tempest unless allow_tenant_isolation is set to false. The demo tenant as part of tempest configuration is being deprecated in favor of the "test accounts" feature which allows you to create multiple test accounts that can be used as an alternative to tenant isolation. The code in config_tempest.py that creates these demo users is in the process of being removed, and code to configure the test accounts option is being added. 

Was this bug report the result of some tempest run failing, or just the observation that the demo tenant is not being created properly for neutron?
Comment 4 David Moreau Simard 2015-11-09 15:45:56 UTC 
(In reply to David Kranz from comment #3)
> The code that creates demo tenants was designed in the nova network world
> and has never worked with neutron. However, the demo tenant is never used by
> tempest unless allow_tenant_isolation is set to false. The demo tenant as
> part of tempest configuration is being deprecated in favor of the "test
> accounts" feature which allows you to create multiple test accounts that can
> be used as an alternative to tenant isolation. The code in config_tempest.py
> that creates these demo users is in the process of being removed, and code
> to configure the test accounts option is being added. 
> 
> Was this bug report the result of some tempest run failing, or just the
> observation that the demo tenant is not being created properly for neutron?

This is not so much a bug report as it is a request for enhancement to allow config_tempest.py to yield network configuration that works on the tenant side.

As a CI developer, I'm currently left without any solutions to get a packstack environment with ovs/neutron/ml2-vxlan to work properly with Khaleesi.

The closest I've gotten things to work was to bypass config_tempest.py completely and instead provision both demo resources and tempest through packstack. Tempest is mostly broken through packstack right now though a review is in progress to fix that [1].

If you have any ideas I'd love to hear them.

[1]: https://review.openstack.org/#/c/237781/
Comment 10 David Moreau Simard 2015-11-10 19:35:36 UTC 
I should also mention that a manual packstack --allinone --provision-demo=y yields reachable virtual machines if and only if TCP22 and ICMP are allowed in the default security groups (see my review that discusses this here: https://review.gerrithub.io/#/c/250321/)

This might or might not be related, I don't know if Tempest configures the security groups of the newly configured tenants with tenant isolation enabled (I guess it would)
Comment 11 David Kranz 2015-11-10 19:45:59 UTC 
It does, but only if the new tenant is created on behalf of a test class that needs to connect to a vm. So a test class that creates a bunch of volumes will not have any security group changes.