Red Hat Bugzilla – Bug 1279503
config_tempest.py does not yield a functional networking environment with Packstack
Last modified: 2015-12-07 10:16:54 EST
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:
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:
When provisioning the demo resources through packstack, it will take care of creating these:
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):
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
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:
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 \
identity.uri http://192.168.1.202:5000/v2.0/ \
compute.allow_tenant_isolation true \
object-storage.operator_role SwiftOperator \
identity.admin_password redhat \
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?
(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 .
If you have any ideas I'd love to hear them.
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)
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.