Activity log for bug #1780780

Date Who What changed Old value New value Message
2018-07-09 12:59:17 Ronelle Landy bug added bug
2018-07-09 12:59:29 Ronelle Landy tags ci
2018-07-09 12:59:55 Ronelle Landy tripleo: milestone rocky-3
2018-07-09 12:59:58 Ronelle Landy tripleo: importance Undecided High
2018-07-09 13:00:06 Ronelle Landy tripleo: status New Triaged
2018-07-09 13:01:18 Ronelle Landy description Tempest test test_network_basic_ops running on master with scenario008 and scenario008 jobs fails with networking/connection issues: http://logs.openstack.org/53/579653/3/check/tripleo-ci-centos-7-scenario008-multinode-oooq-container/5e299dc/logs/undercloud/home/zuul/tempest/tempest.html.gz The problem stems from that fact that we now set up br-ex using pre.yaml from zuul-jobs which relies on a released version of openvswitch: https://github.com/openstack-infra/zuul-jobs/blob/master/roles/multi-node-bridge/vars/RedHat.yaml#L4 https://github.com/openstack-infra/zuul-jobs/blob/master/roles/multi-node-bridge/tasks/common.yaml#L21 The role defaulted to the ocata version - hence the incompatibility with master deployments. I was able to get the scenario007 to pass in my local reproducer environment when using the released queens version of openvswitch. The methodology here is problematic. If we plan to test TripleO integration with OVS, and we only bring in the change with the run playbooks, the pre playbooks will set up with the released version and we will never test what is being changed - or even what is in the master repos. When you used a role in tripleo-quickstart-extras to create br-ex, an updated OVS version was already available to be used in the test. Tempest test test_network_basic_ops running on master with scenario007 and scenario008 jobs fails with networking/connection issues: http://logs.openstack.org/53/579653/3/check/tripleo-ci-centos-7-scenario008-multinode-oooq-container/5e299dc/logs/undercloud/home/zuul/tempest/tempest.html.gz The problem stems from that fact that we now set up br-ex using pre.yaml from zuul-jobs which relies on a released version of openvswitch: https://github.com/openstack-infra/zuul-jobs/blob/master/roles/multi-node-bridge/vars/RedHat.yaml#L4 https://github.com/openstack-infra/zuul-jobs/blob/master/roles/multi-node-bridge/tasks/common.yaml#L21 The role defaulted to the ocata version - hence the incompatibility with master deployments. I was able to get the scenario007 to pass in my local reproducer environment when using the released queens version of openvswitch. The methodology here is problematic. If we plan to test TripleO integration with OVS, and we only bring in the change with the run playbooks, the pre playbooks will set up with the released version and we will never test what is being changed - or even what is in the master repos. When you used a role in tripleo-quickstart-extras to create br-ex, an updated OVS version was already available to be used in the test.
2018-07-09 13:32:08 wes hayutin tags ci alert ci promotion-blocker
2018-07-10 11:21:09 Alan Pevec bug watch added https://github.com/rdo-infra/rdo-release/issues/10
2018-07-11 21:04:29 wes hayutin tripleo: status Triaged Fix Released