<div dir="ltr">Hi Sagi,<br><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 5:56 PM, Sagi Shnaidman <span dir="ltr"><<a href="mailto:sshnaidm@redhat.com" target="_blank">sshnaidm@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi, all<br><br></div>I'd like to discuss the topic about how do we configure tempest in CI jobs for TripleO.<br></div>I have currently two patches:<br></div>support for tempest: <a href="https://review.openstack.org/#/c/295844/" target="_blank">https://review.openstack.org/#/c/295844/</a><br></div>actually run of tests: <a href="https://review.openstack.org/#/c/297038/" target="_blank">https://review.openstack.org/#/c/297038/</a><br><br></div><div>Right now there is no upstream tool to configure tempest, so everybody use their own tools. </div></div></blockquote><div><br></div><div>You are wrong. There is Rally in upstream:) <br>Basic and <span id="result_box" class="" lang="en"><span class="">the most widely used Rally component is Task, which provides benchmarking and testing tool. <br>But, also, Rally has Verification component(<a href="https://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/">here</a> you can find is a bit outdated blog-post, but it can introduce Verification component for you).</span></span><br></div>It can:<br><br><div style="margin-left:40px">1. Configure Tempest based on public OpenStack API. <br></div><div style="margin-left:40px">An example of config from our gates: <a href="http://logs.openstack.org/58/285758/5/check/gate-rally-dsvm-verify-full/eabe2ff/rally-verify/5_verify_showconfig.txt.gz">http://logs.openstack.org/58/285758/5/check/gate-rally-dsvm-verify-full/eabe2ff/rally-verify/5_verify_showconfig.txt.gz</a> . Empty options mean that rally will check these resources while running tempest and create it if necessary)<br><br>2. Launch set of tests, tests which match regexp, list of tests. Also, it supports x-fail mechanism from out of box. <br>An example of full run based on config file posted above - <a href="http://logs.openstack.org/58/285758/5/check/gate-rally-dsvm-verify-full/eabe2ff/rally-verify/7_verify_results.html.gz">http://logs.openstack.org/58/285758/5/check/gate-rally-dsvm-verify-full/eabe2ff/rally-verify/7_verify_results.html.gz</a><br><br></div><div style="margin-left:40px">3. Compare results. <br><a href="http://logs.openstack.org/58/285758/5/check/gate-rally-dsvm-verify-light/d806b91/rally-verify/17_verify_compare_--uuid-1_9fe72ea8-bd5c-45eb-9a37-5e674ea5e5d4_--uuid-2_315843d4-40b8-46f2-aa69-fb3d5d463379.html.gz">http://logs.openstack.org/58/285758/5/check/gate-rally-dsvm-verify-light/d806b91/rally-verify/17_verify_compare_--uuid-1_9fe72ea8-bd5c-45eb-9a37-5e674ea5e5d4_--uuid-2_315843d4-40b8-46f2-aa69-fb3d5d463379.html.gz</a> It is not so good-looking as other rally reports, but we will fix it someday:)<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Summarize:<br></div><div class="gmail_quote">- Rally is an upstream tool, which was accepted to BigTent.<br></div><div class="gmail_quote"><div>- One instance of Rally can manage and run tempest for different number of clouds <br></div><div>- Rally Verification component is tested in gates for every new patch. Also it supports different APIs of services.<br></div><div>- You can install, configure, launch, store results, display results in different formats.<br><br></div><div>Btw, we are planning to refactor verification component(there is an spec on review with several +2), so you will be able to launch whatever you want subunit-based tools via Rally and simplify usage of it.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>However it's planned and David Mellado is working on it AFAIK. <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Till then everybody use their own tools for tempest configuration.<br></div><div>I'd review two of them:<br></div><div>1) Puppet configurations that is used in puppet modules CI<br></div><div>2) Using configure_tempest.py script from <a href="https://github.com/redhat-openstack/tempest/blob/master/tools/config_tempest.py" target="_blank">https://github.com/redhat-openstack/tempest/blob/master/tools/config_tempest.py</a><br></div><div><div><div><div><div><div><br></div><div>Unfortunately there is no ready puppet module or script, that configures tempest, you need to create your own. <br><br>On other hand the config_tempest.py script provides full configuration, support for tempest-deployer-input.conf and possibility to add any config options in the command line when running it: <br><br><span style="font-family:monospace,monospace"><font size="1">python config_tempest.py \<br>        --out etc/tempest.conf \<br>        --debug \<br>        --create \<br>        --deployer-input ~/tempest-deployer-input.conf \<br>        identity.uri $OS_AUTH_URL \<br>        compute.allow_tenant_isolation true \<br>        identity.admin_password $OS_PASSWORD \<br>        compute.build_timeout 500 \<br>        compute.image_ssh_user cirros</font></span><br></div><div><br>Also it uploads images, creates necessary roles, etc. The only thing it requires - existence of public network.<br></div><div>So finally all tempest configuration from scratch will be like:<br> <font size="1"><span style="font-family:monospace,monospace"> <br></span></font></div><div><font size="1"><span style="font-family:monospace,monospace">CONFIGURE_TEMPEST_DIR="$(ls /usr/share/openstack-tempest-*/tools/configure-tempest-directory)"<br>$CONFIGURE_TEMPEST_DIR<br>neutron net-create nova --shared --router:external=True --provider:network_type flat --provider:physical_network datacentre;<br>neutron subnet-create --name ext-subnet --allocation-pool start=$FLOATING_IP_START,end=$FLOATING_IP_END --disable-dhcp --gateway $EXTERNAL_NETWORK_GATEWAY nova $FLOATING_IP_CIDR;<br>python tempest/tools/install_venv.py<br>python config_tempest.py \<br>        --out etc/tempest.conf \<br>        --debug \<br>        --create \<br>        --deployer-input ~/tempest-deployer-input.conf \<br>        identity.uri $OS_AUTH_URL \<br>        compute.allow_tenant_isolation true \<br>        identity.admin_password $OS_PASSWORD \<br>        compute.build_timeout 500 \<br>        compute.image_ssh_user cirros<br></span></font></div><div><font size="1"><span style="font-family:monospace,monospace">testr init; testr run<br></span></font></div><div><br></div><div>In my patch [1] I have proposed it with little changes to TripleO CI repo [2]<br></div><div><br></div><div>Like I wrote before there is an option to use puppet for this, I spent a time to investigate how to do it and would like share the results with your in order to compare it with config_tempest.py approach.<br><br>First of all it's surprising that 
puppet-tempest actually doesn't know to do almost anything. All it knows
 - it's to set IDs of public network (but not router) and images. That's 
all. All the rest you need to configure manually.<br><div>Then 
comes another problem - you can use it only on overcloud controller 
node, where are all service configurations and hiera data. Most of 
values are taken directly from /etc/{service}/service.conf files, so 
doing it on undercloud you will configure undercloud itself (instead of 
overcloud)<br><br></div><div>So first of all you need to upload this manifest to controller node of overcloud.<br></div><div>Let's
 write this puppet manifest, I wrote everything in one file for saving a
 time, but of course it should be a module with usual puppet module 
structure: module_name/manifests/init.pp with module_name class.<br><br></div><div>Manual configurations:<br></div><div><br><span style="color:rgb(153,0,255)"><font size="1"><span style="font-family:monospace,monospace">class testt::config {<br>  $os_username = 'admin'<br>  $os_tenant_name = hiera(keystone::roles::admin::admin_tenant)<br>  $os_password = hiera(admin_password)<br>  $os_auth_url = hiera(keystone::endpoint::public_url)<br>  $keystone_auth_uri = regsubst($os_auth_url, '/v2.0', '')<br>  $floating_range       = "<a href="http://192.0.2.0/24" target="_blank">192.0.2.0/24</a>"<br>  $gateway_ip           = "192.0.2.1"<br>  $floating_pool        = 'start=192.0.2.50,end=192.0.2.99'<br>  $fixed_range          = '<a href="http://10.0.0.0/24" target="_blank">10.0.0.0/24</a>'<br>  $router_name          = 'router1'<br>  $ca_bundle_cert_path = '/etc/ssl/certs/ca-bundle.crt'<br>  $cert_path           = '/etc/pki/ca-trust/source/anchors/puppet_openstack.pem'<br>  $update_ca_certs_cmd = '/usr/bin/update-ca-trust force-enable && /usr/bin/update-ca-trust extract'<br>  $host_url = regsubst($keystone_auth_uri, ':5000', '')<br>}</span></font></span><br><br></div><div>Most of data is taken from hiera on the controller host. (/etc/hieradata)<br></div><div>Then
 we start actually the tempest configuration. Surprisingly it doesn't 
have resource type to work with flavors, so all its configuration is 
done by "exec"s. We run puppet with bash to run bash within a puppet, what gives pretty big overhead.<br><br><span style="color:rgb(153,0,255)"><font size="1"><span style="font-family:monospace,monospace">class testt::provision {<br>  include testt::config<br><br> 
 $os_auth_options = "--os-username ${config::os_username} --os-password 
${config::os_password} --os-tenant-name ${config::os_tenant_name} 
--os-auth-url ${config::os_auth_url}/v2.0"<br><br>  exec { 'manage_m1.nano_nova_flavor':<br>    path     => '/usr/bin:/bin:/usr/sbin:/sbin',<br>    provider => shell,<br> 
   command  => "nova ${os_auth_options} flavor-delete m1.nano ||: ; 
nova ${os_auth_options} flavor-create m1.nano pup_tempest_custom_nano 
128 0 1",<br>    unless   => "nova ${os_auth_options} flavor-list | grep pup_tempest_custom_nano",<br>  }<br><br>  exec { 'manage_m1.micro_nova_flavor':<br>    path     => '/usr/bin:/bin:/usr/sbin:/sbin',<br>    provider => shell,<br> 
   command  => "nova ${os_auth_options} flavor-delete m1.micro ||: 
;nova ${os_auth_options} flavor-create m1.micro pup_tempest_custom_micro
 128 0 1",<br>    unless   => "nova ${os_auth_options} flavor-list | grep pup_tempest_custom_micro",<br>  }</span></font></span><br><br></div><div>Then we create public and private networks, and router between them:<br><font size="1"><span style="font-family:monospace,monospace"><span style="color:rgb(153,0,255)"><br>$neutron_deps = [Neutron_network['nova']]<br><br>neutron_network { 'nova':<br>    ensure          => 'present',<br>    router_external => true,<br>    tenant_name     => "${config::os_tenant_name}",<br>  }<br><br>neutron_subnet { 'ext-subnet':<br>  ensure           => 'present',<br>  cidr             => "${config::floating_range}",<br>  enable_dhcp      => false,<br>  allocation_pools => ["${config::floating_pool}"],<br>  gateway_ip       => "${config::gateway_ip}",<br>  network_name     => 'nova',<br>  tenant_name      => "${config::os_tenant_name}",<br>}<br><br>neutron_network { 'private':<br>    ensure      => 'present',<br>    tenant_name => "${config::os_tenant_name}",<br>  }<br><br>neutron_subnet { 'private_subnet':<br>  ensure       => 'present',<br>  cidr         => "${config::fixed_range}",<br>  network_name => 'private',<br>  tenant_name  => "${config::os_tenant_name}",<br>}<br><br>neutron_router { "${config::router_name}":<br>  ensure               => 'present',<br>  tenant_name          => "${config::os_tenant_name}",<br>  gateway_network_name => 'nova',<br>  require              => Neutron_subnet['ext-subnet'],<br>}<br>neutron_router_interface { "${config::router_name}:private_subnet":<br>  ensure => 'present',<br>}</span></span></font><br></div><div><br></div><div>After this it's a time to upload images:<br><br><span style="color:rgb(153,0,255)"><span style="font-family:monospace,monospace"><font size="1">  glance_image { 'cirros':<br>    ensure           => present,<br>    container_format => 'bare',<br>    disk_format      => 'qcow2',<br>    is_public        => 'yes',<br>    source           => '<a href="http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img" target="_blank">http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img</a>',<br>  }<br>  glance_image { 'cirros_alt':<br>    ensure           => present,<br>    container_format => 'bare',<br>    disk_format      => 'qcow2',<br>    is_public        => 'yes',<br>    source           => '<a href="http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img" target="_blank">http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img</a>',<br>  }<br></font></span></span><br></div><div>And then you run actually puppet tempest with configuration values, most of them you set by yourself:<br><span style="color:rgb(153,0,255)"><span style="font-family:monospace,monospace"><font size="1"><br>class { '::tempest':<br><br><br>debug => true,<br>use_stderr => false,<br>log_file => 'tempest.log',<br>tempest_clone_owner => $::id,<br>git_clone => true,<br>setup_venv => true,<br>tempest_clone_path => '/tmp/openstack/tempest',<br>lock_path => '/tmp/openstack/tempest',<br>tempest_config_file => '/tmp/openstack/tempest/etc/tempest.conf',<br>configure_images => true,<br>configure_networks => true,<br>allow_tenant_isolation => true,<br>identity_uri => "${testt::config::keystone_auth_uri}/v2.0",<br>identity_uri_v3 => "${testt::config::keystone_auth_uri}/v3",<br>admin_username => "${testt::config::os_username}",<br>admin_tenant_name => "${testt::config::os_tenant_name}",<br>admin_password => "${testt::config::os_password}",<br>admin_domain_name => 'Default',<br>auth_version => 'v3',<br>image_name => 'cirros',<br>image_name_alt => 'cirros_alt',<br>cinder_available => true,<br>glance_available => true,<br>horizon_available => $horizon,<br>nova_available => true,<br>neutron_available => true,<br>ceilometer_available => $ceilometer,<br>aodh_available => $aodh,<br>trove_available => $trove,<br>sahara_available => $sahara,<br>heat_available => $heat,<br>swift_available => true,<br>ironic_available => $ironic,<br>public_network_name => 'nova',<br>dashboard_url => "${testt::config::host_url}",<br>flavor_ref => 'pup_tempest_custom_nano',<br>flavor_ref_alt => 'pup_tempest_custom_micro',<br>image_ssh_user => 'cirros',<br>image_alt_ssh_user => 'cirros',<br>img_file => 'cirros-0.3.4-x86_64-disk.img',<br>compute_build_interval => 10,<br>ca_certificates_file => "${testt::config::ca_bundle_cert_path}",<br>img_dir => '/tmp/openstack/tempest',<br>}</font></span></span><br></div><div><br></div><div>But it's not enough, you need also to make some workarounds and additional configurations, for example:<br><br><span style="color:rgb(153,0,255)"><font size="1"><span style="font-family:monospace,monospace">tempest_config { 'object-storage/operator_role':<br>  value => 'SwiftOperator',<br>  path  => "${tempest_clone_path}/etc/tempest.conf",<br>}<br>}</span></font></span><br></div><div><br>After this run puppet on controller node:<br><br><span style="font-family:monospace,monospace"><font size="1"><span style="color:rgb(153,0,255)">sudo puppet apply --verbose --debug --detailed-exitcodes -e "include ::testt" | tee ~/puppet_run.log</span></font></span><br><br></div><div>After everything is finished, you need to copy the folder with tempest to your node:<br></div><div><span style="color:rgb(153,0,255)"><font size="1"><span style="font-family:monospace,monospace">scp -r -heat-admin@${CONTROLLER}:/tmp/openstack /tmp/</span></font></span><br><br></div><div>After this run within this directory testr init and run tests:<br><span style="color:rgb(153,0,255)"><font size="1"><span style="font-family:monospace,monospace">/tmp/tempest/tools/with_venv.sh testr init<br>/tmp/tempest/tools/with_venv.sh testr run </span></font></span><br></div><div><br></div>There
 are still holes in this configuration and most likely you'd fix it by 
another workarounds and tempest_config runs, because it's still a few of
 skipped tests, so configuration is not full as it would be done with 
config_tempest.py.<br></div><div>You don't have also any possibility to add custom configuration in running the manifest, for each config change you need to change the manifest itself which makes it maintenance harder and more complex. <br></div><div><br>I would say that conclusion is quite obvious for me 
and it's much easier even to write tempest.conf manually from 
scratch or simple template and use 5 bash lines, then use puppet for things it's completely
 not fit to.<br><br><div>P.S. In this script I used ideas from puppet-openstack-integration and packstack projects.<br><br>[1] <a href="https://review.openstack.org/#/c/295844/" target="_blank">https://review.openstack.org/#/c/295844/</a><br>[2] <a href="https://git.openstack.org/openstack-infra/tripleo-ci" target="_blank">https://git.openstack.org/openstack-infra/tripleo-ci</a><span><font color="#888888"><br><br>-- <br></font></span></div><span><font color="#888888"><div><div dir="ltr"><div>Best regards<br></div>Sagi Shnaidman<br></div></div>
</font></span></div></div></div></div></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr">Best regards,<br>Andrey Kurilin.<br></div></div>
</div></div>