)]}'
{"id":"openstack%2Fnova~623543","triplet_id":"openstack%2Fnova~master~I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a","project":"openstack/nova","branch":"master","topic":"bp/bandwidth-resource-provider","hashtags":[],"change_id":"I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a","subject":"Ensure that bandwidth and VF are from the same PF","status":"MERGED","created":"2018-12-07 16:18:19.000000000","updated":"2019-03-06 04:03:59.000000000","submitted":"2019-03-06 00:08:01.000000000","submitter":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"total_comment_count":91,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"623543-1551830882234-1d1e633c","meta_rev_id":"039f12bb2e1bdc81d7f79c968b00db759ce75d55","_number":623543,"virtual_id_number":623543,"owner":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"actions":{},"labels":{"Verified":{"approved":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"value":0,"date":"2019-03-05 17:36:51.000000000","_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},{"value":0,"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},{"value":0,"date":"2019-03-06 04:03:59.000000000","post_submit":true,"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},{"value":0,"date":"2019-03-05 20:51:41.000000000","_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"value":0,"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"value":0,"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},{"value":0,"_account_id":8871,"name":"Elastic Recheck","username":"elasticrecheck"},{"value":0,"date":"2019-03-05 18:36:43.000000000","permitted_voting_range":{"min":0,"max":1},"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},{"value":0,"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},{"value":0,"_account_id":12171,"name":"Moshe Levi","email":"moshele@nvidia.com","username":"moshele"},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":2,"date":"2019-03-06 00:08:01.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"date":"2019-03-05 22:48:26.000000000","_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"value":0,"date":"2019-03-05 22:00:41.000000000","_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},{"value":0,"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"value":0,"date":"2019-03-05 19:53:17.000000000","_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"date":"2019-03-05 16:53:49.000000000","_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":0,"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","default_value":0,"optional":true},"Code-Review":{"approved":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"all":[{"value":0,"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},{"value":0,"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},{"value":0,"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},{"value":0,"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"value":2,"date":"2019-03-05 17:53:36.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"value":0,"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},{"value":0,"_account_id":8871,"name":"Elastic Recheck","username":"elasticrecheck"},{"value":0,"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},{"value":0,"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},{"value":0,"_account_id":12171,"name":"Moshe Levi","email":"moshele@nvidia.com","username":"moshele"},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"value":0,"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},{"value":0,"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":2,"date":"2019-03-05 16:53:18.000000000","permitted_voting_range":{"min":2,"max":2},"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"}],"values":{"-2":"Do not merge","-1":"This patch needs further work before it can be merged"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me (core reviewer)"},"description":"","default_value":0,"optional":true},"Workflow":{"approved":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"all":[{"value":0,"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},{"value":0,"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},{"value":0,"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},{"value":0,"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"value":1,"date":"2019-03-05 17:53:36.000000000","permitted_voting_range":{"min":1,"max":1},"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"value":0,"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},{"value":0,"_account_id":8871,"name":"Elastic Recheck","username":"elasticrecheck"},{"value":0,"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},{"value":0,"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},{"value":0,"_account_id":12171,"name":"Moshe Levi","email":"moshele@nvidia.com","username":"moshele"},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"value":0,"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},{"value":0,"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":0,"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true},"Review-Priority":{"all":[{"value":0,"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},{"value":0,"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},{"value":0,"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},{"value":0,"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"value":0,"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"value":0,"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},{"value":0,"_account_id":8871,"name":"Elastic Recheck","username":"elasticrecheck"},{"value":0,"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},{"value":0,"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},{"value":0,"_account_id":12171,"name":"Moshe Levi","email":"moshele@nvidia.com","username":"moshele"},{"value":0,"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"value":0,"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},{"value":0,"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"value":0,"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"value":0,"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":0,"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"}],"values":{" 0":"Default Priority","+1":"Contributor Review Promise","+2":"Core Review Promise"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"_account_id":8871,"name":"Elastic Recheck","username":"elasticrecheck"},{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":12171,"name":"Moshe Levi","email":"moshele@nvidia.com","username":"moshele"},{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2018-12-08 09:46:59.000000000","updated_by":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"reviewer":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"state":"REVIEWER"},{"updated":"2018-12-11 19:27:48.000000000","updated_by":{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},"reviewer":{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2018-12-11 19:32:34.000000000","updated_by":{"_account_id":8871,"name":"Elastic Recheck","username":"elasticrecheck"},"reviewer":{"_account_id":8871,"name":"Elastic Recheck","username":"elasticrecheck"},"state":"REVIEWER"},{"updated":"2018-12-13 14:46:35.000000000","updated_by":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"reviewer":{"_account_id":28714,"name":"Adrian Chiris","email":"adrianc@nvidia.com","username":"adrianc"},"state":"REVIEWER"},{"updated":"2018-12-16 14:12:32.000000000","updated_by":{"_account_id":12171,"name":"Moshe Levi","email":"moshele@nvidia.com","username":"moshele"},"reviewer":{"_account_id":12171,"name":"Moshe Levi","email":"moshele@nvidia.com","username":"moshele"},"state":"REVIEWER"},{"updated":"2019-01-14 19:27:46.000000000","updated_by":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"reviewer":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-01-14 22:26:26.000000000","updated_by":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"reviewer":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-02-08 01:07:13.000000000","updated_by":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"reviewer":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"state":"REVIEWER"},{"updated":"2019-03-04 15:44:09.000000000","updated_by":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"reviewer":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-03-05 04:16:25.000000000","updated_by":{"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},"reviewer":{"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-03-05 13:49:54.000000000","updated_by":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"reviewer":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"state":"REVIEWER"},{"updated":"2019-03-05 14:57:13.000000000","updated_by":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"reviewer":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"state":"REVIEWER"},{"updated":"2019-03-05 16:53:49.000000000","updated_by":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"reviewer":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-03-05 17:36:51.000000000","updated_by":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"reviewer":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-03-05 17:53:36.000000000","updated_by":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"reviewer":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"state":"REVIEWER"},{"updated":"2019-03-05 18:36:43.000000000","updated_by":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"reviewer":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"state":"REVIEWER"},{"updated":"2019-03-05 19:53:17.000000000","updated_by":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"reviewer":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"state":"REVIEWER"},{"updated":"2019-03-05 20:51:41.000000000","updated_by":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"reviewer":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-03-05 22:00:41.000000000","updated_by":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"reviewer":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-03-05 22:48:26.000000000","updated_by":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"reviewer":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-03-06 00:08:01.000000000","updated_by":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"reviewer":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-03-06 04:03:59.000000000","updated_by":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"reviewer":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"state":"REVIEWER"}],"messages":[{"id":"b6a30a520a5195a14a706acbf497c7713022858e","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-07 16:18:19.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"ef75366ae4b534019de4dc84eb62e9f04cfc9221","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-07 16:18:56.000000000","message":"Patch Set 1: Workflow-1","accounts_in_message":[],"_revision_number":1},{"id":"42288ad664c5e9c9a120d5d7bdddfa23ee04425e","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-07 16:21:03.000000000","message":"Patch Set 1:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":1},{"id":"ce6d933dccbf2ab69e9c6e5136de8281beacfa53","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-07 16:48:00.000000000","message":"Patch Set 1:\n\n* pci-test http://52.27.155.124/pci/623543/1 : SUCCESS","accounts_in_message":[],"_revision_number":1},{"id":"fa992b3ea3c496677fb40bad348ff6d89fda474a","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-07 17:24:42.000000000","message":"Patch Set 1:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-25878 : SUCCESS in 1h 01m 46s","accounts_in_message":[],"_revision_number":1},{"id":"98f6372ff09c4bd3aca4789f04bb7c7ac68f91aa","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-07 17:35:27.000000000","message":"Patch Set 1:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/1/check/tempest-dsvm-full-xenial/d148a54/ : SUCCESS in 1h 08m 25s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/1/check/tempest-dsvm-full-xenial-py3/e1e7c0b/ : SUCCESS in 1h 14m 44s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/1/check/grenade-dsvm-xenial/4ab7b1f/ : SUCCESS in 52m 12s (non-voting)","accounts_in_message":[],"_revision_number":1},{"id":"4e193a6d96d316a8c52a180b0f624fcb16185afd","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2018-12-07 17:42:39.000000000","message":"Patch Set 1:\n\nTesting failed ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenial-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/1/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/51ca6ce : FAILURE in 1h 11m 52s","accounts_in_message":[],"_revision_number":1},{"id":"36c57b02aaedb8d325464315ea684ad2c3d4dfeb","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2018-12-07 18:13:20.000000000","message":"Patch Set 1:\n\nBuild succeeded.\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/1/check/nova-out-of-tree-pvm/dd7858d : SUCCESS in 1h 53m 18s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/1/check/nova-in-tree-pvm/0016398 : SUCCESS in 1h 50m 27s","accounts_in_message":[],"_revision_number":1},{"id":"dab9b4a7bf5e29af417def7e37af9c1a281a5a3e","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-07 18:15:49.000000000","message":"Patch Set 1:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/1 : SUCCESS in 1h 54m 29s","accounts_in_message":[],"_revision_number":1},{"id":"810601d47cd1f6b563629580847a5951b0ceb86f","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2018-12-07 19:12:27.000000000","message":"Patch Set 1:\n\nBuild failed.  To recheck use \u0027xenserver: recheck\u0027.  For 3rd party ci contact info: https://wiki.openstack.org/wiki/ThirdPartySystems\n\n- dsvm-tempest-neutron-network http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/43/623543/1/check/dsvm-tempest-neutron-network/101420f : FAILURE in 2h 48m 52s\n- test-vgpu http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/43/623543/1/check/test-vgpu/16ad7e0 : FAILURE in 31m 32s (non-voting)","accounts_in_message":[],"_revision_number":1},{"id":"bccac8710176761db62e54808c245f35fa1689e7","author":{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},"date":"2018-12-07 19:16:09.000000000","message":"Patch Set 1:\n\nBuild succeeded.\n\n- check-dsvm-tempest-vz7-exe-minimal http://openstack-3rd-party-virtuozzo-ci-logs.virtuozzo.com/43/623543/1/check/check-dsvm-tempest-vz7-exe-minimal/13d69e2 : SUCCESS in 1h 05m 09s\n\nFor information, see https://wiki.openstack.org/wiki/ThirdPartySystems/Virtuozzo_CI Make the comment \u0027run-Virtuozzo CI\u0027 to recheck","accounts_in_message":[],"_revision_number":1},{"id":"9e1f8af267c170904e609bc9a941ba6f5d9b1834","author":{"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},"date":"2018-12-07 20:31:59.000000000","message":"Patch Set 1:\n\nBuild succeeded.\n\n- Nova-ML2-Sriov http://13.74.249.42/43/623543/1/check-nova/Nova-ML2-Sriov/a2a91c7 : FAILURE in 25m 29s (non-voting)\n- Nova-MACVTAP-ML2-Sriov http://13.74.249.42/43/623543/1/check-nova/Nova-MACVTAP-ML2-Sriov/1abc32e : SUCCESS in 57m 29s (non-voting)\n\nTo re-run the job post \u0027recheck nova-mlnx\u0027 comment. For more information visit https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI","accounts_in_message":[],"_revision_number":1},{"id":"51404cd012e1497284e685367867d9447f976c23","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-08 00:36:46.000000000","message":"Patch Set 1: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/1/check/tempest-full/b4fc754/ : SUCCESS in 1h 57m 03s\n- neutron-grenade http://logs.openstack.org/43/623543/1/check/neutron-grenade/a2598c4/ : SUCCESS in 1h 04m 38s\n- grenade-py3 http://logs.openstack.org/43/623543/1/check/grenade-py3/9d8609b/ : SUCCESS in 1h 07m 50s\n- tempest-full-py3 http://logs.openstack.org/43/623543/1/check/tempest-full-py3/dce1333/ : SUCCESS in 1h 22m 11s\n- openstack-tox-cover http://logs.openstack.org/43/623543/1/check/openstack-tox-cover/f82c511/cover/ : SUCCESS in 16m 49s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/1/check/openstack-tox-lower-constraints/3b9aad8/ : SUCCESS in 19m 52s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/1/check/openstack-tox-pep8/008516d/ : FAILURE in 9m 04s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/1/check/openstack-tox-py27/1ba8d7b/ : SUCCESS in 14m 09s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/1/check/openstack-tox-py35/91242f8/ : SUCCESS in 15m 04s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/1/check/openstack-tox-py36/1bbbe59/ : SUCCESS in 12m 09s\n- openstack-tox-docs http://logs.openstack.org/43/623543/1/check/openstack-tox-docs/40ecc99/html/ : SUCCESS in 8m 24s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/1/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/53da2c7/ : SUCCESS in 43m 03s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/1/check/devstack-plugin-ceph-tempest/c9c7eab/ : TIMED_OUT in 2h 09m 54s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/1/check/legacy-grenade-dsvm-neutron-multinode-live-migration/9eb4ab2/ : SUCCESS in 1h 12m 25s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/1/check/neutron-grenade-multinode/7a4c0a0/ : SUCCESS in 1h 04m 42s\n- neutron-tempest-linuxbridge http://logs.openstack.org/43/623543/1/check/neutron-tempest-linuxbridge/73f020f/ : SUCCESS in 1h 33m 20s\n- nova-cells-v1 http://logs.openstack.org/43/623543/1/check/nova-cells-v1/9c87551/ : SUCCESS in 1h 05m 58s\n- nova-live-migration http://logs.openstack.org/43/623543/1/check/nova-live-migration/8d18960/ : SUCCESS in 40m 25s\n- nova-multiattach http://logs.openstack.org/43/623543/1/check/nova-multiattach/dc9bf1a/ : SUCCESS in 1h 08m 01s\n- nova-next http://logs.openstack.org/43/623543/1/check/nova-next/4b8fda1/ : SUCCESS in 1h 30m 53s\n- nova-tox-functional http://logs.openstack.org/43/623543/1/check/nova-tox-functional/807f7f5/ : FAILURE in 19m 59s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/1/check/nova-tox-functional-py35/c2ddfa1/ : FAILURE in 19m 25s\n- tempest-multinode-full http://logs.openstack.org/43/623543/1/check/tempest-multinode-full/9897dd9/ : SUCCESS in 1h 49m 09s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/1/check/tempest-slow/086e427/ : SUCCESS in 2h 09m 28s","accounts_in_message":[],"_revision_number":1},{"id":"f297f2b0b4b8a6fdde92766d38661cde67556721","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-10 09:43:58.000000000","message":"Uploaded patch set 2: Patch Set 1 was rebased.","accounts_in_message":[],"_revision_number":2},{"id":"096e0d31e3184dec662cd9e69b0f13f8d27893ba","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-10 10:01:25.000000000","message":"Patch Set 2:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":2},{"id":"0610f60d435442c6d546e9f7764b5661f5087d5b","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-10 10:54:28.000000000","message":"Patch Set 2:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/2 : FAILURE in 6m 40s","accounts_in_message":[],"_revision_number":2},{"id":"14474d46814b54673e702d993fb0f61873103d5a","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-10 11:09:27.000000000","message":"Patch Set 2:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/2/check/tempest-dsvm-full-xenial/f229b67/ : SUCCESS in 1h 08m 13s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/2/check/tempest-dsvm-full-xenial-py3/cada9aa/ : SUCCESS in 1h 09m 49s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/2/check/grenade-dsvm-xenial/359f57b/ : SUCCESS in 58m 18s (non-voting)","accounts_in_message":[],"_revision_number":2},{"id":"4067caf3d4c1f19105924338c68b1adf5c700462","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-10 11:54:06.000000000","message":"Patch Set 2:\n\n* pci-test http://52.27.155.124/pci/623543/2 : FAILURE","accounts_in_message":[],"_revision_number":2},{"id":"203742d0ed60c949058dc603e1c75d4a932f8720","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2018-12-10 12:24:22.000000000","message":"Patch Set 2:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/2/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/8ca1a7e : SUCCESS in 1h 09m 21s","accounts_in_message":[],"_revision_number":2},{"id":"230684a7a25e86c305601d5f00a7ae549e86416c","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-10 12:44:18.000000000","message":"Patch Set 2:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-25942 : SUCCESS in 2h 03m 13s","accounts_in_message":[],"_revision_number":2},{"id":"9a956f277fdc0997def6f1c304097cd37ad38c82","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2018-12-10 13:04:45.000000000","message":"Patch Set 2:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/2/check-vote/ext-nova-zuul/abb0ecc : SUCCESS in 59m 37s","accounts_in_message":[],"_revision_number":2},{"id":"44bfcea8908353f18f6ea18d09603e2f604a06a7","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-10 13:20:00.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"a717db2e9be1d12408915b6fd7b0df888f7b35ad","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-10 13:23:36.000000000","message":"Patch Set 3:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":3},{"id":"4af284fcf0f4a2137cbc13f0315988ebf005bd87","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-10 13:30:09.000000000","message":"Patch Set 3:\n\n* pci-test http://52.27.155.124/pci/623543/3 : FAILURE","accounts_in_message":[],"_revision_number":3},{"id":"2e09e6d16599526c25dde226f5e7db77ef8d10ae","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2018-12-10 14:25:14.000000000","message":"Patch Set 3:\n\nTesting failed ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenial-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/3/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/e7de3a7 : FAILURE in 1h 00m 29s","accounts_in_message":[],"_revision_number":3},{"id":"40d4e80d79f301f148da44f2ef890139193252f2","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-10 14:29:11.000000000","message":"Patch Set 3:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-25949 : SUCCESS in 1h 01m 16s","accounts_in_message":[],"_revision_number":3},{"id":"a898a42d388eed16d70b2b6ba1fc7e8b488b03d2","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-10 14:31:01.000000000","message":"Patch Set 3:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/3/check/tempest-dsvm-full-xenial/e47fa54/ : SUCCESS in 1h 09m 09s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/3/check/tempest-dsvm-full-xenial-py3/4402fe0/ : SUCCESS in 1h 08m 44s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/3/check/grenade-dsvm-xenial/6144c1f/ : SUCCESS in 50m 40s (non-voting)","accounts_in_message":[],"_revision_number":3},{"id":"cce2286f7173b94ebfc04546f84159b28f5923b9","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2018-12-10 14:33:50.000000000","message":"Patch Set 3:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/3/check-vote/ext-nova-zuul/c9e0fbd : FAILURE in 58m 58s","accounts_in_message":[],"_revision_number":3},{"id":"3c8e17da98e32620015c1f14c9f3bc98478a9602","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-10 15:19:10.000000000","message":"Patch Set 3:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/3 : SUCCESS in 1h 56m 21s","accounts_in_message":[],"_revision_number":3},{"id":"f3ceaec2e86ee929861748bf3a0d7226df719b4f","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2018-12-10 15:37:14.000000000","message":"Patch Set 3:\n\nBuild succeeded.\n\n- dsvm-tempest-neutron-network http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/43/623543/3/check/dsvm-tempest-neutron-network/000dc48 : SUCCESS in 2h 13m 41s","accounts_in_message":[],"_revision_number":3},{"id":"361cae0211e1ccbbd97dba8785524b50412f49c5","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2018-12-10 17:43:10.000000000","message":"Patch Set 3:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/3/check/nova-out-of-tree-pvm/858f3a2 : FAILURE in 4h 03m 39s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/3/check/nova-in-tree-pvm/8cd3f2e : SUCCESS in 2h 43m 24s","accounts_in_message":[],"_revision_number":3},{"id":"db4f69b7c440c431770a1d45e5421683b8a49be2","author":{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},"date":"2018-12-10 17:54:22.000000000","message":"Patch Set 3:\n\nBuild succeeded.\n\n- check-dsvm-tempest-vz7-exe-minimal http://openstack-3rd-party-virtuozzo-ci-logs.virtuozzo.com/43/623543/3/check/check-dsvm-tempest-vz7-exe-minimal/4148e8b : SUCCESS in 1h 09m 23s\n\nFor information, see https://wiki.openstack.org/wiki/ThirdPartySystems/Virtuozzo_CI Make the comment \u0027run-Virtuozzo CI\u0027 to recheck","accounts_in_message":[],"_revision_number":3},{"id":"8d9f50e209c1110052ab8fd569e68824620b2780","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-10 21:34:15.000000000","message":"Patch Set 3: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/3/check/tempest-full/d2f483b/ : SUCCESS in 1h 45m 04s\n- neutron-grenade http://logs.openstack.org/43/623543/3/check/neutron-grenade/9f9e888/ : SUCCESS in 56m 05s\n- grenade-py3 http://logs.openstack.org/43/623543/3/check/grenade-py3/6a8de49/ : SUCCESS in 1h 08m 48s\n- tempest-full-py3 http://logs.openstack.org/43/623543/3/check/tempest-full-py3/e36443b/ : SUCCESS in 1h 28m 16s\n- openstack-tox-cover http://logs.openstack.org/43/623543/3/check/openstack-tox-cover/ab8ad53/cover/ : SUCCESS in 16m 51s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/3/check/openstack-tox-lower-constraints/cdb9987/ : SUCCESS in 14m 29s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/3/check/openstack-tox-pep8/08cfb70/ : FAILURE in 9m 10s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/3/check/openstack-tox-py27/30667e5/ : SUCCESS in 14m 52s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/3/check/openstack-tox-py35/7e993cd/ : SUCCESS in 12m 38s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/3/check/openstack-tox-py36/0c41eb7/ : SUCCESS in 11m 30s\n- openstack-tox-docs http://logs.openstack.org/43/623543/3/check/openstack-tox-docs/834e0f1/html/ : SUCCESS in 7m 25s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/3/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/2ff18c8/ : SUCCESS in 48m 24s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/3/check/devstack-plugin-ceph-tempest/f81e052/ : TIMED_OUT in 2h 10m 51s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/3/check/legacy-grenade-dsvm-neutron-multinode-live-migration/88972a0/ : SUCCESS in 1h 03m 04s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/3/check/neutron-grenade-multinode/7577074/ : SUCCESS in 1h 08m 13s\n- nova-cells-v1 http://logs.openstack.org/43/623543/3/check/nova-cells-v1/abf93fb/ : SUCCESS in 1h 04m 51s\n- nova-live-migration http://logs.openstack.org/43/623543/3/check/nova-live-migration/e973a2c/ : SUCCESS in 49m 48s\n- nova-multiattach http://logs.openstack.org/43/623543/3/check/nova-multiattach/2b1b493/ : SUCCESS in 1h 01m 22s\n- nova-next http://logs.openstack.org/43/623543/3/check/nova-next/4d31d5f/ : SUCCESS in 1h 33m 30s\n- nova-tox-functional http://logs.openstack.org/43/623543/3/check/nova-tox-functional/ab38105/ : FAILURE in 20m 57s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/3/check/nova-tox-functional-py35/d675298/ : FAILURE in 20m 29s\n- tempest-multinode-full http://logs.openstack.org/43/623543/3/check/tempest-multinode-full/46b18de/ : SUCCESS in 1h 44m 22s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/3/check/tempest-slow/0227032/ : SUCCESS in 1h 44m 45s","accounts_in_message":[],"_revision_number":3},{"id":"b4a6852c328344ff7f700706567f60e629152d35","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-11 08:28:54.000000000","message":"Patch Set 3: Workflow-1","accounts_in_message":[],"_revision_number":3},{"id":"870c9a08c82d386d2da23d924806ec58becdca8e","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-11 16:29:19.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"76e65a0ecbb4559a456d0b2db76257fd7a2813e5","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2018-12-11 16:30:52.000000000","message":"Patch Set 4:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":4},{"id":"fb6771efe8c7ab869ad209e3a0d730b995049986","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-11 16:30:53.000000000","message":"Patch Set 4: Workflow-1","accounts_in_message":[],"_revision_number":4},{"id":"1be4bfe769b07769023a16dd12e856b7d2001a13","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-11 16:32:42.000000000","message":"Patch Set 4:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":4},{"id":"39af26249653deb93101429eeab38aa16b09a316","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-11 17:18:02.000000000","message":"Patch Set 4:\n\n* pci-test http://52.27.155.124/pci/623543/4 : SUCCESS","accounts_in_message":[],"_revision_number":4},{"id":"cbc4323a8ca40c44617ac0df349063f79f82250e","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2018-12-11 17:19:02.000000000","message":"Patch Set 4:\n\nTesting failed ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenial-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/4/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/b180dd3 : FAILURE in 45m 35s","accounts_in_message":[],"_revision_number":4},{"id":"322b5dacb44c56ec4f64a75b8ab2bfbb28591cb6","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-11 17:19:05.000000000","message":"Patch Set 4:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-26034 : FAILURE in 43m 28s","accounts_in_message":[],"_revision_number":4},{"id":"de46bbe00e6d7801d3d52a8ac3f4cda920dfc808","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2018-12-11 17:22:23.000000000","message":"Patch Set 4:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/4/check/nova-out-of-tree-pvm/acf9334 : FAILURE in 45m 43s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/4/check/nova-in-tree-pvm/53d8cb4 : FAILURE in 44m 36s","accounts_in_message":[],"_revision_number":4},{"id":"c79bd7382b1b21abd6c88abfb8b578f3dd27b744","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-11 17:24:05.000000000","message":"Patch Set 4:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/4/check/tempest-dsvm-full-xenial/c4dc67e/ : FAILURE in 51m 17s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/4/check/tempest-dsvm-full-xenial-py3/e93a178/ : FAILURE in 52m 58s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/4/check/grenade-dsvm-xenial/678a09b/ : FAILURE in 50m 09s (non-voting)","accounts_in_message":[],"_revision_number":4},{"id":"a8c60ade353f94ac2acf6fc3620930823acac6e4","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-11 17:50:25.000000000","message":"Patch Set 4:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/4 : FAILURE in 1h 17m 45s","accounts_in_message":[],"_revision_number":4},{"id":"71867b003cf6e4a9bbb6e52cc3de2fe79c4a884e","author":{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},"date":"2018-12-11 19:27:48.000000000","message":"Patch Set 4:\n\nBuild failed\n\n- check-dsvm-tempest-vz7-exe-minimal http://openstack-3rd-party-virtuozzo-ci-logs.virtuozzo.com/43/623543/4/check/check-dsvm-tempest-vz7-exe-minimal/c89902c : FAILURE in 1h 11m 37s\n\nFor information, see https://wiki.openstack.org/wiki/ThirdPartySystems/Virtuozzo_CI Make the comment \u0027run-Virtuozzo CI\u0027 to recheck","accounts_in_message":[],"_revision_number":4},{"id":"8268d95983fc48621b6b0dcb984eb52e96702560","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-11 19:31:53.000000000","message":"Patch Set 4: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/4/check/tempest-full/f5b76cc/ : FAILURE in 50m 54s\n- neutron-grenade http://logs.openstack.org/43/623543/4/check/neutron-grenade/25a44b2/ : FAILURE in 49m 08s\n- grenade-py3 http://logs.openstack.org/43/623543/4/check/grenade-py3/3909505/ : FAILURE in 53m 03s\n- tempest-full-py3 http://logs.openstack.org/43/623543/4/check/tempest-full-py3/25948bc/ : FAILURE in 48m 06s\n- openstack-tox-cover http://logs.openstack.org/43/623543/4/check/openstack-tox-cover/12ffc4d/ : FAILURE in 14m 51s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/4/check/openstack-tox-lower-constraints/a060a4b/ : FAILURE in 12m 06s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/4/check/openstack-tox-pep8/5f30d0c/ : FAILURE in 8m 40s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/4/check/openstack-tox-py27/4622a02/ : FAILURE in 12m 17s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/4/check/openstack-tox-py35/b825061/ : FAILURE in 12m 26s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/4/check/openstack-tox-py36/fc885e4/ : FAILURE in 12m 18s\n- openstack-tox-docs http://logs.openstack.org/43/623543/4/check/openstack-tox-docs/6efa4bd/html/ : SUCCESS in 6m 23s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/4/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/a0ae012/ : FAILURE in 43m 13s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/4/check/devstack-plugin-ceph-tempest/d54345a/ : FAILURE in 1h 07m 19s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/4/check/legacy-grenade-dsvm-neutron-multinode-live-migration/edc7025/ : FAILURE in 1h 00m 17s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/4/check/neutron-grenade-multinode/d8630ea/ : FAILURE in 1h 08m 28s\n- neutron-tempest-linuxbridge http://logs.openstack.org/43/623543/4/check/neutron-tempest-linuxbridge/d83d2e2/ : FAILURE in 1h 24m 44s\n- nova-live-migration http://logs.openstack.org/43/623543/4/check/nova-live-migration/d1181bb/ : FAILURE in 42m 06s\n- nova-multiattach http://logs.openstack.org/43/623543/4/check/nova-multiattach/cd4f08e/ : FAILURE in 34m 28s\n- nova-next http://logs.openstack.org/43/623543/4/check/nova-next/de82dce/ : FAILURE in 55m 47s\n- nova-tox-functional http://logs.openstack.org/43/623543/4/check/nova-tox-functional/3138041/ : FAILURE in 23m 04s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/4/check/nova-tox-functional-py35/49745f3/ : FAILURE in 20m 38s\n- tempest-multinode-full http://logs.openstack.org/43/623543/4/check/tempest-multinode-full/112ad9a/ : FAILURE in 1h 02m 08s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/4/check/tempest-slow/3ed336e/ : FAILURE in 1h 05m 33s","accounts_in_message":[],"_revision_number":4},{"id":"5d7916a203761b8e05084e249e9dc69e29f488ec","author":{"_account_id":8871,"name":"Elastic Recheck","username":"elasticrecheck"},"date":"2018-12-11 19:32:34.000000000","message":"Patch Set 4:\n\nI noticed Zuul failed, I think you hit bug(s):\n\n- grenade-py3: unrecognized error\n- neutron-grenade-multinode: unrecognized error\n- neutron-grenade: unrecognized error\n- neutron-tempest-linuxbridge: unrecognized error\n- nova-live-migration: unrecognized error\n- nova-multiattach: unrecognized error\n- nova-next: unrecognized error\n- nova-tox-functional-py35: https://bugs.launchpad.net/bugs/1704588\n- nova-tox-functional: https://bugs.launchpad.net/bugs/1704588\n- openstack-tox-cover: https://bugs.launchpad.net/bugs/1800472\n- openstack-tox-lower-constraints: https://bugs.launchpad.net/bugs/1800472\n- openstack-tox-pep8: unrecognized error\n- openstack-tox-py27: https://bugs.launchpad.net/bugs/1800472\n- openstack-tox-py35: https://bugs.launchpad.net/bugs/1800472\n- openstack-tox-py36: https://bugs.launchpad.net/bugs/1800472\n- tempest-full-py3: unrecognized error\n- tempest-full: unrecognized error\n- tempest-slow: unrecognized error\n\nSome of the tests failed in a way that we did not understand. Please help us classify these issues so that they can be part of Elastic Recheck http://status.openstack.org/elastic-recheck/\nFor more details on this and other bugs, please see http://status.openstack.org/elastic-recheck/","accounts_in_message":[],"_revision_number":4},{"id":"83d65b74f842e8ea103fb8d533f8213ac796a6bf","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2018-12-11 19:48:24.000000000","message":"Patch Set 4:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/4/check-vote/ext-nova-zuul/ad76721 : FAILURE in 43m 57s","accounts_in_message":[],"_revision_number":4},{"id":"44bf79ed709acd80360717b3c2949b8d8e6e1cfc","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-12 17:07:39.000000000","message":"Uploaded patch set 5.","accounts_in_message":[],"_revision_number":5},{"id":"7aa3d44a3dda0cc9a998336b9f018f4c9bf5591d","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-12 17:07:57.000000000","message":"Patch Set 5: Workflow-1\n\n(2 comments)","accounts_in_message":[],"_revision_number":5},{"id":"965b45544d122a0d54c2332ababd01930657180e","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2018-12-12 17:11:13.000000000","message":"Patch Set 5:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":5},{"id":"33d27200dcad66c5a3b545e8ac4787c0028ecef8","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-12 17:11:55.000000000","message":"Patch Set 5:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":5},{"id":"6da0af4efe92de52e49d5992d40f5fc2218fc71d","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-12 17:53:51.000000000","message":"Patch Set 5:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/5/check/tempest-dsvm-full-xenial/d4d8ed4/ : FAILURE in 24m 15s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/5/check/tempest-dsvm-full-xenial-py3/4a56788/ : FAILURE in 23m 26s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/5/check/grenade-dsvm-xenial/0955f0f/ : FAILURE in 44m 06s (non-voting)","accounts_in_message":[],"_revision_number":5},{"id":"629497b9a0ae9c8973313eb36b130c79cc79cd44","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-12 18:17:12.000000000","message":"Patch Set 5:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-26091 : SUCCESS in 1h 04m 35s","accounts_in_message":[],"_revision_number":5},{"id":"44d3be44c934e98555fd651670298ec0b538a288","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2018-12-12 18:38:19.000000000","message":"Patch Set 5:\n\nTesting failed ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenial-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/5/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/f9e66bf : FAILURE in 1h 26m 17s","accounts_in_message":[],"_revision_number":5},{"id":"40002e58c03e4d6359a03d69f3b3b135758a902c","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-12 19:16:55.000000000","message":"Patch Set 5:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/5 : FAILURE in 2h 06m 08s","accounts_in_message":[],"_revision_number":5},{"id":"9acb687b7d12f5f8e1ca092b327be5703456c5bd","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2018-12-12 19:18:23.000000000","message":"Patch Set 5:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/5/check/nova-out-of-tree-pvm/a89dffc : FAILURE in 2h 09m 14s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/5/check/nova-in-tree-pvm/622d7f0 : FAILURE in 1h 49m 30s","accounts_in_message":[],"_revision_number":5},{"id":"52ed81de936518bd51746f8f97e0c5fb96b47141","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-12 23:03:33.000000000","message":"Patch Set 5: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/5/check/tempest-full/e3cd6ea/ : SUCCESS in 1h 18m 47s\n- neutron-grenade http://logs.openstack.org/43/623543/5/check/neutron-grenade/f3e1301/ : SUCCESS in 49m 34s\n- grenade-py3 http://logs.openstack.org/43/623543/5/check/grenade-py3/5ef0d31/ : SUCCESS in 1h 01m 46s\n- tempest-full-py3 http://logs.openstack.org/43/623543/5/check/tempest-full-py3/400300d/ : SUCCESS in 1h 49m 29s\n- openstack-tox-cover http://logs.openstack.org/43/623543/5/check/openstack-tox-cover/afb023a/ : FAILURE in 14m 15s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/5/check/openstack-tox-lower-constraints/c0d2458/ : FAILURE in 13m 36s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/5/check/openstack-tox-pep8/27ba5da/ : FAILURE in 9m 05s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/5/check/openstack-tox-py27/0b7d5f9/ : FAILURE in 14m 14s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/5/check/openstack-tox-py35/d8e8354/ : FAILURE in 15m 26s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/5/check/openstack-tox-py36/c706bd0/ : FAILURE in 11m 38s\n- openstack-tox-docs http://logs.openstack.org/43/623543/5/check/openstack-tox-docs/f7dcd70/html/ : SUCCESS in 6m 15s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/5/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/a550536/ : FAILURE in 50m 57s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/5/check/devstack-plugin-ceph-tempest/05d3194/ : SUCCESS in 1h 35m 06s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/5/check/legacy-grenade-dsvm-neutron-multinode-live-migration/fa61fec/ : SUCCESS in 1h 00m 10s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/5/check/neutron-grenade-multinode/c3a40ab/ : SUCCESS in 59m 00s\n- neutron-tempest-linuxbridge http://logs.openstack.org/43/623543/5/check/neutron-tempest-linuxbridge/76384e0/ : SUCCESS in 1h 27m 45s\n- nova-live-migration http://logs.openstack.org/43/623543/5/check/nova-live-migration/5f1a8fb/ : SUCCESS in 44m 20s\n- nova-multiattach http://logs.openstack.org/43/623543/5/check/nova-multiattach/6b040ee/ : SUCCESS in 1h 07m 32s\n- nova-next http://logs.openstack.org/43/623543/5/check/nova-next/3c3ac83/ : SUCCESS in 1h 35m 06s\n- nova-tox-functional http://logs.openstack.org/43/623543/5/check/nova-tox-functional/d82f372/ : SUCCESS in 27m 36s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/5/check/nova-tox-functional-py35/deb3b8b/ : SUCCESS in 24m 21s\n- tempest-multinode-full http://logs.openstack.org/43/623543/5/check/tempest-multinode-full/2f1678e/ : SUCCESS in 1h 35m 35s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/5/check/tempest-slow/d85c171/ : SUCCESS in 1h 47m 00s","accounts_in_message":[],"_revision_number":5},{"id":"f38cc7ee183cea3e651a3c86ff0641d725f2267d","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-13 00:34:25.000000000","message":"Patch Set 5:\n\n* pci-test http://52.27.155.124/pci/623543/5 : FAILURE","accounts_in_message":[],"_revision_number":5},{"id":"025ac47f588e59c71c22da5537f36141e19805f8","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-14 14:36:54.000000000","message":"Uploaded patch set 6: Patch Set 5 was rebased.","accounts_in_message":[],"_revision_number":6},{"id":"f39ec6e12a4cdbf4ea89434d71cb26ccd52df1f6","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-14 14:59:22.000000000","message":"Patch Set 6:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":6},{"id":"b8cefe78555b259d3e46e9781e25250a98fd5576","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2018-12-14 15:03:03.000000000","message":"Patch Set 6:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":6},{"id":"f3d8697bdc0f52af9718bf26f492eb4b4db1811e","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2018-12-14 16:27:48.000000000","message":"Patch Set 6:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":6},{"id":"c5d3c9f4bf968e52f2ad303b9f92393e6cc62b0c","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-14 16:29:53.000000000","message":"Patch Set 6:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/6 : FAILURE in 1h 21m 52s","accounts_in_message":[],"_revision_number":6},{"id":"9b819facaaeffd37cf4576b62b345cf25f8ed498","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-14 16:53:22.000000000","message":"Uploaded patch set 7.","accounts_in_message":[],"_revision_number":7},{"id":"40ba9940c994c7b179b3e1bdb21a273c04940661","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-14 16:57:09.000000000","message":"Patch Set 7:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":7},{"id":"44a70d2815be097cf230ac621d313c44e980a74a","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2018-12-14 17:02:52.000000000","message":"Patch Set 7:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":7},{"id":"c13986f6b60d0f400edab7b57e34f1ebe23114b5","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-14 17:45:41.000000000","message":"Uploaded patch set 8: Patch Set 7 was rebased.","accounts_in_message":[],"_revision_number":8},{"id":"f8a3d2e4dcddb2d4854c8b8a4153196e41f1d807","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-14 17:56:56.000000000","message":"Patch Set 8:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":8},{"id":"e2059763e70f7a64ec2c1948ca4c337c133b5b2e","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2018-12-14 18:06:41.000000000","message":"Patch Set 8:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":8},{"id":"3f5215acd69b5fca4bb1b4453c2ade1883d78447","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2018-12-14 19:07:39.000000000","message":"Patch Set 8:\n\nTesting failed ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenial-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/8/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/680ab07 : FAILURE in 1h 08m 41s","accounts_in_message":[],"_revision_number":8},{"id":"e0b62a13da8c21cfcf9e87049e997f3c472ba24c","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-14 19:09:10.000000000","message":"Patch Set 8:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/8/check/tempest-dsvm-full-xenial/74e0fd8/ : SUCCESS in 1h 14m 07s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/8/check/tempest-dsvm-full-xenial-py3/cba165a/ : FAILURE in 1h 06m 10s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/8/check/grenade-dsvm-xenial/d1518d0/ : FAILURE in 33m 26s (non-voting)","accounts_in_message":[],"_revision_number":8},{"id":"fd5e648d64fbcfff7f429d165b8ee6f629bcb5d8","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-14 20:07:15.000000000","message":"Patch Set 8:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-26175 : SUCCESS in 1h 58m 56s","accounts_in_message":[],"_revision_number":8},{"id":"87834112663db8fc2c75d94e37aaf49a33db9114","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-14 20:08:12.000000000","message":"Patch Set 8:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/8 : FAILURE in 2h 11m 42s","accounts_in_message":[],"_revision_number":8},{"id":"a87418c764c863e3c7aa99e08d6cf84786c5f1f2","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-14 21:53:16.000000000","message":"Patch Set 8: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/8/check/tempest-full/99ac793/ : SUCCESS in 1h 34m 20s\n- neutron-grenade http://logs.openstack.org/43/623543/8/check/neutron-grenade/1fbe935/ : SUCCESS in 57m 59s\n- grenade-py3 http://logs.openstack.org/43/623543/8/check/grenade-py3/74a8e81/ : SUCCESS in 53m 05s\n- tempest-full-py3 http://logs.openstack.org/43/623543/8/check/tempest-full-py3/07a28a7/ : SUCCESS in 1h 03m 59s\n- openstack-tox-cover http://logs.openstack.org/43/623543/8/check/openstack-tox-cover/a874325/ : FAILURE in 12m 53s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/8/check/openstack-tox-lower-constraints/2435dd9/ : FAILURE in 11m 23s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/8/check/openstack-tox-pep8/d4bb39d/ : FAILURE in 8m 11s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/8/check/openstack-tox-py27/7ddc750/ : FAILURE in 12m 27s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/8/check/openstack-tox-py35/a1b1d15/ : FAILURE in 11m 44s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/8/check/openstack-tox-py36/4761364/ : FAILURE in 10m 45s\n- openstack-tox-docs http://logs.openstack.org/43/623543/8/check/openstack-tox-docs/053b80a/html/ : SUCCESS in 6m 41s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/8/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/6e8e2f1/ : SUCCESS in 52m 08s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/8/check/devstack-plugin-ceph-tempest/66e4766/ : FAILURE in 1h 46m 33s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/8/check/legacy-grenade-dsvm-neutron-multinode-live-migration/a308716/ : SUCCESS in 1h 05m 43s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/8/check/neutron-grenade-multinode/98b7958/ : SUCCESS in 1h 05m 55s\n- nova-live-migration http://logs.openstack.org/43/623543/8/check/nova-live-migration/16d4299/ : SUCCESS in 49m 22s\n- nova-multiattach http://logs.openstack.org/43/623543/8/check/nova-multiattach/4447ee6/ : SUCCESS in 1h 07m 51s\n- nova-next http://logs.openstack.org/43/623543/8/check/nova-next/486d24e/ : SUCCESS in 1h 36m 20s\n- nova-tox-functional http://logs.openstack.org/43/623543/8/check/nova-tox-functional/f7dbbb8/ : SUCCESS in 20m 07s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/8/check/nova-tox-functional-py35/5c371fa/ : SUCCESS in 18m 08s\n- tempest-multinode-full http://logs.openstack.org/43/623543/8/check/tempest-multinode-full/3cd300a/ : POST_FAILURE in 1h 54m 45s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/8/check/tempest-slow/0f69bfa/ : SUCCESS in 2h 09m 58s","accounts_in_message":[],"_revision_number":8},{"id":"0a6ae1a76954c9beaf0ce67728a165b46f1c52fa","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-14 22:20:35.000000000","message":"Patch Set 6:\n\n* pci-test http://52.27.155.124/pci/623543/6 : SUCCESS","accounts_in_message":[],"_revision_number":6},{"id":"f086f19bb4625fa3782c0ed422b231990ec04110","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-14 22:47:15.000000000","message":"Patch Set 7:\n\n* pci-test http://52.27.155.124/pci/623543/7 : FAILURE","accounts_in_message":[],"_revision_number":7},{"id":"1158650333bbb448af81dd58dcaa9442665ca908","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-14 23:47:46.000000000","message":"Patch Set 8:\n\n* pci-test http://52.27.155.124/pci/623543/8 : SUCCESS","accounts_in_message":[],"_revision_number":8},{"id":"cf4409b99e5fe062ee2a491d2a40f417b03cef64","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-17 09:57:01.000000000","message":"Patch Set 8: Workflow-1","accounts_in_message":[],"_revision_number":8},{"id":"0fad297ca0d95bcf96c624eeb03491d2fcd2f0b1","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-18 15:49:46.000000000","message":"Uploaded patch set 9: Patch Set 8 was rebased.","accounts_in_message":[],"_revision_number":9},{"id":"bf9845a9990da000edc0664a211946920aea6292","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-18 16:32:58.000000000","message":"Patch Set 9:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":9},{"id":"764955b662c26213ddd91c14538911c4fd7f4fa0","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-18 16:34:03.000000000","message":"Patch Set 9:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/9 : FAILURE in 7m 20s","accounts_in_message":[],"_revision_number":9},{"id":"61cfba687910f77fd10b09b9625aca6a661df4f3","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-18 17:30:39.000000000","message":"Patch Set 9:\n\n* pci-test http://52.27.155.124/pci/623543/9 : FAILURE","accounts_in_message":[],"_revision_number":9},{"id":"c5a96a373505d33c23a3413ba46c9024d98e5dd1","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2018-12-18 18:47:25.000000000","message":"Patch Set 9:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/9/check-vote/ext-nova-zuul/90da0ee : FAILURE in 32m 25s","accounts_in_message":[],"_revision_number":9},{"id":"ef2d0623c47b86eaa0b96d8d3364969adf5cf6e4","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-18 19:01:05.000000000","message":"Patch Set 9:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/9/check/tempest-dsvm-full-xenial/7b22f2e/ : FAILURE in 35m 30s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/9/check/tempest-dsvm-full-xenial-py3/a01438b/ : SUCCESS in 1h 11m 35s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/9/check/grenade-dsvm-xenial/79c4570/ : FAILURE in 2h 17m 55s (non-voting)","accounts_in_message":[],"_revision_number":9},{"id":"7cb8c46d1b8e8875fe40e8ef4c5aaf4fe42c6c8c","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2018-12-18 19:49:59.000000000","message":"Patch Set 9:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/9/check/nova-out-of-tree-pvm/fe6540c : FAILURE in 14m 44s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/9/check/nova-in-tree-pvm/f922e95 : SUCCESS in 2h 28m 49s","accounts_in_message":[],"_revision_number":9},{"id":"bb96fc3fad8eb851de340f5c2d0c10e09e04ad3d","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-18 20:05:02.000000000","message":"Patch Set 9: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/9/check/tempest-full/780b8e9/ : SUCCESS in 1h 51m 25s\n- neutron-grenade http://logs.openstack.org/43/623543/9/check/neutron-grenade/3f7d432/ : SUCCESS in 1h 16m 07s\n- grenade-py3 http://logs.openstack.org/43/623543/9/check/grenade-py3/3c8778e/ : SUCCESS in 1h 03m 06s\n- tempest-full-py3 http://logs.openstack.org/43/623543/9/check/tempest-full-py3/4698717/ : SUCCESS in 1h 14m 08s\n- openstack-tox-cover http://logs.openstack.org/43/623543/9/check/openstack-tox-cover/ae48edc/ : FAILURE in 15m 06s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/9/check/openstack-tox-lower-constraints/e987c32/ : FAILURE in 12m 50s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/9/check/openstack-tox-pep8/0659db0/ : FAILURE in 10m 26s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/9/check/openstack-tox-py27/0141e62/ : FAILURE in 13m 01s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/9/check/openstack-tox-py35/c617d51/ : FAILURE in 14m 19s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/9/check/openstack-tox-py36/846c77e/ : FAILURE in 14m 38s\n- openstack-tox-docs http://logs.openstack.org/43/623543/9/check/openstack-tox-docs/8c3e8d5/html/ : SUCCESS in 7m 24s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/9/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/bfc7700/ : SUCCESS in 47m 05s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/9/check/devstack-plugin-ceph-tempest/28f6e02/ : TIMED_OUT in 2h 05m 55s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/9/check/legacy-grenade-dsvm-neutron-multinode-live-migration/22709f1/ : SUCCESS in 1h 11m 48s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/9/check/neutron-grenade-multinode/40349aa/ : SUCCESS in 1h 12m 46s\n- nova-live-migration http://logs.openstack.org/43/623543/9/check/nova-live-migration/65e54c8/ : SUCCESS in 50m 29s\n- nova-multiattach http://logs.openstack.org/43/623543/9/check/nova-multiattach/bf047c3/ : SUCCESS in 54m 52s\n- nova-next http://logs.openstack.org/43/623543/9/check/nova-next/4d21ea3/ : SUCCESS in 1h 40m 31s\n- nova-tox-functional http://logs.openstack.org/43/623543/9/check/nova-tox-functional/46d38d4/ : SUCCESS in 18m 07s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/9/check/nova-tox-functional-py35/c247e20/ : SUCCESS in 19m 36s\n- tempest-multinode-full http://logs.openstack.org/43/623543/9/check/tempest-multinode-full/8144997/ : SUCCESS in 1h 34m 41s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/9/check/tempest-slow/b1bbad3/ : SUCCESS in 1h 37m 23s","accounts_in_message":[],"_revision_number":9},{"id":"c495dad82beff6bf68df9857e2f5f92f7ada4c8e","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-19 00:05:39.000000000","message":"Patch Set 9:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-26293 : FAILURE in 3h 30m 57s","accounts_in_message":[],"_revision_number":9},{"id":"385471950131b9afeadbe25c8ba4430e6da6121d","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2018-12-19 12:38:35.000000000","message":"Patch Set 9:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/9/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/951c752 : SUCCESS in 1h 10m 32s","accounts_in_message":[],"_revision_number":9},{"id":"d6788c3e79444235961902e4a5334b90845d404a","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-19 15:49:06.000000000","message":"Uploaded patch set 10: Patch Set 9 was rebased.","accounts_in_message":[],"_revision_number":10},{"id":"9f97e759e742c3fba8cf4369221268415fc67bf0","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-19 16:25:51.000000000","message":"Patch Set 10:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":10},{"id":"f1203d98cbbbab0a9a281a00949e2e6476e8dedf","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-19 17:52:54.000000000","message":"Patch Set 10:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/10/check/tempest-dsvm-full-xenial/e2a7f46/ : SUCCESS in 1h 04m 06s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/10/check/tempest-dsvm-full-xenial-py3/5b35576/ : SUCCESS in 1h 00m 55s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/10/check/grenade-dsvm-xenial/59dfbc8/ : SUCCESS in 51m 12s (non-voting)","accounts_in_message":[],"_revision_number":10},{"id":"81eec0ce1dcf7a8a171974c55aeb96e044f2f5c0","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-19 18:23:23.000000000","message":"Patch Set 10:\n\n* pci-test http://52.27.155.124/pci/623543/10 : SUCCESS","accounts_in_message":[],"_revision_number":10},{"id":"94b48fce1b05b2d7f2f3fbac90cd43f45c5cc56a","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2018-12-19 18:43:00.000000000","message":"Patch Set 10:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/10/check-vote/ext-nova-zuul/9a76e98 : FAILURE in 31m 13s","accounts_in_message":[],"_revision_number":10},{"id":"17eb19d9e1b8bae775a5b57fde9752d2a66f8163","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-19 19:01:33.000000000","message":"Patch Set 10: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/10/check/tempest-full/e14dfe7/ : SUCCESS in 1h 19m 39s\n- neutron-grenade http://logs.openstack.org/43/623543/10/check/neutron-grenade/091d57c/ : SUCCESS in 50m 42s\n- grenade-py3 http://logs.openstack.org/43/623543/10/check/grenade-py3/7b797d9/ : SUCCESS in 59m 10s\n- tempest-full-py3 http://logs.openstack.org/43/623543/10/check/tempest-full-py3/99cc4fc/ : SUCCESS in 1h 13m 26s\n- openstack-tox-cover http://logs.openstack.org/43/623543/10/check/openstack-tox-cover/38a992e/ : FAILURE in 15m 44s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/10/check/openstack-tox-lower-constraints/9413aa2/ : FAILURE in 17m 31s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/10/check/openstack-tox-pep8/1b7ca2e/ : FAILURE in 8m 58s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/10/check/openstack-tox-py27/f82ec41/ : FAILURE in 14m 50s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/10/check/openstack-tox-py35/76795e2/ : FAILURE in 12m 27s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/10/check/openstack-tox-py36/daf2354/ : FAILURE in 16m 00s\n- openstack-tox-docs http://logs.openstack.org/43/623543/10/check/openstack-tox-docs/e528d0c/html/ : SUCCESS in 5m 56s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/10/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/2c3d1f4/ : SUCCESS in 41m 44s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/10/check/devstack-plugin-ceph-tempest/1f19978/ : FAILURE in 1h 39m 37s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/10/check/legacy-grenade-dsvm-neutron-multinode-live-migration/bce2bba/ : SUCCESS in 1h 12m 02s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/10/check/neutron-grenade-multinode/e512691/ : SUCCESS in 1h 02m 54s\n- nova-live-migration http://logs.openstack.org/43/623543/10/check/nova-live-migration/08f7f96/ : SUCCESS in 42m 41s\n- nova-multiattach http://logs.openstack.org/43/623543/10/check/nova-multiattach/3bf3b8a/ : SUCCESS in 54m 53s\n- nova-next http://logs.openstack.org/43/623543/10/check/nova-next/c88597f/ : SUCCESS in 1h 44m 53s\n- nova-tox-functional http://logs.openstack.org/43/623543/10/check/nova-tox-functional/395374f/ : SUCCESS in 23m 35s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/10/check/nova-tox-functional-py35/6b93322/ : SUCCESS in 17m 10s\n- tempest-multinode-full http://logs.openstack.org/43/623543/10/check/tempest-multinode-full/d8beb11/ : SUCCESS in 1h 23m 50s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/10/check/tempest-slow/d1e7b96/ : SUCCESS in 1h 45m 44s","accounts_in_message":[],"_revision_number":10},{"id":"716b3055c52e7084ab4933f97f28933367e83ea1","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-19 20:52:42.000000000","message":"Patch Set 10:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/10 : FAILURE in 2h 13m 46s","accounts_in_message":[],"_revision_number":10},{"id":"2acb2711966fa8975087645e989a71882696f40e","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2018-12-19 22:28:33.000000000","message":"Patch Set 10:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/10/check/nova-out-of-tree-pvm/0efb9f0 : FAILURE in 19m 36s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/10/check/nova-in-tree-pvm/206d2a4 : FAILURE in 5h 03m 08s","accounts_in_message":[],"_revision_number":10},{"id":"f6bfc2962aa37f6c08a54ee350c302a566a3337a","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-20 00:31:03.000000000","message":"Patch Set 10:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-26345 : FAILURE in 4h 07m 19s","accounts_in_message":[],"_revision_number":10},{"id":"7ee8d3cb45f8fdc0ef9eeef2710e23378e13f2e6","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-20 10:16:35.000000000","message":"Uploaded patch set 11: Patch Set 10 was rebased.","accounts_in_message":[],"_revision_number":11},{"id":"77db1e718599fffdc529163a89091e48271b7261","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-20 11:02:28.000000000","message":"Patch Set 11:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":11},{"id":"ddb2df1584bd4bbbf0676ac7b13d1d5acdf6ab5d","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-20 12:23:39.000000000","message":"Patch Set 11:\n\n* pci-test http://52.27.155.124/pci/623543/11 : FAILURE","accounts_in_message":[],"_revision_number":11},{"id":"5fea6e850323b83753d88ba6f43c162de800d9d8","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-20 12:41:54.000000000","message":"Patch Set 11: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/11/check/tempest-full/1098df6/ : SUCCESS in 1h 27m 00s\n- neutron-grenade http://logs.openstack.org/43/623543/11/check/neutron-grenade/2d5d8a9/ : SUCCESS in 57m 08s\n- grenade-py3 http://logs.openstack.org/43/623543/11/check/grenade-py3/3f184f0/ : SUCCESS in 1h 04m 54s\n- tempest-full-py3 http://logs.openstack.org/43/623543/11/check/tempest-full-py3/0e81aca/ : SUCCESS in 1h 20m 18s\n- openstack-tox-cover http://logs.openstack.org/43/623543/11/check/openstack-tox-cover/8c00d07/ : FAILURE in 14m 02s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/11/check/openstack-tox-lower-constraints/a65667b/ : FAILURE in 12m 23s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/11/check/openstack-tox-pep8/5eef23a/ : FAILURE in 9m 27s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/11/check/openstack-tox-py27/36d4229/ : FAILURE in 11m 37s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/11/check/openstack-tox-py35/518d350/ : FAILURE in 12m 05s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/11/check/openstack-tox-py36/d577a8c/ : FAILURE in 10m 33s\n- openstack-tox-docs http://logs.openstack.org/43/623543/11/check/openstack-tox-docs/dd8d670/html/ : SUCCESS in 6m 17s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/11/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/87cea9c/ : SUCCESS in 40m 24s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/11/check/devstack-plugin-ceph-tempest/96608de/ : SUCCESS in 1h 42m 39s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/11/check/legacy-grenade-dsvm-neutron-multinode-live-migration/b02f1e0/ : SUCCESS in 1h 04m 45s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/11/check/neutron-grenade-multinode/63a4734/ : SUCCESS in 1h 12m 21s\n- nova-live-migration http://logs.openstack.org/43/623543/11/check/nova-live-migration/316a6e3/ : SUCCESS in 47m 18s\n- nova-multiattach http://logs.openstack.org/43/623543/11/check/nova-multiattach/15b7bdd/ : SUCCESS in 1h 04m 40s\n- nova-next http://logs.openstack.org/43/623543/11/check/nova-next/dbc3810/ : SUCCESS in 1h 26m 25s\n- nova-tox-functional http://logs.openstack.org/43/623543/11/check/nova-tox-functional/3266fbf/ : SUCCESS in 22m 09s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/11/check/nova-tox-functional-py35/40dd898/ : SUCCESS in 17m 04s\n- tempest-multinode-full http://logs.openstack.org/43/623543/11/check/tempest-multinode-full/4c1889d/ : SUCCESS in 1h 23m 39s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/11/check/tempest-slow/fe11841/ : SUCCESS in 1h 37m 48s","accounts_in_message":[],"_revision_number":11},{"id":"5651b107148ab39df786bfc209a3f447e06dfcfa","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-20 14:05:21.000000000","message":"Patch Set 11:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/11/check/tempest-dsvm-full-xenial/a296847/ : FAILURE in 3h 03m 07s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/11/check/tempest-dsvm-full-xenial-py3/0f43889/ : FAILURE in 29m 53s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/11/check/grenade-dsvm-xenial/3365912/ : SUCCESS in 51m 16s (non-voting)","accounts_in_message":[],"_revision_number":11},{"id":"9d906ee9346246340326f187db805b4804628cfd","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2018-12-20 14:28:43.000000000","message":"Patch Set 11:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/11/check/nova-out-of-tree-pvm/8624c5d : FAILURE in 15m 24s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/11/check/nova-in-tree-pvm/62b50bb : SUCCESS in 2h 28m 20s","accounts_in_message":[],"_revision_number":11},{"id":"fd61dbbe91b9af482f24c5e1c5b30e45734c13cd","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-20 14:42:33.000000000","message":"Patch Set 11:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-26417 : SUCCESS in 1h 26m 37s","accounts_in_message":[],"_revision_number":11},{"id":"62e1adaf1bb1970f504cfe6d9c7e6cf28e9d5802","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2018-12-20 16:00:39.000000000","message":"Uploaded patch set 12: Patch Set 11 was rebased.","accounts_in_message":[],"_revision_number":12},{"id":"c8e4631ff960df2eb163d109f6cc89218aadd9ce","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2018-12-20 16:46:40.000000000","message":"Patch Set 12:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":12},{"id":"35405338d925c64811f00eca1fea6c80cbb0f258","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2018-12-20 17:47:06.000000000","message":"Patch Set 12:\n\n* pci-test http://52.27.155.124/pci/623543/12 : FAILURE","accounts_in_message":[],"_revision_number":12},{"id":"b56a1dbf814a2307c3aed9c38f59586c8ebee41a","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2018-12-20 19:30:21.000000000","message":"Patch Set 12: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/12/check/tempest-full/0e2fed3/ : SUCCESS in 1h 40m 33s\n- neutron-grenade http://logs.openstack.org/43/623543/12/check/neutron-grenade/3587279/ : SUCCESS in 57m 23s\n- grenade-py3 http://logs.openstack.org/43/623543/12/check/grenade-py3/395991d/ : SUCCESS in 1h 09m 12s\n- tempest-full-py3 http://logs.openstack.org/43/623543/12/check/tempest-full-py3/11d5574/ : SUCCESS in 1h 19m 54s\n- openstack-tox-cover http://logs.openstack.org/43/623543/12/check/openstack-tox-cover/04f87a6/ : FAILURE in 13m 01s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/12/check/openstack-tox-lower-constraints/f4c410c/ : FAILURE in 13m 07s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/12/check/openstack-tox-pep8/84f174a/ : FAILURE in 8m 39s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/12/check/openstack-tox-py27/4e6138d/ : FAILURE in 13m 01s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/12/check/openstack-tox-py35/c685e5c/ : FAILURE in 12m 37s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/12/check/openstack-tox-py36/6e7dbe8/ : FAILURE in 10m 36s\n- openstack-tox-docs http://logs.openstack.org/43/623543/12/check/openstack-tox-docs/0ea0aab/html/ : SUCCESS in 6m 04s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/12/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/c7f510b/ : SUCCESS in 48m 22s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/12/check/devstack-plugin-ceph-tempest/e89183a/ : FAILURE in 1h 48m 28s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/12/check/legacy-grenade-dsvm-neutron-multinode-live-migration/6de858f/ : SUCCESS in 58m 32s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/12/check/neutron-grenade-multinode/aac31a0/ : SUCCESS in 1h 06m 41s\n- nova-live-migration http://logs.openstack.org/43/623543/12/check/nova-live-migration/13c304e/ : SUCCESS in 48m 04s\n- nova-multiattach http://logs.openstack.org/43/623543/12/check/nova-multiattach/58ac445/ : SUCCESS in 56m 03s\n- nova-next http://logs.openstack.org/43/623543/12/check/nova-next/3455086/ : SUCCESS in 1h 30m 57s\n- nova-tox-functional http://logs.openstack.org/43/623543/12/check/nova-tox-functional/422af48/ : SUCCESS in 19m 04s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/12/check/nova-tox-functional-py35/a749ff4/ : SUCCESS in 22m 06s\n- tempest-multinode-full http://logs.openstack.org/43/623543/12/check/tempest-multinode-full/079978f/ : SUCCESS in 1h 24m 57s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/12/check/tempest-slow/45f8abf/ : SUCCESS in 2h 17m 20s","accounts_in_message":[],"_revision_number":12},{"id":"d53897dc4ab551fe94e8463ae9f760466bb6c875","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2018-12-20 19:50:04.000000000","message":"Patch Set 12:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/12/check/tempest-dsvm-full-xenial/d335338/ : FAILURE in 3h 02m 43s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/12/check/tempest-dsvm-full-xenial-py3/daceb03/ : FAILURE in 59m 44s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/12/check/grenade-dsvm-xenial/a61cfe7/ : FAILURE in 1h 54m 12s (non-voting)","accounts_in_message":[],"_revision_number":12},{"id":"ab538e21e8b768f30bc7c834467fd9816b2fe2a0","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2018-12-20 20:11:54.000000000","message":"Patch Set 12:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":12},{"id":"f5b1229738e7952393bc972a695c317a94654a2c","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2018-12-20 21:41:46.000000000","message":"Patch Set 12:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-26434 : FAILURE in 2h 28m 26s","accounts_in_message":[],"_revision_number":12},{"id":"71e5a7cbdc4f0f85f974a0600c9c1b0026746a59","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2018-12-20 22:47:14.000000000","message":"Patch Set 12:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/12 : SUCCESS in 1h 55m 10s","accounts_in_message":[],"_revision_number":12},{"id":"b75b8cd81fe0a1d6a7fca66b51b8032ec378f61f","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2018-12-21 17:09:12.000000000","message":"Patch Set 12:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/12/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/ef9f8c3 : SUCCESS in 1h 12m 16s","accounts_in_message":[],"_revision_number":12},{"id":"ce8436eb161da3a6cebd5a1c548a08c87ee319ce","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-01-14 16:29:33.000000000","message":"Uploaded patch set 13.","accounts_in_message":[],"_revision_number":13},{"id":"7b9ddf0625754d46d6b1b499af82e9e2692fc404","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-01-14 17:33:05.000000000","message":"Patch Set 13:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":13},{"id":"54d4906b8227b8be2fc199732c56ae3ecf01659d","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2019-01-14 19:27:46.000000000","message":"Patch Set 13:\n\n* pci-test http://52.27.155.124/pci/623543/13 : SUCCESS","accounts_in_message":[],"_revision_number":13},{"id":"a9bb76ec13bbc392957af5d6fe63c7d2409d4a8f","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-01-14 20:02:05.000000000","message":"Patch Set 13: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/13/check/tempest-full/685aed3/ : SUCCESS in 1h 28m 11s\n- neutron-grenade http://logs.openstack.org/43/623543/13/check/neutron-grenade/287fca3/ : SUCCESS in 52m 39s\n- grenade-py3 http://logs.openstack.org/43/623543/13/check/grenade-py3/85fe0c7/ : SUCCESS in 55m 29s\n- tempest-full-py3 http://logs.openstack.org/43/623543/13/check/tempest-full-py3/36cbf93/ : SUCCESS in 1h 09m 57s\n- openstack-tox-cover http://logs.openstack.org/43/623543/13/check/openstack-tox-cover/bd681e8/ : FAILURE in 13m 58s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/13/check/openstack-tox-lower-constraints/d07c3df/ : FAILURE in 12m 56s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/13/check/openstack-tox-pep8/0d5e7d7/ : FAILURE in 8m 36s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/13/check/openstack-tox-py27/da08743/ : FAILURE in 14m 30s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/13/check/openstack-tox-py35/073f20f/ : FAILURE in 17m 48s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/13/check/openstack-tox-py36/d6b41c3/ : FAILURE in 13m 12s\n- openstack-tox-docs http://logs.openstack.org/43/623543/13/check/openstack-tox-docs/0d6b223/html/ : SUCCESS in 6m 28s\n- ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/13/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/c087702/ : SUCCESS in 48m 41s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/13/check/devstack-plugin-ceph-tempest/24a8744/ : TIMED_OUT in 2h 07m 07s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/13/check/legacy-grenade-dsvm-neutron-multinode-live-migration/79112a2/ : SUCCESS in 1h 00m 52s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/13/check/neutron-grenade-multinode/7c38188/ : SUCCESS in 1h 09m 48s\n- nova-live-migration http://logs.openstack.org/43/623543/13/check/nova-live-migration/1967300/ : SUCCESS in 49m 57s\n- nova-multiattach http://logs.openstack.org/43/623543/13/check/nova-multiattach/e57a48f/ : SUCCESS in 1h 04m 18s\n- nova-next http://logs.openstack.org/43/623543/13/check/nova-next/f71d914/ : SUCCESS in 1h 29m 30s\n- nova-tox-functional http://logs.openstack.org/43/623543/13/check/nova-tox-functional/169feaf/ : SUCCESS in 20m 31s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/13/check/nova-tox-functional-py35/46e4fbb/ : SUCCESS in 18m 05s\n- tempest-multinode-full http://logs.openstack.org/43/623543/13/check/tempest-multinode-full/156c286/ : SUCCESS in 1h 22m 40s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/13/check/tempest-slow/5c2e5f6/ : SUCCESS in 1h 54m 41s","accounts_in_message":[],"_revision_number":13},{"id":"59da52d507efd443ddf8496cc0a461293f2c418e","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-01-14 20:13:46.000000000","message":"Patch Set 13:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/13/check/tempest-dsvm-full-xenial/c86a52f/ : SUCCESS in 1h 08m 20s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/13/check/tempest-dsvm-full-xenial-py3/77daee0/ : SUCCESS in 1h 17m 09s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/13/check/grenade-dsvm-xenial/3c37368/ : SUCCESS in 1h 03m 07s (non-voting)","accounts_in_message":[],"_revision_number":13},{"id":"4e4c6ff290052a7d196cc03abfcef2158afb4b9b","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-01-14 20:41:31.000000000","message":"Patch Set 13:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/13/check-vote/ext-nova-zuul/b4ee923 : SUCCESS in 53m 32s","accounts_in_message":[],"_revision_number":13},{"id":"12f00e19b4ab83e60b1092d9db10b516d15f6ac0","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2019-01-14 22:26:26.000000000","message":"Patch Set 13:\n\nBuild failed.  To recheck use \u0027xenserver: recheck\u0027.  For 3rd party ci contact info: https://wiki.openstack.org/wiki/ThirdPartySystems\n\n- dsvm-tempest-neutron-network http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/43/623543/13/check/dsvm-tempest-neutron-network/53d4da5 : FAILURE in 1h 36m 45s\n- test-vgpu http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/43/623543/13/check/test-vgpu/826d20b : FAILURE in 32m 59s (non-voting)","accounts_in_message":[],"_revision_number":13},{"id":"34f8ef9a15314b10c142abe55e1331b4ee5f5923","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-01-14 22:54:58.000000000","message":"Patch Set 13:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/13/check/nova-out-of-tree-pvm/4be01ba : FAILURE in 19m 15s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/13/check/nova-in-tree-pvm/e56af29 : SUCCESS in 1h 41m 58s","accounts_in_message":[],"_revision_number":13},{"id":"97fc8e74b9434aa472f7e130d93e7faeab779cc6","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-01-14 22:57:48.000000000","message":"Patch Set 13:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-26694 : SUCCESS in 2h 23m 25s","accounts_in_message":[],"_revision_number":13},{"id":"9a4028a8d7b9f65f34f6439a2d7e7a6636d629d1","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-01-15 03:29:09.000000000","message":"Patch Set 13:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/13/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/1a67f38 : SUCCESS in 1h 18m 30s","accounts_in_message":[],"_revision_number":13},{"id":"40b542f74c9d9f5ec14cfe5ba412c4dbd991ab4e","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-01-24 15:29:40.000000000","message":"Uploaded patch set 14.","accounts_in_message":[],"_revision_number":14},{"id":"0aa5f13d1f66fca1eb9e1f3e9e5e9829a1bcdf3b","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-01-24 15:34:09.000000000","message":"Patch Set 14: Workflow-1\n\nWIP, see TODOs in the commit message","accounts_in_message":[],"_revision_number":14},{"id":"a4c8311b1efeb5809fc58b2989d7366f0ebbaf76","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-01-24 15:53:17.000000000","message":"Patch Set 14:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":14},{"id":"6c3da10cd543367a8bf21acefd7a6060934b7346","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-01-24 16:06:35.000000000","message":"Patch Set 14:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/14 : FAILURE in 9m 23s","accounts_in_message":[],"_revision_number":14},{"id":"b4bce99654dc74b68719043134e3391442cc6aa6","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-01-24 16:21:55.000000000","message":"Uploaded patch set 15: Patch Set 14 was rebased.","accounts_in_message":[],"_revision_number":15},{"id":"bee114226cdd2037da341023cd233eadacb708cc","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-01-24 17:26:35.000000000","message":"Patch Set 15:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/15 : FAILURE in 1m 29s","accounts_in_message":[],"_revision_number":15},{"id":"9c44103e49ab926fd3123e6c2018f506e0cde936","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-01-24 17:27:26.000000000","message":"Patch Set 15:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":15},{"id":"0c86a4c2788f9d59adc45e66c82c7a92439ead91","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-01-24 19:55:48.000000000","message":"Patch Set 15:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/15/check/tempest-dsvm-full-xenial/c3b38bc/ : SUCCESS in 1h 02m 54s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/15/check/tempest-dsvm-full-xenial-py3/767b638/ : SUCCESS in 1h 16m 38s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/15/check/grenade-dsvm-xenial/d4d2b3a/ : SUCCESS in 58m 07s (non-voting)","accounts_in_message":[],"_revision_number":15},{"id":"9c81842be686f41560ac90c7447a63db53f7d199","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-01-24 20:13:10.000000000","message":"Patch Set 15:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/15/check-vote/ext-nova-zuul/a78c202 : SUCCESS in 1h 01m 37s","accounts_in_message":[],"_revision_number":15},{"id":"27691ae6a077d3ce333415ef9761c089ce894e1a","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-01-24 21:14:59.000000000","message":"Patch Set 15: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/15/check/tempest-full/80fd1a6/ : SUCCESS in 1h 54m 23s\n- neutron-grenade http://logs.openstack.org/43/623543/15/check/neutron-grenade/60b7ec9/ : SUCCESS in 1h 01m 34s\n- grenade-py3 http://logs.openstack.org/43/623543/15/check/grenade-py3/0405567/ : SUCCESS in 1h 08m 03s\n- tempest-full-py3 http://logs.openstack.org/43/623543/15/check/tempest-full-py3/52c0aaa/ : SUCCESS in 1h 57m 24s\n- openstack-tox-cover http://logs.openstack.org/43/623543/15/check/openstack-tox-cover/47f1363/ : FAILURE in 17m 04s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/15/check/openstack-tox-lower-constraints/bdf5c8f/ : FAILURE in 13m 37s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/15/check/openstack-tox-pep8/31c9ea2/ : FAILURE in 9m 28s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/15/check/openstack-tox-py27/56009e6/ : FAILURE in 15m 20s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/15/check/openstack-tox-py35/217be1b/ : FAILURE in 11m 53s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/15/check/openstack-tox-py36/085a7ed/ : FAILURE in 12m 20s\n- openstack-tox-docs http://logs.openstack.org/43/623543/15/check/openstack-tox-docs/bd285e6/html/ : SUCCESS in 6m 51s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/15/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/d859563/ : SUCCESS in 51m 49s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/15/check/devstack-plugin-ceph-tempest/b1fc67a/ : TIMED_OUT in 2h 04m 59s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/15/check/legacy-grenade-dsvm-neutron-multinode-live-migration/fa3ab90/ : FAILURE in 1h 06m 14s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/15/check/neutron-grenade-multinode/801cab1/ : SUCCESS in 1h 11m 12s\n- nova-live-migration http://logs.openstack.org/43/623543/15/check/nova-live-migration/950db85/ : SUCCESS in 44m 43s\n- nova-multiattach http://logs.openstack.org/43/623543/15/check/nova-multiattach/f8596df/ : SUCCESS in 1h 10m 05s\n- nova-next http://logs.openstack.org/43/623543/15/check/nova-next/f6b2828/ : SUCCESS in 1h 52m 35s\n- nova-tox-functional http://logs.openstack.org/43/623543/15/check/nova-tox-functional/e29b2e4/ : SUCCESS in 19m 42s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/15/check/nova-tox-functional-py35/a91ac08/ : SUCCESS in 19m 46s\n- tempest-multinode-full http://logs.openstack.org/43/623543/15/check/tempest-multinode-full/23def41/ : SUCCESS in 1h 49m 13s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/15/check/tempest-slow/17a6498/ : FAILURE in 2h 12m 35s","accounts_in_message":[],"_revision_number":15},{"id":"600c2395ffed71e2a6465e8245c19773ab30b4b1","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-01-24 22:28:08.000000000","message":"Patch Set 15:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-27004 : SUCCESS in 1h 40m 33s","accounts_in_message":[],"_revision_number":15},{"id":"458231fe194e46f5f449fec0b9b8a223a533c8b2","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-01-24 23:50:01.000000000","message":"Patch Set 15:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/15/check/nova-out-of-tree-pvm/bb1220e : FAILURE in 3h 52m 13s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/15/check/nova-in-tree-pvm/046fe85 : FAILURE in 3h 59m 46s","accounts_in_message":[],"_revision_number":15},{"id":"e7dd579e0de26580ad0f159b0d0179e4e5dcbfe8","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-01-25 09:53:34.000000000","message":"Patch Set 15:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/15/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/865ef78 : SUCCESS in 1h 23m 38s","accounts_in_message":[],"_revision_number":15},{"id":"327d1431efb61a927cbd5642a88a867fbd212176","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-01-26 16:32:54.000000000","message":"Uploaded patch set 16: Patch Set 15 was rebased.","accounts_in_message":[],"_revision_number":16},{"id":"89bab67620bf0ae29e18c37707edfd481e506363","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-01-26 17:24:46.000000000","message":"Patch Set 16:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":16},{"id":"de7937bfd2bf93a06855b80b6ddd5e2895db4c6d","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-01-26 18:56:06.000000000","message":"Patch Set 16:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/16/check-vote/ext-nova-zuul/eba3dac : FAILURE in 33m 17s","accounts_in_message":[],"_revision_number":16},{"id":"e8c88f886acb588a8beb2198daed948bbec7c434","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-01-26 19:23:49.000000000","message":"Patch Set 16:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/16/check/tempest-dsvm-full-xenial/2e39d46/ : SUCCESS in 1h 11m 17s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/16/check/tempest-dsvm-full-xenial-py3/1cb0f33/ : SUCCESS in 1h 17m 39s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/16/check/grenade-dsvm-xenial/70cfb00/ : SUCCESS in 57m 13s (non-voting)","accounts_in_message":[],"_revision_number":16},{"id":"20ed6d2511cb7a46dcd6747aa635298e4ca746e7","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-01-26 19:30:49.000000000","message":"Patch Set 16: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/16/check/tempest-full/b782ceb/ : SUCCESS in 1h 42m 12s\n- neutron-grenade http://logs.openstack.org/43/623543/16/check/neutron-grenade/22647b5/ : SUCCESS in 57m 48s\n- grenade-py3 http://logs.openstack.org/43/623543/16/check/grenade-py3/733f399/ : SUCCESS in 1h 02m 06s\n- tempest-full-py3 http://logs.openstack.org/43/623543/16/check/tempest-full-py3/6b930b7/ : SUCCESS in 1h 24m 47s\n- openstack-tox-cover http://logs.openstack.org/43/623543/16/check/openstack-tox-cover/8774b0e/ : FAILURE in 13m 50s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/16/check/openstack-tox-lower-constraints/fbf79ca/ : FAILURE in 12m 26s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/16/check/openstack-tox-pep8/21c144c/ : FAILURE in 9m 02s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/16/check/openstack-tox-py27/25ccb56/ : FAILURE in 12m 35s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/16/check/openstack-tox-py35/2dad5b1/ : FAILURE in 12m 24s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/16/check/openstack-tox-py36/cab2bd5/ : FAILURE in 12m 40s\n- openstack-tox-docs http://logs.openstack.org/43/623543/16/check/openstack-tox-docs/58a0f51/html/ : SUCCESS in 7m 36s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/16/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/a7e9d26/ : SUCCESS in 47m 33s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/16/check/devstack-plugin-ceph-tempest/4e0f6df/ : SUCCESS in 2h 02m 00s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/16/check/legacy-grenade-dsvm-neutron-multinode-live-migration/576cb30/ : FAILURE in 1h 06m 16s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/16/check/neutron-grenade-multinode/a168885/ : SUCCESS in 1h 06m 37s\n- nova-live-migration http://logs.openstack.org/43/623543/16/check/nova-live-migration/74c8df9/ : SUCCESS in 48m 06s\n- nova-multiattach http://logs.openstack.org/43/623543/16/check/nova-multiattach/ce0ac12/ : SUCCESS in 1h 07m 26s\n- nova-next http://logs.openstack.org/43/623543/16/check/nova-next/b0ece6e/ : SUCCESS in 1h 46m 56s\n- nova-tox-functional http://logs.openstack.org/43/623543/16/check/nova-tox-functional/2dd6ad9/ : SUCCESS in 18m 59s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/16/check/nova-tox-functional-py35/7ecc6f3/ : SUCCESS in 18m 04s\n- tempest-multinode-full http://logs.openstack.org/43/623543/16/check/tempest-multinode-full/c8c941c/ : SUCCESS in 1h 55m 29s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/16/check/tempest-slow/2ff4d8a/ : SUCCESS in 2h 16m 35s","accounts_in_message":[],"_revision_number":16},{"id":"5daa64dadb4f6d28f2d078df6afe62e9cb64128a","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-01-26 19:55:14.000000000","message":"Patch Set 16:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/16/check/nova-out-of-tree-pvm/526e9c3 : FAILURE in 2h 32m 19s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/16/check/nova-in-tree-pvm/f711009 : SUCCESS in 2h 19m 29s","accounts_in_message":[],"_revision_number":16},{"id":"365fdd52474ca56cf53ffafcd385b0ab3c863ae3","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-01-26 22:41:08.000000000","message":"Patch Set 16:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-27137 : FAILURE in 2h 10m 31s","accounts_in_message":[],"_revision_number":16},{"id":"1f6a67db0d586698961ef9584a2eec4b4ce69701","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-01-26 23:28:53.000000000","message":"Patch Set 16:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/16 : SUCCESS in 2h 19m 26s","accounts_in_message":[],"_revision_number":16},{"id":"5b4d2eefb761eb4e3464b979c8a8bb60c1e128db","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-01-27 19:46:49.000000000","message":"Patch Set 16:\n\nTesting failed ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenial-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/16/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/38c7d85 : FAILURE in 46s","accounts_in_message":[],"_revision_number":16},{"id":"3ed522e9d6aa6bf76e5f00d46791396598a77344","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-01-28 14:51:40.000000000","message":"Uploaded patch set 17: Patch Set 16 was rebased.","accounts_in_message":[],"_revision_number":17},{"id":"8c67565c8573460406d93d886cb495828f356e43","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-01-28 15:56:59.000000000","message":"Patch Set 17:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":17},{"id":"49689ed8d58d83cd4059d4d1155b8beaf16ecf32","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-01-28 16:27:38.000000000","message":"Patch Set 17:\n\nTesting failed ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenial-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/17/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/519b5f2 : FAILURE in 21s","accounts_in_message":[],"_revision_number":17},{"id":"cef91d34e6b60a758fea15c2a0b173397b5d2fec","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-01-28 17:51:19.000000000","message":"Patch Set 17:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/17/check/tempest-dsvm-full-xenial/c4fd2f6/ : SUCCESS in 1h 15m 13s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/17/check/tempest-dsvm-full-xenial-py3/de44f88/ : SUCCESS in 1h 27m 19s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/17/check/grenade-dsvm-xenial/a6c9784/ : SUCCESS in 1h 06m 39s (non-voting)","accounts_in_message":[],"_revision_number":17},{"id":"d9c16e42a12357e820724124e96d32d70ee96578","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-01-28 17:52:46.000000000","message":"Patch Set 17:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/17/check-vote/ext-nova-zuul/a90445a : FAILURE in 37m 58s","accounts_in_message":[],"_revision_number":17},{"id":"846aca747c289feacfee26acbca7f2de51bfcad3","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-01-28 19:37:56.000000000","message":"Patch Set 17:\n\nBuild succeeded.\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/17/check/nova-out-of-tree-pvm/06f0f56 : SUCCESS in 1h 39m 21s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/17/check/nova-in-tree-pvm/00d9d3b : SUCCESS in 2h 09m 05s","accounts_in_message":[],"_revision_number":17},{"id":"a08424b119f8f736fef6913b06c61c354b0951f5","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-01-28 20:13:05.000000000","message":"Patch Set 17: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/17/check/tempest-full/788457a/ : TIMED_OUT in 2h 05m 52s\n- neutron-grenade http://logs.openstack.org/43/623543/17/check/neutron-grenade/77ebcae/ : SUCCESS in 1h 29m 19s\n- grenade-py3 http://logs.openstack.org/43/623543/17/check/grenade-py3/26be669/ : SUCCESS in 1h 06m 05s\n- tempest-full-py3 http://logs.openstack.org/43/623543/17/check/tempest-full-py3/0b8fc2f/ : SUCCESS in 1h 39m 35s\n- openstack-tox-cover http://logs.openstack.org/43/623543/17/check/openstack-tox-cover/b2335c5/ : FAILURE in 14m 17s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/17/check/openstack-tox-lower-constraints/8682702/ : FAILURE in 13m 09s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/17/check/openstack-tox-pep8/9b7562a/ : FAILURE in 9m 54s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/17/check/openstack-tox-py27/6e01487/ : FAILURE in 13m 28s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/17/check/openstack-tox-py35/b126519/ : FAILURE in 12m 14s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/17/check/openstack-tox-py36/dd8bf9a/ : FAILURE in 11m 42s\n- openstack-tox-docs http://logs.openstack.org/43/623543/17/check/openstack-tox-docs/db7f83a/html/ : SUCCESS in 6m 42s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/17/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/15544c7/ : SUCCESS in 50m 50s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/17/check/devstack-plugin-ceph-tempest/03ec148/ : TIMED_OUT in 2h 04m 53s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/17/check/legacy-grenade-dsvm-neutron-multinode-live-migration/d5b01a5/ : FAILURE in 1h 07m 36s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/17/check/neutron-grenade-multinode/7962959/ : SUCCESS in 59m 57s\n- nova-live-migration http://logs.openstack.org/43/623543/17/check/nova-live-migration/76551de/ : SUCCESS in 1h 08m 11s\n- nova-multiattach http://logs.openstack.org/43/623543/17/check/nova-multiattach/77a1d32/ : SUCCESS in 1h 26m 06s\n- nova-next http://logs.openstack.org/43/623543/17/check/nova-next/48180d8/ : SUCCESS in 2h 01m 06s\n- nova-tox-functional http://logs.openstack.org/43/623543/17/check/nova-tox-functional/bbb78c5/ : SUCCESS in 19m 51s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/17/check/nova-tox-functional-py35/6a46bbd/ : SUCCESS in 20m 33s\n- tempest-multinode-full http://logs.openstack.org/43/623543/17/check/tempest-multinode-full/e314efc/ : SUCCESS in 2h 04m 47s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/17/check/tempest-slow/cacfcf2/ : SUCCESS in 2h 19m 13s","accounts_in_message":[],"_revision_number":17},{"id":"069c3707610fc784eea3e84daa458dc43472b4ef","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-01-28 21:28:38.000000000","message":"Patch Set 17:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-27184 : SUCCESS in 2h 39m 27s","accounts_in_message":[],"_revision_number":17},{"id":"0fb7057b014a6a163a3d7191cf4a6c508753f7da","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-01-28 21:52:08.000000000","message":"Patch Set 17:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/17 : SUCCESS in 2h 12m 17s","accounts_in_message":[],"_revision_number":17},{"id":"4a6ae5fac44b13908813d77ef9d21bf2c7dedbbb","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-05 10:54:46.000000000","message":"Uploaded patch set 18: Patch Set 17 was rebased.","accounts_in_message":[],"_revision_number":18},{"id":"ddd9da765748e0c3d9c7e0587d9aa6491c8e4a66","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-05 12:07:26.000000000","message":"Patch Set 18:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/18/check-vote/ext-nova-zuul/b37673d : SUCCESS in 57m 04s","accounts_in_message":[],"_revision_number":18},{"id":"f2bf265751263f02f244e6c7d32298239ae286b9","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-05 12:35:11.000000000","message":"Patch Set 18:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/18/check/tempest-dsvm-full-xenial/fda5e5d/ : SUCCESS in 1h 03m 28s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/18/check/tempest-dsvm-full-xenial-py3/3831aa7/ : SUCCESS in 1h 12m 55s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/18/check/grenade-dsvm-xenial/2061f75/ : SUCCESS in 1h 04m 48s (non-voting)","accounts_in_message":[],"_revision_number":18},{"id":"74b20b8fbf0c56ab978eec26a367a0d1f1756069","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-05 13:31:18.000000000","message":"Patch Set 18: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/18/check/tempest-full/eb7fe54/ : FAILURE in 1h 19m 03s\n- neutron-grenade http://logs.openstack.org/43/623543/18/check/neutron-grenade/e95b944/ : SUCCESS in 56m 43s\n- grenade-py3 http://logs.openstack.org/43/623543/18/check/grenade-py3/67d3405/ : SUCCESS in 1h 08m 25s\n- tempest-full-py3 http://logs.openstack.org/43/623543/18/check/tempest-full-py3/2eb659f/ : SUCCESS in 1h 35m 49s\n- openstack-tox-cover http://logs.openstack.org/43/623543/18/check/openstack-tox-cover/13429e6/ : FAILURE in 6m 10s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/18/check/openstack-tox-lower-constraints/606c7be/ : FAILURE in 7m 16s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/18/check/openstack-tox-pep8/06be583/ : FAILURE in 10m 14s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/18/check/openstack-tox-py27/db1a5dd/ : FAILURE in 6m 21s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/18/check/openstack-tox-py35/ae14eed/ : FAILURE in 6m 47s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/18/check/openstack-tox-py36/d679771/ : FAILURE in 6m 21s\n- openstack-tox-docs http://logs.openstack.org/43/623543/18/check/openstack-tox-docs/1ab09ec/html/ : SUCCESS in 7m 13s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/18/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/29d682e/ : SUCCESS in 56m 55s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/18/check/devstack-plugin-ceph-tempest/f531aaf/ : SUCCESS in 1h 56m 19s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/18/check/legacy-grenade-dsvm-neutron-multinode-live-migration/a8e46c6/ : FAILURE in 1h 18m 34s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/18/check/neutron-grenade-multinode/b33e572/ : SUCCESS in 1h 11m 06s\n- nova-live-migration http://logs.openstack.org/43/623543/18/check/nova-live-migration/16880e0/ : SUCCESS in 51m 09s\n- nova-multiattach http://logs.openstack.org/43/623543/18/check/nova-multiattach/d63b439/ : SUCCESS in 1h 18m 12s\n- nova-next http://logs.openstack.org/43/623543/18/check/nova-next/917fe89/ : SUCCESS in 2h 09m 06s\n- nova-tox-functional http://logs.openstack.org/43/623543/18/check/nova-tox-functional/abdf906/ : SUCCESS in 20m 36s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/18/check/nova-tox-functional-py35/6c7826d/ : SUCCESS in 18m 22s\n- tempest-multinode-full http://logs.openstack.org/43/623543/18/check/tempest-multinode-full/abb2f7b/ : SUCCESS in 2h 00m 17s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/18/check/tempest-slow/7e44637/ : SUCCESS in 2h 14m 24s","accounts_in_message":[],"_revision_number":18},{"id":"f692ccadadf1803bf9be16f40fb5c813dbab0d80","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-05 14:54:33.000000000","message":"Patch Set 18:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/18 : FAILURE in 2h 38m 31s","accounts_in_message":[],"_revision_number":18},{"id":"4538f1ae2b9834156bccf420661d51b8a2ed98d9","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-05 15:42:49.000000000","message":"Uploaded patch set 19.","accounts_in_message":[],"_revision_number":19},{"id":"34e803b135e19fa13ed0ca8fc1701c6ee6b33327","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-05 16:38:47.000000000","message":"Patch Set 19:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/19/check-vote/ext-nova-zuul/e93da19 : SUCCESS in 54m 12s","accounts_in_message":[],"_revision_number":19},{"id":"58049c039e200125a76fd85eda2e290686f4b24c","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-05 16:58:59.000000000","message":"Patch Set 19:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/19/check/tempest-dsvm-full-xenial/7e150bc/ : SUCCESS in 1h 08m 39s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/19/check/tempest-dsvm-full-xenial-py3/5bf6e7f/ : SUCCESS in 1h 14m 00s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/19/check/grenade-dsvm-xenial/00f2447/ : SUCCESS in 52m 07s (non-voting)","accounts_in_message":[],"_revision_number":19},{"id":"925b599cf11d28a002f3f8a643a25729bd1df355","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-05 17:54:10.000000000","message":"Patch Set 19: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/19/check/tempest-full/94899dc/ : SUCCESS in 1h 52m 30s\n- neutron-grenade http://logs.openstack.org/43/623543/19/check/neutron-grenade/9d4fa51/ : SUCCESS in 50m 03s\n- grenade-py3 http://logs.openstack.org/43/623543/19/check/grenade-py3/2420c08/ : SUCCESS in 55m 37s\n- tempest-full-py3 http://logs.openstack.org/43/623543/19/check/tempest-full-py3/405e050/ : FAILURE in 59m 37s\n- openstack-tox-cover http://logs.openstack.org/43/623543/19/check/openstack-tox-cover/1fabb4b/ : FAILURE in 5m 40s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/19/check/openstack-tox-lower-constraints/99e87a7/ : FAILURE in 5m 21s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/19/check/openstack-tox-pep8/84e6452/ : FAILURE in 9m 58s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/19/check/openstack-tox-py27/f8b71c3/ : FAILURE in 5m 56s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/19/check/openstack-tox-py35/3c8c15f/ : FAILURE in 5m 37s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/19/check/openstack-tox-py36/85e2bdb/ : FAILURE in 5m 26s\n- openstack-tox-docs http://logs.openstack.org/43/623543/19/check/openstack-tox-docs/cea67e2/html/ : SUCCESS in 7m 43s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/19/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/8ca5795/ : SUCCESS in 46m 08s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/19/check/devstack-plugin-ceph-tempest/61c2140/ : TIMED_OUT in 2h 06m 35s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/19/check/legacy-grenade-dsvm-neutron-multinode-live-migration/be3db2e/ : FAILURE in 1h 01m 48s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/19/check/neutron-grenade-multinode/9e391cc/ : SUCCESS in 1h 03m 02s\n- nova-live-migration http://logs.openstack.org/43/623543/19/check/nova-live-migration/bc7d621/ : SUCCESS in 44m 06s\n- nova-multiattach http://logs.openstack.org/43/623543/19/check/nova-multiattach/3a0e47f/ : SUCCESS in 1h 18m 03s\n- nova-next http://logs.openstack.org/43/623543/19/check/nova-next/fa5a866/ : SUCCESS in 1h 39m 49s\n- nova-tox-functional http://logs.openstack.org/43/623543/19/check/nova-tox-functional/83c0767/ : SUCCESS in 17m 30s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/19/check/nova-tox-functional-py35/6341ffa/ : SUCCESS in 31m 51s\n- tempest-multinode-full http://logs.openstack.org/43/623543/19/check/tempest-multinode-full/3a9e3d5/ : SUCCESS in 1h 48m 33s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/19/check/tempest-slow/b4017eb/ : SUCCESS in 1h 57m 05s","accounts_in_message":[],"_revision_number":19},{"id":"d29f2f09adc7a4d1dd9d3b9c8ffc6f424700ff13","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-05 18:51:30.000000000","message":"Patch Set 19:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/19 : FAILURE in 2h 31m 49s","accounts_in_message":[],"_revision_number":19},{"id":"a976715d72f1e2678c3bed3eb86dbd64a814f147","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-02-05 21:47:30.000000000","message":"Patch Set 19:\n\nBuild succeeded.\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/19/check/nova-out-of-tree-pvm/c2a763e : SUCCESS in 2h 05m 44s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/19/check/nova-in-tree-pvm/86364fd : SUCCESS in 1h 59m 07s","accounts_in_message":[],"_revision_number":19},{"id":"1bce5cf68d0123c73cc5c02cc9c5cd88958c900d","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-02-06 04:28:25.000000000","message":"Patch Set 19:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/19/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/19dc96d : SUCCESS in 1h 14m 11s","accounts_in_message":[],"_revision_number":19},{"id":"7e7c1543d841901e9d250597a25a02af4adf2858","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-06 15:16:54.000000000","message":"Uploaded patch set 20: Patch Set 19 was rebased.","accounts_in_message":[],"_revision_number":20},{"id":"894a4c740fd9037b88407987ad526b576f411347","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-06 16:47:30.000000000","message":"Patch Set 20:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/20/check-vote/ext-nova-zuul/746b4b9 : FAILURE in 6m 26s","accounts_in_message":[],"_revision_number":20},{"id":"eaa09393bcb372b4fde14d39a39dd496f4e620d5","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-06 16:57:02.000000000","message":"Patch Set 20:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/20/check/tempest-dsvm-full-xenial/b593390/ : SUCCESS in 1h 13m 40s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/20/check/tempest-dsvm-full-xenial-py3/1f415c5/ : SUCCESS in 1h 18m 14s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/20/check/grenade-dsvm-xenial/395a112/ : SUCCESS in 56m 57s (non-voting)","accounts_in_message":[],"_revision_number":20},{"id":"0930fb2f5c7c136330a49d43989257754a201147","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-06 18:57:06.000000000","message":"Patch Set 20: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/20/check/tempest-full/44ca60f/ : SUCCESS in 1h 43m 51s\n- neutron-grenade http://logs.openstack.org/43/623543/20/check/neutron-grenade/86ac316/ : SUCCESS in 1h 09m 21s\n- grenade-py3 http://logs.openstack.org/43/623543/20/check/grenade-py3/6173d34/ : SUCCESS in 1h 00m 42s\n- tempest-full-py3 http://logs.openstack.org/43/623543/20/check/tempest-full-py3/c23e932/ : SUCCESS in 1h 40m 23s\n- openstack-tox-cover http://logs.openstack.org/43/623543/20/check/openstack-tox-cover/592ff95/ : FAILURE in 19m 08s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/20/check/openstack-tox-lower-constraints/70d3aba/ : FAILURE in 12m 49s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/20/check/openstack-tox-pep8/5ac2f55/ : FAILURE in 10m 58s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/20/check/openstack-tox-py27/eb96d34/ : FAILURE in 13m 37s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/20/check/openstack-tox-py35/9176c27/ : FAILURE in 13m 57s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/20/check/openstack-tox-py36/37b1512/ : FAILURE in 13m 16s\n- openstack-tox-docs http://logs.openstack.org/43/623543/20/check/openstack-tox-docs/5b7a5d2/html/ : SUCCESS in 9m 38s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/20/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/b2438c5/ : SUCCESS in 49m 27s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/20/check/devstack-plugin-ceph-tempest/aebca29/ : TIMED_OUT in 2h 06m 51s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/20/check/legacy-grenade-dsvm-neutron-multinode-live-migration/1c980e7/ : FAILURE in 1h 20m 03s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/20/check/neutron-grenade-multinode/b6333e4/ : SUCCESS in 59m 57s\n- nova-live-migration http://logs.openstack.org/43/623543/20/check/nova-live-migration/831c29d/ : SUCCESS in 51m 43s\n- nova-multiattach http://logs.openstack.org/43/623543/20/check/nova-multiattach/0a7caac/ : SUCCESS in 1h 29m 02s\n- nova-next http://logs.openstack.org/43/623543/20/check/nova-next/d9be675/ : SUCCESS in 2h 07m 10s\n- nova-tox-functional http://logs.openstack.org/43/623543/20/check/nova-tox-functional/aaebc40/ : SUCCESS in 18m 08s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/20/check/nova-tox-functional-py35/7469188/ : SUCCESS in 19m 57s\n- tempest-multinode-full http://logs.openstack.org/43/623543/20/check/tempest-multinode-full/b4d087e/ : SUCCESS in 1h 44m 46s (non-voting)\n- tempest-slow http://logs.openstack.org/43/623543/20/check/tempest-slow/9e8fb7e/ : SUCCESS in 2h 01m 49s","accounts_in_message":[],"_revision_number":20},{"id":"e7d6a881287197be65e92958071cfe8a0c01bbf4","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-06 20:29:32.000000000","message":"Patch Set 20:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/20 : FAILURE in 2h 14m 23s","accounts_in_message":[],"_revision_number":20},{"id":"586e2205e5c634093a94ee01927ffd00871839bb","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-02-07 22:53:32.000000000","message":"Patch Set 20:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/20/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/2b22742 : SUCCESS in 1h 16m 25s","accounts_in_message":[],"_revision_number":20},{"id":"944d607434b136e40b8b42214e20038964e48ba3","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-02-08 01:07:13.000000000","message":"Uploaded patch set 21: Patch Set 20 was rebased.","accounts_in_message":[],"_revision_number":21},{"id":"c24a8a4a05110882d7037c39e0b5dfe44a394a6b","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-08 03:23:58.000000000","message":"Patch Set 21:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/21/check/tempest-dsvm-full-xenial/4eea971/ : SUCCESS in 1h 13m 02s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/21/check/tempest-dsvm-full-xenial-py3/abc561c/ : SUCCESS in 1h 51m 26s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/21/check/grenade-dsvm-xenial/2a1256c/ : SUCCESS in 1h 00m 22s (non-voting)","accounts_in_message":[],"_revision_number":21},{"id":"1aa01e3b87ed26bb792abd62170bd1cb17b92b24","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-08 03:26:46.000000000","message":"Patch Set 21: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/21/check/tempest-full/872e291/ : SUCCESS in 1h 58m 49s\n- neutron-grenade http://logs.openstack.org/43/623543/21/check/neutron-grenade/59ab0b2/ : SUCCESS in 56m 05s\n- grenade-py3 http://logs.openstack.org/43/623543/21/check/grenade-py3/420f604/ : SUCCESS in 1h 00m 21s\n- tempest-full-py3 http://logs.openstack.org/43/623543/21/check/tempest-full-py3/c720b63/ : SUCCESS in 1h 37m 06s\n- openstack-tox-cover http://logs.openstack.org/43/623543/21/check/openstack-tox-cover/d135fdc/ : FAILURE in 13m 55s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/21/check/openstack-tox-lower-constraints/ab31b38/ : FAILURE in 14m 17s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/21/check/openstack-tox-pep8/ef68994/ : FAILURE in 10m 08s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/21/check/openstack-tox-py27/79047a0/ : FAILURE in 17m 18s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/21/check/openstack-tox-py35/69caf27/ : FAILURE in 13m 44s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/21/check/openstack-tox-py36/2c4aeff/ : FAILURE in 15m 07s\n- openstack-tox-docs http://logs.openstack.org/43/623543/21/check/openstack-tox-docs/ffd17c5/html/ : SUCCESS in 6m 41s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/21/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/4612ae4/ : SUCCESS in 51m 09s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/21/check/devstack-plugin-ceph-tempest/c80b2b1/ : FAILURE in 2h 04m 39s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/21/check/legacy-grenade-dsvm-neutron-multinode-live-migration/ca85a9c/ : FAILURE in 59m 27s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/21/check/neutron-grenade-multinode/b620bf4/ : SUCCESS in 1h 07m 28s\n- nova-live-migration http://logs.openstack.org/43/623543/21/check/nova-live-migration/78664cf/ : SUCCESS in 49m 01s\n- nova-multiattach http://logs.openstack.org/43/623543/21/check/nova-multiattach/33a4148/ : SUCCESS in 1h 24m 09s\n- nova-next http://logs.openstack.org/43/623543/21/check/nova-next/94fb578/ : SUCCESS in 1h 52m 26s\n- nova-tox-functional http://logs.openstack.org/43/623543/21/check/nova-tox-functional/64dab25/ : SUCCESS in 20m 27s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/21/check/nova-tox-functional-py35/c6ecaaa/ : SUCCESS in 18m 04s\n- tempest-multinode-full http://logs.openstack.org/43/623543/21/check/tempest-multinode-full/53332a2/ : SUCCESS in 1h 54m 37s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/21/check/tempest-slow-py3/1ba740b/ : SUCCESS in 2h 02m 43s","accounts_in_message":[],"_revision_number":21},{"id":"79d9c6bddde32c828d68b47453137d46e29b3edf","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-08 03:55:20.000000000","message":"Patch Set 21:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/21/check-vote/ext-nova-zuul/b857164 : FAILURE in 8m 28s","accounts_in_message":[],"_revision_number":21},{"id":"8459ff2d1a7a9de090d45659effeb2722c45c904","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-08 08:28:15.000000000","message":"Patch Set 21:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/21 : SUCCESS in 2h 20m 27s","accounts_in_message":[],"_revision_number":21},{"id":"bda122b9527a12816cf21c31f886a78f86c8691b","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-02-08 14:10:50.000000000","message":"Patch Set 21:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/21/check/nova-out-of-tree-pvm/912d5d0 : FAILURE in 1m 12s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/21/check/nova-in-tree-pvm/ec582a2 : FAILURE in 1m 49s","accounts_in_message":[],"_revision_number":21},{"id":"8d9f629fd423894b1348d243ee9e6ca7bca96dac","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-02-09 17:39:57.000000000","message":"Patch Set 21:\n\nTesting failed ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenial-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/21/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/4815ba7 : FAILURE in 20m 28s","accounts_in_message":[],"_revision_number":21},{"id":"f9d4f3c65918e06874333677ecc83d2ff091e6b6","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-02-12 09:22:08.000000000","message":"Patch Set 21:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-27391 : FAILURE in 1h 18m 29s","accounts_in_message":[],"_revision_number":21},{"id":"5d8f51da2933f8a0337f2a33781f690eb25b7581","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-12 09:46:07.000000000","message":"Uploaded patch set 22: Patch Set 21 was rebased.","accounts_in_message":[],"_revision_number":22},{"id":"6ce686115e871b502872dac313c4dc4169305e73","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-12 09:55:08.000000000","message":"Patch Set 22:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":22},{"id":"368a17faa73c61d0cb4a050716bfd73b6d237694","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-12 10:01:09.000000000","message":"Patch Set 22:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/22/check-vote/ext-nova-zuul/f6979c2 : FAILURE in 6m 08s","accounts_in_message":[],"_revision_number":22},{"id":"4fba1e5d1b2e58a65bad74e9349991f6d52bcf32","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-12 11:20:52.000000000","message":"Patch Set 22:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/22/check/tempest-dsvm-full-xenial/33ff5eb/ : SUCCESS in 1h 20m 42s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/22/check/tempest-dsvm-full-xenial-py3/5659d6c/ : SUCCESS in 1h 15m 04s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/22/check/grenade-dsvm-xenial/359a444/ : SUCCESS in 55m 13s (non-voting)","accounts_in_message":[],"_revision_number":22},{"id":"ca0cd4290ac2718c1bc49255a39b53c55e7bb73a","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-02-12 11:45:09.000000000","message":"Patch Set 22:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/22/check/nova-out-of-tree-pvm/db4d568 : SUCCESS in 1h 50m 45s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/22/check/nova-in-tree-pvm/ec94f9f : FAILURE in 1h 53m 18s","accounts_in_message":[],"_revision_number":22},{"id":"07689c3ca14a402f2e9f835e4cea695977020c69","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-12 11:54:50.000000000","message":"Patch Set 22: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/22/check/tempest-full/4e4600b/ : SUCCESS in 1h 46m 49s\n- neutron-grenade http://logs.openstack.org/43/623543/22/check/neutron-grenade/dcf37a1/ : SUCCESS in 53m 48s\n- grenade-py3 http://logs.openstack.org/43/623543/22/check/grenade-py3/c18ed40/ : SUCCESS in 1h 04m 52s\n- tempest-full-py3 http://logs.openstack.org/43/623543/22/check/tempest-full-py3/9b8f7b7/ : SUCCESS in 1h 34m 39s\n- openstack-tox-cover http://logs.openstack.org/43/623543/22/check/openstack-tox-cover/3a31a5b/ : FAILURE in 15m 10s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/22/check/openstack-tox-lower-constraints/e3ebd85/ : FAILURE in 12m 00s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/22/check/openstack-tox-pep8/220029f/ : FAILURE in 9m 28s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/22/check/openstack-tox-py27/fafedf5/ : FAILURE in 12m 26s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/22/check/openstack-tox-py35/db9ba0c/ : FAILURE in 13m 43s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/22/check/openstack-tox-py36/a0c6910/ : FAILURE in 10m 46s\n- openstack-tox-docs http://logs.openstack.org/43/623543/22/check/openstack-tox-docs/c71d5c8/html/ : SUCCESS in 9m 46s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/22/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/c3c58cc/ : SUCCESS in 55m 50s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/22/check/devstack-plugin-ceph-tempest/bdd4ea0/ : SUCCESS in 1h 57m 51s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/22/check/legacy-grenade-dsvm-neutron-multinode-live-migration/cbdfdcd/ : FAILURE in 1h 17m 09s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/22/check/neutron-grenade-multinode/d61767a/ : SUCCESS in 1h 17m 51s\n- nova-live-migration http://logs.openstack.org/43/623543/22/check/nova-live-migration/4ab659a/ : SUCCESS in 52m 52s\n- nova-next http://logs.openstack.org/43/623543/22/check/nova-next/fa2dbf2/ : SUCCESS in 1h 47m 37s\n- nova-tox-functional http://logs.openstack.org/43/623543/22/check/nova-tox-functional/6620753/ : SUCCESS in 19m 20s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/22/check/nova-tox-functional-py35/e5f6680/ : SUCCESS in 19m 05s\n- tempest-multinode-full http://logs.openstack.org/43/623543/22/check/tempest-multinode-full/b059e6a/ : SUCCESS in 1h 51m 24s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/22/check/tempest-slow-py3/a362543/ : SUCCESS in 1h 57m 37s","accounts_in_message":[],"_revision_number":22},{"id":"ee3bd098b22dfb885a975a4fa922af15137d2de1","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-12 12:13:43.000000000","message":"Patch Set 22:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/22 : SUCCESS in 2h 17m 37s","accounts_in_message":[],"_revision_number":22},{"id":"2fd182105ad95c93bfe4fe5e1e9a8471988c179f","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-12 13:49:22.000000000","message":"Uploaded patch set 23.","accounts_in_message":[],"_revision_number":23},{"id":"ae1f3fddfe0e28b3d103fc89b884e05a22ea1860","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-12 13:51:23.000000000","message":"Patch Set 23:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/23/check-vote/ext-nova-zuul/9e3e6e8 : FAILURE in 36s","accounts_in_message":[],"_revision_number":23},{"id":"78a1e05397794044eda3aca05dff2e286ead41dd","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-12 13:51:28.000000000","message":"Patch Set 23:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":23},{"id":"51ff8bb937557cb989e41a34bc620f57aac75310","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-12 15:11:55.000000000","message":"Patch Set 23:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/23/check/tempest-dsvm-full-xenial/5189f79/ : SUCCESS in 1h 08m 52s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/23/check/tempest-dsvm-full-xenial-py3/f1dacf1/ : SUCCESS in 1h 20m 22s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/23/check/grenade-dsvm-xenial/a9f9df0/ : SUCCESS in 56m 36s (non-voting)","accounts_in_message":[],"_revision_number":23},{"id":"7297fd2834243a9bc069df01c6c2939c87fa937f","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-12 16:02:57.000000000","message":"Patch Set 23: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/23/check/tempest-full/cf833ee/ : SUCCESS in 1h 59m 20s\n- neutron-grenade http://logs.openstack.org/43/623543/23/check/neutron-grenade/b917ab1/ : SUCCESS in 1h 01m 17s\n- grenade-py3 http://logs.openstack.org/43/623543/23/check/grenade-py3/f81ec9c/ : SUCCESS in 1h 03m 02s\n- tempest-full-py3 http://logs.openstack.org/43/623543/23/check/tempest-full-py3/ef418ae/ : SUCCESS in 1h 36m 49s\n- openstack-tox-cover http://logs.openstack.org/43/623543/23/check/openstack-tox-cover/0830596/cover/ : SUCCESS in 15m 10s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/23/check/openstack-tox-lower-constraints/64eb9aa/ : FAILURE in 12m 36s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/23/check/openstack-tox-pep8/b00f168/ : SUCCESS in 10m 17s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/23/check/openstack-tox-py27/e1a6cc6/ : SUCCESS in 12m 45s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/23/check/openstack-tox-py35/45409a2/ : SUCCESS in 13m 21s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/23/check/openstack-tox-py36/ed658e7/ : SUCCESS in 12m 03s\n- openstack-tox-docs http://logs.openstack.org/43/623543/23/check/openstack-tox-docs/49bc59f/html/ : SUCCESS in 6m 02s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/23/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/5999445/ : SUCCESS in 45m 44s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/23/check/devstack-plugin-ceph-tempest/2315020/ : TIMED_OUT in 2h 05m 06s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/23/check/legacy-grenade-dsvm-neutron-multinode-live-migration/0a25112/ : FAILURE in 1h 03m 02s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/23/check/neutron-grenade-multinode/248aff6/ : SUCCESS in 1h 03m 43s\n- nova-live-migration http://logs.openstack.org/43/623543/23/check/nova-live-migration/466bd8f/ : SUCCESS in 47m 06s\n- nova-next http://logs.openstack.org/43/623543/23/check/nova-next/f9d84e8/ : SUCCESS in 1h 36m 39s\n- nova-tox-functional http://logs.openstack.org/43/623543/23/check/nova-tox-functional/da1a572/ : SUCCESS in 16m 30s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/23/check/nova-tox-functional-py35/ff750f9/ : SUCCESS in 19m 53s\n- tempest-multinode-full http://logs.openstack.org/43/623543/23/check/tempest-multinode-full/8d619d4/ : SUCCESS in 1h 56m 16s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/23/check/tempest-slow-py3/9772157/ : SUCCESS in 2h 02m 42s","accounts_in_message":[],"_revision_number":23},{"id":"30d03c6ad7dd91f7a8132ebacff7dde5dd16d7b2","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-12 16:06:04.000000000","message":"Uploaded patch set 24: Patch Set 23 was rebased.","accounts_in_message":[],"_revision_number":24},{"id":"7fb5ebe46623ec514b17cc9a6e1a59781d601528","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-12 16:17:46.000000000","message":"Patch Set 24:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":24},{"id":"81055056948ddf9c6104c1e32e287621aad44e0e","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-12 16:31:54.000000000","message":"Patch Set 24:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":24},{"id":"990cc3e2f00cd734442ab9ba61b80eb02194d630","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-12 17:42:10.000000000","message":"Patch Set 24:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/24/check/tempest-dsvm-full-xenial/e4c24e0/ : SUCCESS in 1h 19m 23s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/24/check/tempest-dsvm-full-xenial-py3/7b50b95/ : SUCCESS in 1h 15m 55s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/24/check/grenade-dsvm-xenial/87f41a6/ : SUCCESS in 58m 11s (non-voting)","accounts_in_message":[],"_revision_number":24},{"id":"1c65de7e612a2c43990d1a8e217d11e81dae5ea7","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-02-12 18:46:43.000000000","message":"Patch Set 24:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/24/check/nova-out-of-tree-pvm/40a6023 : FAILURE in 2m 20s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/24/check/nova-in-tree-pvm/f75d51d : FAILURE in 1m 13s","accounts_in_message":[],"_revision_number":24},{"id":"ce6c3f4e3bbcae5f88cb3130197c61218fc6a591","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-12 19:22:13.000000000","message":"Patch Set 24: Verified+1\n\nBuild succeeded (check pipeline).\n\n- tempest-full http://logs.openstack.org/43/623543/24/check/tempest-full/d25f922/ : SUCCESS in 1h 46m 13s\n- neutron-grenade http://logs.openstack.org/43/623543/24/check/neutron-grenade/dada218/ : SUCCESS in 56m 00s\n- grenade-py3 http://logs.openstack.org/43/623543/24/check/grenade-py3/b364303/ : SUCCESS in 1h 03m 17s\n- tempest-full-py3 http://logs.openstack.org/43/623543/24/check/tempest-full-py3/b5bb41c/ : SUCCESS in 1h 42m 50s\n- openstack-tox-cover http://logs.openstack.org/43/623543/24/check/openstack-tox-cover/dc8f5f7/cover/ : SUCCESS in 16m 37s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/24/check/openstack-tox-lower-constraints/63a5ebf/ : SUCCESS in 12m 35s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/24/check/openstack-tox-pep8/e9e7abd/ : SUCCESS in 13m 13s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/24/check/openstack-tox-py27/432b109/ : SUCCESS in 15m 16s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/24/check/openstack-tox-py35/770a2a7/ : SUCCESS in 14m 05s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/24/check/openstack-tox-py36/76309e7/ : SUCCESS in 11m 09s\n- openstack-tox-docs http://logs.openstack.org/43/623543/24/check/openstack-tox-docs/7eb1415/html/ : SUCCESS in 9m 48s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/24/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/8fe280e/ : SUCCESS in 51m 19s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/24/check/devstack-plugin-ceph-tempest/e1a263e/ : TIMED_OUT in 2h 04m 45s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/24/check/legacy-grenade-dsvm-neutron-multinode-live-migration/c641abb/ : FAILURE in 1h 08m 28s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/24/check/neutron-grenade-multinode/be7c856/ : SUCCESS in 1h 15m 25s\n- nova-live-migration http://logs.openstack.org/43/623543/24/check/nova-live-migration/2f57fee/ : SUCCESS in 57m 15s\n- nova-next http://logs.openstack.org/43/623543/24/check/nova-next/083b2ca/ : SUCCESS in 2h 06m 12s\n- nova-tox-functional http://logs.openstack.org/43/623543/24/check/nova-tox-functional/9802fcd/ : SUCCESS in 17m 58s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/24/check/nova-tox-functional-py35/58ebdba/ : SUCCESS in 21m 36s\n- tempest-multinode-full http://logs.openstack.org/43/623543/24/check/tempest-multinode-full/aa17427/ : SUCCESS in 1h 46m 29s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/24/check/tempest-slow-py3/ac6d155/ : SUCCESS in 2h 07m 50s","accounts_in_message":[],"_revision_number":24},{"id":"7919e124ff8f0bf5c42e73f903a156099e6ed47b","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-12 21:47:00.000000000","message":"Patch Set 24:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/24 : SUCCESS in 2h 34m 22s","accounts_in_message":[],"_revision_number":24},{"id":"51d2763de1e0c950eb8ddbbaa0ea9aa61e986aa7","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-02-12 23:07:45.000000000","message":"Patch Set 24:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-24 : FAILURE \n\nSee https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI for rechecking and info.","accounts_in_message":[],"_revision_number":24},{"id":"184ad0cd7de766c0833ae50c3c78c411be505922","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-02-13 01:39:45.000000000","message":"Patch Set 24:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-27479 : FAILURE in 2h 22m 16s","accounts_in_message":[],"_revision_number":24},{"id":"3ecc9f5ec221611a05eb20ba9ec7c3757f59a17f","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-02-13 07:23:38.000000000","message":"Patch Set 24:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/24/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/c322008 : SUCCESS in 1h 17m 17s","accounts_in_message":[],"_revision_number":24},{"id":"1038894adfdc8af99125f21c53e62dc3bffd08fa","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-13 10:04:58.000000000","message":"Uploaded patch set 25: Patch Set 24 was rebased.","accounts_in_message":[],"_revision_number":25},{"id":"3a6584be0a497afae59a3eb5fc560ada9915a444","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-13 10:16:32.000000000","message":"Patch Set 25:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":25},{"id":"16770d0125e3335ae440de9f6da1ff2ae57c2f0a","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-13 10:23:02.000000000","message":"Patch Set 25:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/25/check-vote/ext-nova-zuul/457efd6 : FAILURE in 6m 58s","accounts_in_message":[],"_revision_number":25},{"id":"c2d77485caf0e4669127d5d9e9da10ecbd1201b0","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-13 11:43:04.000000000","message":"Patch Set 25:\n\nBuild succeeded. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/25/check/tempest-dsvm-full-xenial/751e4ef/ : SUCCESS in 1h 14m 00s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/25/check/tempest-dsvm-full-xenial-py3/6bb4559/ : SUCCESS in 1h 21m 14s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/25/check/grenade-dsvm-xenial/d64bd7d/ : SUCCESS in 1h 01m 34s (non-voting)","accounts_in_message":[],"_revision_number":25},{"id":"51feb91533f4b9ec5b88f08d3583dd7d14340a36","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-13 12:23:16.000000000","message":"Patch Set 25: Verified+1\n\nBuild succeeded (check pipeline).\n\n- tempest-full http://logs.openstack.org/43/623543/25/check/tempest-full/1970a79/ : SUCCESS in 1h 42m 30s\n- neutron-grenade http://logs.openstack.org/43/623543/25/check/neutron-grenade/1d618e3/ : SUCCESS in 50m 45s\n- grenade-py3 http://logs.openstack.org/43/623543/25/check/grenade-py3/8a7906b/ : SUCCESS in 1h 01m 48s\n- tempest-full-py3 http://logs.openstack.org/43/623543/25/check/tempest-full-py3/092ddb3/ : SUCCESS in 1h 35m 08s\n- openstack-tox-cover http://logs.openstack.org/43/623543/25/check/openstack-tox-cover/2d6d451/cover/ : SUCCESS in 14m 16s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/25/check/openstack-tox-lower-constraints/5adcdd5/ : SUCCESS in 13m 09s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/25/check/openstack-tox-pep8/65aa514/ : SUCCESS in 10m 47s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/25/check/openstack-tox-py27/b4e94d6/ : SUCCESS in 13m 10s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/25/check/openstack-tox-py35/faee7a3/ : SUCCESS in 14m 55s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/25/check/openstack-tox-py36/6b8536d/ : SUCCESS in 12m 23s\n- openstack-tox-docs http://logs.openstack.org/43/623543/25/check/openstack-tox-docs/2d24817/html/ : SUCCESS in 7m 21s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/25/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/cda6249/ : SUCCESS in 47m 48s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/25/check/devstack-plugin-ceph-tempest/37e7850/ : SUCCESS in 2h 01m 10s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/25/check/neutron-grenade-multinode/54d44fb/ : SUCCESS in 1h 07m 39s\n- nova-live-migration http://logs.openstack.org/43/623543/25/check/nova-live-migration/9779cb3/ : SUCCESS in 49m 14s\n- nova-next http://logs.openstack.org/43/623543/25/check/nova-next/1c8bf8a/ : SUCCESS in 1h 46m 36s\n- nova-tox-functional http://logs.openstack.org/43/623543/25/check/nova-tox-functional/10501e6/ : SUCCESS in 21m 39s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/25/check/nova-tox-functional-py35/77a6843/ : SUCCESS in 19m 45s\n- tempest-multinode-full http://logs.openstack.org/43/623543/25/check/tempest-multinode-full/dac5cb6/ : SUCCESS in 1h 45m 38s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/25/check/tempest-slow-py3/24f7633/ : SUCCESS in 1h 57m 15s","accounts_in_message":[],"_revision_number":25},{"id":"3e3b9ebb861033d836130bc18fd96701d20b2647","author":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"date":"2019-02-13 12:24:31.000000000","message":"Patch Set 25:\n\nBuild failed.  For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures\n\n- EMC_VxFlexOS_NOVA http://publiclogs.emc.com/43/623543/25/check/EMC_VxFlexOS_NOVA/408ac1d/EMC_VxFlexOS_NOVA/None : NOT_REGISTERED\n\nLeave a comment with \u0027run-dell-emc-vxflexos\u0027 to trigger a recheck, for more information about CI, please see https://wiki.openstack.org/wiki/ThirdPartySystems/Dell_EMC_VxFlexOS_CI","accounts_in_message":[],"_revision_number":25},{"id":"10e25e68ecc65eb7df78536c18f1f8eec249b3c3","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-02-13 12:50:31.000000000","message":"Patch Set 25:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/25/check/nova-out-of-tree-pvm/da492e4 : SUCCESS in 2h 38m 46s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/25/check/nova-in-tree-pvm/40fd827 : FAILURE in 2h 31m 32s","accounts_in_message":[],"_revision_number":25},{"id":"357174e9bf86816fdd41f44d6e8ab7ec965c3078","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-13 14:07:20.000000000","message":"Patch Set 25:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/25 : SUCCESS in 2h 20m 15s","accounts_in_message":[],"_revision_number":25},{"id":"3474785087d9ac50d13c24552a163da6e55f5651","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-02-13 14:13:17.000000000","message":"Patch Set 25:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-27559 : FAILURE in 1h 36m 10s","accounts_in_message":[],"_revision_number":25},{"id":"01eb20cb2f05a751ee29850f00804ec2ea6fa5e4","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-02-13 19:50:28.000000000","message":"Patch Set 25:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-25 : FAILURE \n\nSee https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI for rechecking and info.","accounts_in_message":[],"_revision_number":25},{"id":"846bee0a127b945ed8f073281fa5bcc2db779887","author":{"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},"date":"2019-02-13 21:31:00.000000000","message":"Patch Set 25:\n\nBuild succeeded.\n\n- Nova-ML2-Sriov http://13.74.249.42/43/623543/25/check-nova/Nova-ML2-Sriov/8e33c8d : SUCCESS in 1h 01m 01s (non-voting)\n- Nova-MACVTAP-ML2-Sriov http://13.74.249.42/43/623543/25/check-nova/Nova-MACVTAP-ML2-Sriov/36f745c : SUCCESS in 1h 13m 27s (non-voting)\n\nTo re-run the job post \u0027recheck nova-mlnx\u0027 comment. For more information visit https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI","accounts_in_message":[],"_revision_number":25},{"id":"7290fa45e36b452debc8d52c8e9c8516138219a3","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-02-15 02:34:39.000000000","message":"Patch Set 25:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/25/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/54d0e10 : SUCCESS in 1h 16m 58s","accounts_in_message":[],"_revision_number":25},{"id":"1967281aab1a3fc84627af5723a20a05eb7d2ca6","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-15 13:24:07.000000000","message":"Uploaded patch set 26: Patch Set 25 was rebased.","accounts_in_message":[],"_revision_number":26},{"id":"3adbf1072089e321ec1f56eca0c3ed6296b84dda","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-15 13:27:10.000000000","message":"Patch Set 26: Verified-1\n\nThis change depends on a change that failed to merge.","accounts_in_message":[],"_revision_number":26},{"id":"f378300c6fb31111d30079c95c1d316f6d2dbe46","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-15 13:36:21.000000000","message":"Patch Set 26:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":26},{"id":"52a2b62fa564237d32de32ceaf67141c5e20dce7","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-15 13:36:54.000000000","message":"Patch Set 26:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":26},{"id":"7403a6c9fae82198fc3645bab1b35af739a97e59","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-15 13:38:03.000000000","message":"Uploaded patch set 27: Patch Set 26 was rebased.","accounts_in_message":[],"_revision_number":27},{"id":"64bd18a6880f8e1addf1357976ea5bcfd7a63602","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-15 13:51:47.000000000","message":"Patch Set 27:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":27},{"id":"d7b67a05eb67325a72e1c379d2ca50ab18be1afe","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-15 15:09:23.000000000","message":"Patch Set 27:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/27/check/tempest-dsvm-full-xenial/5350abe/ : FAILURE in 55m 36s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/27/check/tempest-dsvm-full-xenial-py3/c4c22db/ : FAILURE in 1h 04m 19s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/27/check/grenade-dsvm-xenial/68b87cc/ : FAILURE in 1h 01m 19s (non-voting)","accounts_in_message":[],"_revision_number":27},{"id":"a24f67d2cd5b3c32f3d3ec5d0bf2149ee4143cb2","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-02-15 15:32:03.000000000","message":"Patch Set 27:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/27/check/nova-out-of-tree-pvm/cfbd754 : FAILURE in 37m 08s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/27/check/nova-in-tree-pvm/6bb5201 : FAILURE in 37m 41s","accounts_in_message":[],"_revision_number":27},{"id":"352e613f665fafbb00beb66e5def0f2d4a603108","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-15 16:25:19.000000000","message":"Patch Set 27:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/27/check-vote/ext-nova-zuul/6be1b8a : SUCCESS in 57m 15s","accounts_in_message":[],"_revision_number":27},{"id":"be8457854da0610a5706510ef7fa6d51fb74bdbd","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-02-15 16:26:52.000000000","message":"Patch Set 27:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-27744 : FAILURE in 50m 17s","accounts_in_message":[],"_revision_number":27},{"id":"46a3939a4ff19a0970d568c1560b6bfc41d845ac","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-15 16:46:45.000000000","message":"Patch Set 27: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- tempest-full http://logs.openstack.org/43/623543/27/check/tempest-full/37eb381/ : SUCCESS in 1h 43m 11s\n- neutron-grenade http://logs.openstack.org/43/623543/27/check/neutron-grenade/eba4d7c/ : SUCCESS in 53m 28s\n- grenade-py3 http://logs.openstack.org/43/623543/27/check/grenade-py3/49804d3/ : SUCCESS in 1h 01m 03s\n- tempest-full-py3 http://logs.openstack.org/43/623543/27/check/tempest-full-py3/c14342e/ : SUCCESS in 1h 27m 45s\n- openstack-tox-cover http://logs.openstack.org/43/623543/27/check/openstack-tox-cover/75c78be/cover/ : SUCCESS in 15m 48s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/27/check/openstack-tox-lower-constraints/5e1bc01/ : SUCCESS in 13m 26s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/27/check/openstack-tox-pep8/73f17e4/ : SUCCESS in 9m 52s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/27/check/openstack-tox-py27/a7fea98/ : SUCCESS in 12m 35s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/27/check/openstack-tox-py35/5804ead/ : SUCCESS in 16m 50s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/27/check/openstack-tox-py36/fa76844/ : SUCCESS in 12m 39s\n- openstack-tox-docs http://logs.openstack.org/43/623543/27/check/openstack-tox-docs/bdbaf8e/html/ : SUCCESS in 6m 00s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/27/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/41ef683/ : SUCCESS in 40m 10s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/27/check/devstack-plugin-ceph-tempest/56d4e18/ : SUCCESS in 2h 05m 47s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/27/check/neutron-grenade-multinode/89b170d/ : SUCCESS in 1h 05m 47s\n- nova-live-migration http://logs.openstack.org/43/623543/27/check/nova-live-migration/851ee75/ : SUCCESS in 54m 46s\n- nova-next http://logs.openstack.org/43/623543/27/check/nova-next/db6591d/ : SUCCESS in 2h 18m 22s\n- nova-tox-functional http://logs.openstack.org/43/623543/27/check/nova-tox-functional/881234d/ : SUCCESS in 25m 36s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/27/check/nova-tox-functional-py35/628619c/ : SUCCESS in 24m 23s\n- tempest-multinode-full http://logs.openstack.org/43/623543/27/check/tempest-multinode-full/69c6fcb/ : SUCCESS in 2h 27m 12s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/27/check/tempest-slow-py3/e87f068/ : FAILURE in 2h 19m 52s","accounts_in_message":[],"_revision_number":27},{"id":"8713744e90510c0df6f3c312c6901d7b925d5c70","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-15 20:53:39.000000000","message":"Patch Set 27:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/27 : SUCCESS in 2h 20m 24s","accounts_in_message":[],"_revision_number":27},{"id":"035c84d2ad6b76bd92a5cb17e46b9793cda00eb7","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-02-17 10:49:15.000000000","message":"Patch Set 27:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/27/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/7f2529c : SUCCESS in 1h 17m 06s","accounts_in_message":[],"_revision_number":27},{"id":"f2a03a74d44b0ebb6d5abcb7311bd18e2528a5d3","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-18 13:14:02.000000000","message":"Uploaded patch set 28: Patch Set 27 was rebased.","accounts_in_message":[],"_revision_number":28},{"id":"9467ca31b2f904f5a45dd4c64c26b2ed7574660b","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-18 13:25:28.000000000","message":"Patch Set 28:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":28},{"id":"a0d51bf5010c4b4f91f7a62b2ae085ed025db85d","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-18 13:31:53.000000000","message":"Uploaded patch set 29: Patch Set 28 was rebased.","accounts_in_message":[],"_revision_number":29},{"id":"981f0e176cb37963a1eab44704d7d75fc03ed819","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-18 13:43:37.000000000","message":"Patch Set 29:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":29},{"id":"af1d689f42510addd3e8db7509981ecd92bc086e","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-18 15:21:59.000000000","message":"Patch Set 29:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/29/check/tempest-dsvm-full-xenial/e1957d5/ : FAILURE in 54m 37s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/29/check/tempest-dsvm-full-xenial-py3/562cf05/ : FAILURE in 1h 02m 00s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/29/check/grenade-dsvm-xenial/106deb6/ : FAILURE in 1h 28m 02s (non-voting)","accounts_in_message":[],"_revision_number":29},{"id":"6d3559e220bf72b7382a0fc727182360350d8a50","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-02-18 15:34:40.000000000","message":"Patch Set 29:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/29/check/nova-out-of-tree-pvm/74614b9 : FAILURE in 37m 33s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/29/check/nova-in-tree-pvm/7fcdd67 : FAILURE in 38m 07s","accounts_in_message":[],"_revision_number":29},{"id":"8e7ea16e2fa6d2d423d4ab3578895828c128f35c","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-18 16:19:26.000000000","message":"Patch Set 29:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/29 : SUCCESS in 2h 27m 13s","accounts_in_message":[],"_revision_number":29},{"id":"5fa890825d2d225819c63b5304661bfea0cfdc3b","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-18 16:48:56.000000000","message":"Patch Set 29: Verified+1\n\nBuild succeeded (check pipeline).\n\n- tempest-full http://logs.openstack.org/43/623543/29/check/tempest-full/183dc3b/ : SUCCESS in 1h 49m 21s\n- neutron-grenade http://logs.openstack.org/43/623543/29/check/neutron-grenade/27afec7/ : SUCCESS in 56m 39s\n- grenade-py3 http://logs.openstack.org/43/623543/29/check/grenade-py3/a010f8b/ : SUCCESS in 1h 01m 57s\n- tempest-full-py3 http://logs.openstack.org/43/623543/29/check/tempest-full-py3/a6698be/ : SUCCESS in 1h 24m 45s\n- openstack-tox-cover http://logs.openstack.org/43/623543/29/check/openstack-tox-cover/653f6ef/cover/ : SUCCESS in 22m 16s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/29/check/openstack-tox-lower-constraints/450edca/ : SUCCESS in 12m 39s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/29/check/openstack-tox-pep8/151bfbd/ : SUCCESS in 11m 10s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/29/check/openstack-tox-py27/c8af0f3/ : SUCCESS in 14m 41s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/29/check/openstack-tox-py35/f8d6bc5/ : SUCCESS in 11m 53s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/29/check/openstack-tox-py36/fa75ff1/ : SUCCESS in 17m 08s\n- openstack-tox-docs http://logs.openstack.org/43/623543/29/check/openstack-tox-docs/e0ae43a/html/ : SUCCESS in 8m 11s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/29/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/fc39343/ : SUCCESS in 51m 44s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/29/check/devstack-plugin-ceph-tempest/c74b846/ : SUCCESS in 1h 58m 55s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/29/check/neutron-grenade-multinode/a12a225/ : SUCCESS in 1h 07m 52s\n- nova-live-migration http://logs.openstack.org/43/623543/29/check/nova-live-migration/c568c9a/ : SUCCESS in 44m 04s\n- nova-next http://logs.openstack.org/43/623543/29/check/nova-next/0fe4113/ : SUCCESS in 2h 15m 59s\n- nova-tox-functional http://logs.openstack.org/43/623543/29/check/nova-tox-functional/4e11934/ : SUCCESS in 19m 28s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/29/check/nova-tox-functional-py35/bf168ac/ : SUCCESS in 21m 36s\n- tempest-multinode-full http://logs.openstack.org/43/623543/29/check/tempest-multinode-full/4516743/ : SUCCESS in 2h 01m 31s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/29/check/tempest-slow-py3/adf4ace/ : SUCCESS in 2h 15m 59s","accounts_in_message":[],"_revision_number":29},{"id":"6dcb619671c1c1909cee9a9060ef125163c1cbeb","author":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"date":"2019-02-18 16:50:17.000000000","message":"Patch Set 29:\n\nBuild failed.  For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures\n\n- EMC_VxFlexOS_NOVA http://publiclogs.emc.com/43/623543/29/check/EMC_VxFlexOS_NOVA/b123ff1/EMC_VxFlexOS_NOVA/None : NOT_REGISTERED\n\nLeave a comment with \u0027run-dell-emc-vxflexos\u0027 to trigger a recheck, for more information about CI, please see https://wiki.openstack.org/wiki/ThirdPartySystems/Dell_EMC_VxFlexOS_CI","accounts_in_message":[],"_revision_number":29},{"id":"423dd97efc125d5bebbb291633b4b0af9dc26d96","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-02-18 17:42:12.000000000","message":"Patch Set 29:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-27813 : FAILURE in 1h 39m 58s","accounts_in_message":[],"_revision_number":29},{"id":"9ea826e1a722c09dba77465b5ebc94f0317c7fe3","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-02-18 18:19:31.000000000","message":"Patch Set 29:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-29 : FAILURE \n\nSee https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI for rechecking and info.","accounts_in_message":[],"_revision_number":29},{"id":"c65e30c9ea1ea85f506596cb71a4c41cac65fcb9","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-02-18 21:24:42.000000000","message":"Patch Set 29:\n\nTesting failed ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenial-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/29/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/56a04bf : FAILURE in 1h 24m 00s","accounts_in_message":[],"_revision_number":29},{"id":"9268802b82393a65bc759712111f497defeabf7d","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-20 08:16:43.000000000","message":"Uploaded patch set 30: Patch Set 29 was rebased.","accounts_in_message":[],"_revision_number":30},{"id":"160d3900a83d31e527c363cf1065d63542d9d990","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-20 08:28:54.000000000","message":"Patch Set 30:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":30},{"id":"19ddbdbb2b07a8d8443dc0bd1693cb63d34fc9a3","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-20 09:52:27.000000000","message":"Patch Set 30:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/30/check/tempest-dsvm-full-xenial/853c23a/ : UNSTABLE in 1h 07m 35s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/30/check/tempest-dsvm-full-xenial-py3/b2952ea/ : UNSTABLE in 1h 16m 23s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/30/check/grenade-dsvm-xenial/44b2876/ : UNSTABLE in 1h 03m 30s (non-voting)","accounts_in_message":[],"_revision_number":30},{"id":"9f035ac838d5e01ba3692d3dd6b975cfc57ba8c0","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-20 10:52:50.000000000","message":"Patch Set 30: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- grenade-py3 http://logs.openstack.org/43/623543/30/check/grenade-py3/1d8878c/ : SUCCESS in 1h 04m 10s\n- tempest-full-py3 http://logs.openstack.org/43/623543/30/check/tempest-full-py3/d3e0b1e/ : SUCCESS in 1h 26m 08s\n- openstack-tox-cover http://logs.openstack.org/43/623543/30/check/openstack-tox-cover/b6fc165/cover/ : SUCCESS in 17m 11s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/30/check/openstack-tox-lower-constraints/b3d9289/ : SUCCESS in 11m 41s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/30/check/openstack-tox-pep8/5f259ab/ : SUCCESS in 9m 23s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/30/check/openstack-tox-py27/38a7e4d/ : FAILURE in 26m 19s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/30/check/openstack-tox-py35/3a60451/ : SUCCESS in 12m 57s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/30/check/openstack-tox-py36/dd85eed/ : SUCCESS in 13m 06s\n- openstack-tox-docs http://logs.openstack.org/43/623543/30/check/openstack-tox-docs/2901974/html/ : SUCCESS in 6m 45s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/30/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/73fcebc/ : SUCCESS in 47m 35s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/30/check/devstack-plugin-ceph-tempest/b2acbad/ : SUCCESS in 1h 50m 10s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/30/check/neutron-grenade-multinode/9f0d643/ : SUCCESS in 1h 08m 01s\n- nova-live-migration http://logs.openstack.org/43/623543/30/check/nova-live-migration/f33b8e4/ : SUCCESS in 48m 41s\n- nova-next http://logs.openstack.org/43/623543/30/check/nova-next/100a746/ : SUCCESS in 2h 18m 52s\n- nova-tox-functional http://logs.openstack.org/43/623543/30/check/nova-tox-functional/f33ada7/ : FAILURE in 17m 49s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/30/check/nova-tox-functional-py35/79352a1/ : SUCCESS in 19m 39s\n- tempest-multinode-full http://logs.openstack.org/43/623543/30/check/tempest-multinode-full/7d447a0/ : SUCCESS in 1h 49m 48s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/30/check/tempest-slow-py3/33a75bb/ : SUCCESS in 2h 12m 01s","accounts_in_message":[],"_revision_number":30},{"id":"814b8cfa86418d4429b4eaabaf2612b04d82a894","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-02-20 12:16:43.000000000","message":"Patch Set 30:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/30/check/nova-out-of-tree-pvm/4d74fda : FAILURE in 39m 04s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/30/check/nova-in-tree-pvm/23e2fb6 : FAILURE in 36m 04s","accounts_in_message":[],"_revision_number":30},{"id":"b540ef3749f976f677681d8088f46234b3d1c9b4","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-20 14:47:49.000000000","message":"Patch Set 30:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/30 : SUCCESS in 2h 22m 30s","accounts_in_message":[],"_revision_number":30},{"id":"074cc84771ec1f2296b3934c8818a89f5889be29","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-20 21:18:36.000000000","message":"Patch Set 30:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/30/check-vote/ext-nova-zuul/be95e78 : SUCCESS in 58m 31s","accounts_in_message":[],"_revision_number":30},{"id":"ed67ba8b2b1899d1b28a1ea950ca0bac1cbf0a21","author":{"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},"date":"2019-02-21 01:28:20.000000000","message":"Patch Set 30:\n\nBuild succeeded.\n\n- Nova-ML2-Sriov http://13.74.249.42/43/623543/30/check-nova/Nova-ML2-Sriov/841ea79 : SUCCESS in 1h 23m 21s (non-voting)\n- Nova-MACVTAP-ML2-Sriov http://13.74.249.42/43/623543/30/check-nova/Nova-MACVTAP-ML2-Sriov/61e6d6f : SUCCESS in 56m 47s (non-voting)\n\nTo re-run the job post \u0027recheck nova-mlnx\u0027 comment. For more information visit https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI","accounts_in_message":[],"_revision_number":30},{"id":"5fc78e2d6975d3d6af97009162fbdc65b9017887","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-02-21 10:18:52.000000000","message":"Patch Set 30:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-27955 : FAILURE in 1h 38m 02s","accounts_in_message":[],"_revision_number":30},{"id":"73d0286a5c1de693d09eea1a3265f94cc4a6198c","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-21 11:45:01.000000000","message":"Uploaded patch set 31: Patch Set 30 was rebased.","accounts_in_message":[],"_revision_number":31},{"id":"d09b813577d064f8668b357993c0c9cbb98737d5","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-21 11:56:24.000000000","message":"Patch Set 31:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":31},{"id":"5ec0a100c47cb4a2cc893d0494c5371365f9a37c","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-02-21 13:20:43.000000000","message":"Patch Set 31:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/31/check/tempest-dsvm-full-xenial/e34b6f7/ : UNSTABLE in 1h 10m 08s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/31/check/tempest-dsvm-full-xenial-py3/8370f64/ : UNSTABLE in 1h 16m 21s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/31/check/grenade-dsvm-xenial/41b9516/ : UNSTABLE in 1h 02m 24s (non-voting)","accounts_in_message":[],"_revision_number":31},{"id":"10531cd0a73afb7028725da9ad626dcd634ae3e5","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-21 14:54:12.000000000","message":"Patch Set 31: Verified+1\n\nBuild succeeded (check pipeline).\n\n- grenade-py3 http://logs.openstack.org/43/623543/31/check/grenade-py3/6cfb0fa/ : SUCCESS in 1h 01m 58s\n- tempest-full-py3 http://logs.openstack.org/43/623543/31/check/tempest-full-py3/9a2e487/ : SUCCESS in 1h 42m 16s\n- openstack-tox-cover http://logs.openstack.org/43/623543/31/check/openstack-tox-cover/df3d75e/cover/ : SUCCESS in 18m 46s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/31/check/openstack-tox-lower-constraints/b017bc1/ : SUCCESS in 19m 26s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/31/check/openstack-tox-pep8/f306212/ : SUCCESS in 11m 38s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/31/check/openstack-tox-py27/77de98a/ : SUCCESS in 12m 40s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/31/check/openstack-tox-py35/60d1b96/ : SUCCESS in 19m 35s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/31/check/openstack-tox-py36/b580ee9/ : SUCCESS in 12m 59s\n- openstack-tox-docs http://logs.openstack.org/43/623543/31/check/openstack-tox-docs/13b0814/html/ : SUCCESS in 7m 56s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/31/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/64b0bcc/ : SUCCESS in 1h 01m 43s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/31/check/devstack-plugin-ceph-tempest/bdfef2d/ : SUCCESS in 1h 58m 37s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/31/check/neutron-grenade-multinode/8314f54/ : SUCCESS in 1h 13m 31s\n- nova-live-migration http://logs.openstack.org/43/623543/31/check/nova-live-migration/ad57652/ : SUCCESS in 59m 17s\n- nova-next http://logs.openstack.org/43/623543/31/check/nova-next/c8cff0c/ : SUCCESS in 1h 57m 20s\n- nova-tox-functional http://logs.openstack.org/43/623543/31/check/nova-tox-functional/7339880/ : SUCCESS in 20m 55s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/31/check/nova-tox-functional-py35/1179b2f/ : SUCCESS in 21m 15s\n- tempest-multinode-full http://logs.openstack.org/43/623543/31/check/tempest-multinode-full/f602bd0/ : SUCCESS in 1h 37m 17s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/31/check/tempest-slow-py3/742a2b2/ : SUCCESS in 1h 56m 47s","accounts_in_message":[],"_revision_number":31},{"id":"866f2601394ee59564f14aa6ff1a417e013b7bc1","author":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"date":"2019-02-21 14:55:42.000000000","message":"Patch Set 31:\n\nBuild failed.  For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures\n\n- EMC_VxFlexOS_NOVA http://publiclogs.emc.com/43/623543/31/check/EMC_VxFlexOS_NOVA/41cd232/EMC_VxFlexOS_NOVA/None : NOT_REGISTERED\n\nLeave a comment with \u0027run-dell-emc-vxflexos\u0027 to trigger a recheck, for more information about CI, please see https://wiki.openstack.org/wiki/ThirdPartySystems/Dell_EMC_VxFlexOS_CI","accounts_in_message":[],"_revision_number":31},{"id":"ee9e5719be7e4a3c4711baf899a2659f74ec328f","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-02-21 16:31:14.000000000","message":"Patch Set 31:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-31 : FAILURE \n\nSee https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI for rechecking and info.","accounts_in_message":[],"_revision_number":31},{"id":"5d8d3069acd7c0536f580a7fa28d67ae19626832","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-02-21 16:40:58.000000000","message":"Patch Set 31:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/31 : SUCCESS in 2h 46m 52s","accounts_in_message":[],"_revision_number":31},{"id":"c74db6040a8cdcef876b03cc3956f3f670281f91","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-02-21 18:48:45.000000000","message":"Patch Set 31:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-28016 : FAILURE in 47m 44s","accounts_in_message":[],"_revision_number":31},{"id":"c06316cc38fdb198bf65b3920a3f0ee30aead188","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-21 19:52:19.000000000","message":"Patch Set 31:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/31/check-vote/ext-nova-zuul/2358fbd : SUCCESS in 1h 01m 31s","accounts_in_message":[],"_revision_number":31},{"id":"69081bfeed610f256068fb7607e7560cb04e362e","author":{"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},"date":"2019-02-21 23:12:30.000000000","message":"Patch Set 31:\n\nBuild succeeded.\n\n- Nova-ML2-Sriov http://13.74.249.42/43/623543/31/check-nova/Nova-ML2-Sriov/946ebde : SUCCESS in 1h 11m 02s (non-voting)\n- Nova-MACVTAP-ML2-Sriov http://13.74.249.42/43/623543/31/check-nova/Nova-MACVTAP-ML2-Sriov/9847b42 : SUCCESS in 1h 13m 25s (non-voting)\n\nTo re-run the job post \u0027recheck nova-mlnx\u0027 comment. For more information visit https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI","accounts_in_message":[],"_revision_number":31},{"id":"e97b013d02ccc17473a3cf5b019d5516b27bb008","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-02-22 16:21:40.000000000","message":"Patch Set 31:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/31/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/887e1e3 : SUCCESS in 1h 15m 17s","accounts_in_message":[],"_revision_number":31},{"id":"04987653974bd04dcb2a1a1e7ec96c5e358afb6c","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-02-27 13:10:06.000000000","message":"Patch Set 31:\n\nThis change depends on a change that failed to merge.","accounts_in_message":[],"_revision_number":31},{"id":"fb30501dabd022172931485c83eb76e406d15de5","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-27 13:14:30.000000000","message":"Uploaded patch set 32: Patch Set 31 was rebased.","accounts_in_message":[],"_revision_number":32},{"id":"433bdc322bd4674415ef848283fae1281228284e","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-27 13:16:34.000000000","message":"Patch Set 32:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":32},{"id":"490e174d0e2545e45cab48a7a94d409f98595806","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-27 13:25:41.000000000","message":"Uploaded patch set 33: Patch Set 32 was rebased.","accounts_in_message":[],"_revision_number":33},{"id":"773e9edbe4f6e26e2d8c9f3397bcd4887a0ee680","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-27 13:29:00.000000000","message":"Patch Set 33:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":33},{"id":"7b8dd335e1780d0ae337f72535ff58f73eefb11e","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-02-27 15:04:53.000000000","message":"Patch Set 33:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-28347 : FAILURE in 1h 22m 30s","accounts_in_message":[],"_revision_number":33},{"id":"029093ecee388c223bc627951546ed2384cefe40","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-27 16:42:13.000000000","message":"Patch Set 33: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- grenade-py3 http://logs.openstack.org/43/623543/33/check/grenade-py3/f7372b2/ : SUCCESS in 1h 06m 10s\n- tempest-full-py3 http://logs.openstack.org/43/623543/33/check/tempest-full-py3/bd73ce5/ : SUCCESS in 1h 24m 08s\n- openstack-tox-cover http://logs.openstack.org/43/623543/33/check/openstack-tox-cover/5fcd3af/cover/ : SUCCESS in 17m 44s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/33/check/openstack-tox-lower-constraints/3c5ea3e/ : SUCCESS in 13m 51s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/33/check/openstack-tox-pep8/af2cf86/ : SUCCESS in 11m 26s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/33/check/openstack-tox-py27/83154d8/ : SUCCESS in 13m 49s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/33/check/openstack-tox-py35/620786f/ : SUCCESS in 13m 17s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/33/check/openstack-tox-py36/519c8e7/ : SUCCESS in 13m 04s\n- openstack-tox-docs http://logs.openstack.org/43/623543/33/check/openstack-tox-docs/b08dfef/html/ : SUCCESS in 7m 16s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/33/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/3eca8e6/ : SUCCESS in 51m 12s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/33/check/devstack-plugin-ceph-tempest/00772bc/ : TIMED_OUT in 2h 05m 39s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/33/check/legacy-grenade-dsvm-neutron-multinode-live-migration/50df3a6/ : SUCCESS in 1h 15m 19s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/33/check/neutron-grenade-multinode/5a1166f/ : SUCCESS in 1h 15m 29s\n- nova-live-migration http://logs.openstack.org/43/623543/33/check/nova-live-migration/44ef4aa/ : SUCCESS in 44m 03s\n- nova-next http://logs.openstack.org/43/623543/33/check/nova-next/270c65d/ : FAILURE in 2h 58m 21s\n- nova-tox-functional http://logs.openstack.org/43/623543/33/check/nova-tox-functional/e7a4f6a/ : SUCCESS in 21m 57s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/33/check/nova-tox-functional-py35/62015fc/ : SUCCESS in 19m 39s\n- tempest-multinode-full http://logs.openstack.org/43/623543/33/check/tempest-multinode-full/84870ab/ : SUCCESS in 1h 53m 11s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/33/check/tempest-slow-py3/c359aeb/ : SUCCESS in 2h 11m 54s","accounts_in_message":[],"_revision_number":33},{"id":"c6456827bdf61b1117de5d0ff34d07025cfb9d28","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-02-27 17:08:37.000000000","message":"Uploaded patch set 34: Patch Set 33 was rebased.","accounts_in_message":[],"_revision_number":34},{"id":"2f8561fca1193ecbab07bfe52b0177445f273f2f","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-02-27 17:12:18.000000000","message":"Patch Set 34:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":34},{"id":"938501cd49af478457f81d3bd50be17263bb95f6","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-02-27 17:42:14.000000000","message":"Patch Set 34:\n\nMerge Failed.\n\nThis change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.","accounts_in_message":[],"_revision_number":34},{"id":"566b70821aa09fdd4063a2e88eeafabca3bc57fd","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-02-27 22:43:37.000000000","message":"Patch Set 34: Verified+1\n\nBuild succeeded (check pipeline).\n\n- grenade-py3 http://logs.openstack.org/43/623543/34/check/grenade-py3/224b538/ : SUCCESS in 1h 06m 34s\n- tempest-full-py3 http://logs.openstack.org/43/623543/34/check/tempest-full-py3/3419e96/ : SUCCESS in 1h 24m 31s\n- openstack-tox-cover http://logs.openstack.org/43/623543/34/check/openstack-tox-cover/7d37a1b/cover/ : SUCCESS in 16m 00s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/34/check/openstack-tox-lower-constraints/dbd768d/ : SUCCESS in 13m 52s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/34/check/openstack-tox-pep8/c79747b/ : SUCCESS in 12m 43s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/34/check/openstack-tox-py27/a515bfd/ : SUCCESS in 13m 21s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/34/check/openstack-tox-py35/3e3ef4b/ : SUCCESS in 13m 17s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/34/check/openstack-tox-py36/592b1b8/ : SUCCESS in 13m 00s\n- openstack-tox-docs http://logs.openstack.org/43/623543/34/check/openstack-tox-docs/7b943d7/html/ : SUCCESS in 6m 53s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/34/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/217e0e7/ : SUCCESS in 45m 47s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/34/check/devstack-plugin-ceph-tempest/33471b7/ : SUCCESS in 1h 30m 19s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/34/check/legacy-grenade-dsvm-neutron-multinode-live-migration/085d149/ : SUCCESS in 59m 50s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/34/check/neutron-grenade-multinode/22f1c6e/ : SUCCESS in 1h 03m 57s\n- nova-live-migration http://logs.openstack.org/43/623543/34/check/nova-live-migration/823690a/ : SUCCESS in 43m 39s\n- nova-next http://logs.openstack.org/43/623543/34/check/nova-next/5447637/ : SUCCESS in 1h 54m 16s\n- nova-tox-functional http://logs.openstack.org/43/623543/34/check/nova-tox-functional/416846b/ : SUCCESS in 19m 50s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/34/check/nova-tox-functional-py35/229cd49/ : SUCCESS in 17m 30s\n- tempest-multinode-full http://logs.openstack.org/43/623543/34/check/tempest-multinode-full/2b848a0/ : SUCCESS in 1h 45m 36s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/34/check/tempest-slow-py3/5db5972/ : SUCCESS in 2h 40m 04s","accounts_in_message":[],"_revision_number":34},{"id":"8d970f273d0ebfa537829cb9ebd841605d652a69","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-02-28 05:38:22.000000000","message":"Patch Set 34:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-34 : FAILURE \n\nSee https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI for rechecking and info.","accounts_in_message":[],"_revision_number":34},{"id":"56b534d58a36fd4e8d18a5219b3bb75a3c98012b","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-03-01 11:19:57.000000000","message":"Patch Set 34:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/34/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/0608988 : SUCCESS in 1h 17m 32s","accounts_in_message":[],"_revision_number":34},{"id":"8993d1879a94a8a096d2fb02831265fecb78a4c3","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-01 13:03:53.000000000","message":"Uploaded patch set 35.","accounts_in_message":[],"_revision_number":35},{"id":"2f104505e40d44c76bdcb6a8727e888162246ca4","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-01 13:04:39.000000000","message":"Patch Set 36: Patch Set 35 was rebased","accounts_in_message":[],"_revision_number":36},{"id":"3f061544edacf516d77ce9d727a6e80980ddef40","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-03-01 13:04:51.000000000","message":"Patch Set 35:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":35},{"id":"ebf9e0f4f92b1812f0b0500f5cd0eff5edba163d","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-03-01 13:05:37.000000000","message":"Patch Set 36:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":36},{"id":"a2a8c4ec89611fcd23d8427c0156f50250e9095e","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-03-01 14:15:02.000000000","message":"Patch Set 36:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-28526 : SUCCESS in 1h 08m 25s","accounts_in_message":[],"_revision_number":36},{"id":"bc4ff1c327914c93f4ece89e52308c69030cfc23","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-03-01 15:24:22.000000000","message":"Patch Set 36:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/36 : SUCCESS in 2h 18m 33s","accounts_in_message":[],"_revision_number":36},{"id":"f2d4b4308188d4637d77bc3fb703e952a7ba0fab","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-03-01 15:25:44.000000000","message":"Patch Set 36: Verified+1\n\nBuild succeeded (check pipeline).\n\n- grenade-py3 http://logs.openstack.org/43/623543/36/check/grenade-py3/beb510d/ : SUCCESS in 1h 10m 29s\n- tempest-full-py3 http://logs.openstack.org/43/623543/36/check/tempest-full-py3/6004786/ : SUCCESS in 1h 39m 08s\n- openstack-tox-cover http://logs.openstack.org/43/623543/36/check/openstack-tox-cover/54742d6/cover/ : SUCCESS in 16m 22s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/36/check/openstack-tox-lower-constraints/75cccfb/ : SUCCESS in 13m 21s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/36/check/openstack-tox-pep8/f411008/ : SUCCESS in 10m 32s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/36/check/openstack-tox-py27/bb35b02/ : SUCCESS in 15m 11s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/36/check/openstack-tox-py35/8ec8c99/ : SUCCESS in 14m 42s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/36/check/openstack-tox-py36/6971d14/ : SUCCESS in 13m 40s\n- openstack-tox-docs http://logs.openstack.org/43/623543/36/check/openstack-tox-docs/4789e82/html/ : SUCCESS in 6m 28s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/36/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/70b3b9e/ : SUCCESS in 46m 55s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/36/check/devstack-plugin-ceph-tempest/3d60d29/ : SUCCESS in 1h 27m 03s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/36/check/legacy-grenade-dsvm-neutron-multinode-live-migration/a1f8705/ : SUCCESS in 1h 06m 08s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/36/check/neutron-grenade-multinode/caf8d20/ : SUCCESS in 1h 15m 34s\n- nova-live-migration http://logs.openstack.org/43/623543/36/check/nova-live-migration/c39772b/ : SUCCESS in 48m 38s\n- nova-next http://logs.openstack.org/43/623543/36/check/nova-next/8dfcefa/ : SUCCESS in 1h 50m 25s\n- nova-tox-functional http://logs.openstack.org/43/623543/36/check/nova-tox-functional/f83b7c4/ : SUCCESS in 20m 13s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/36/check/nova-tox-functional-py35/d7ed78f/ : SUCCESS in 17m 50s\n- tempest-multinode-full http://logs.openstack.org/43/623543/36/check/tempest-multinode-full/0d308c2/ : SUCCESS in 1h 47m 34s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/36/check/tempest-slow-py3/1b70c58/ : SUCCESS in 2h 12m 59s","accounts_in_message":[],"_revision_number":36},{"id":"fefc6cde0d30cbcdd103268808fe5e2451d1b665","author":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"date":"2019-03-01 15:26:27.000000000","message":"Patch Set 36:\n\nBuild failed.  For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures\n\n- EMC_VxFlexOS_NOVA http://publiclogs.emc.com/43/623543/36/check/EMC_VxFlexOS_NOVA/a59b9ba/EMC_VxFlexOS_NOVA/None : NOT_REGISTERED\n\nLeave a comment with \u0027run-dell-emc-vxflexos\u0027 to trigger a recheck, for more information about CI, please see https://wiki.openstack.org/wiki/ThirdPartySystems/Dell_EMC_VxFlexOS_CI","accounts_in_message":[],"_revision_number":36},{"id":"b6caf0cf755960bf0de1122b89dbebf4862b8bdc","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-01 15:51:34.000000000","message":"Uploaded patch set 37: Patch Set 36 was rebased.","accounts_in_message":[],"_revision_number":37},{"id":"71e4f0b3d2067745751f423413f8fe9d250610a2","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-03-01 16:31:36.000000000","message":"Patch Set 37:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/37 : FAILURE in 38m 15s","accounts_in_message":[],"_revision_number":37},{"id":"15e96f8e27548deabc021e9c46107bfccc940193","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-03-01 16:39:21.000000000","message":"Patch Set 37:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":37},{"id":"9d5e3a9d97074852ee85ea94ee815ef8b14ed474","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-03-01 18:53:55.000000000","message":"Patch Set 37:\n\nTesting completed on the zVM Driver CI system check-nova pipeline and failed.  To recheck only the zVM driver plugins, submit a comment with only  zvm: recheck in the comment.. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-28532 : FAILURE in 2h 59m 25s","accounts_in_message":[],"_revision_number":37},{"id":"100814f371aa482cf2cfc7cffe823c8ea0e1aaf9","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-03-01 19:07:09.000000000","message":"Patch Set 37: Verified+1\n\nBuild succeeded (check pipeline).\n\n- grenade-py3 http://logs.openstack.org/43/623543/37/check/grenade-py3/2d91384/ : SUCCESS in 1h 10m 17s\n- tempest-full-py3 http://logs.openstack.org/43/623543/37/check/tempest-full-py3/a437a05/ : SUCCESS in 1h 35m 20s\n- openstack-tox-cover http://logs.openstack.org/43/623543/37/check/openstack-tox-cover/06b2ef6/cover/ : SUCCESS in 17m 59s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/37/check/openstack-tox-lower-constraints/eabbf91/ : SUCCESS in 15m 51s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/37/check/openstack-tox-pep8/44b17d8/ : SUCCESS in 9m 20s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/37/check/openstack-tox-py27/af7328c/ : SUCCESS in 13m 20s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/37/check/openstack-tox-py35/44bf648/ : SUCCESS in 12m 53s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/37/check/openstack-tox-py36/6e9e6c7/ : SUCCESS in 12m 48s\n- openstack-tox-docs http://logs.openstack.org/43/623543/37/check/openstack-tox-docs/14af7ec/html/ : SUCCESS in 6m 41s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/37/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/1f0543b/ : SUCCESS in 53m 49s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/37/check/devstack-plugin-ceph-tempest/500e074/ : SUCCESS in 1h 32m 15s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/37/check/legacy-grenade-dsvm-neutron-multinode-live-migration/50f5fac/ : SUCCESS in 1h 06m 33s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/37/check/neutron-grenade-multinode/b0529bc/ : SUCCESS in 1h 07m 15s\n- nova-live-migration http://logs.openstack.org/43/623543/37/check/nova-live-migration/f7b0d07/ : SUCCESS in 51m 33s\n- nova-next http://logs.openstack.org/43/623543/37/check/nova-next/bb6d796/ : SUCCESS in 2h 29m 58s\n- nova-tox-functional http://logs.openstack.org/43/623543/37/check/nova-tox-functional/91e283f/ : SUCCESS in 23m 55s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/37/check/nova-tox-functional-py35/401ea1d/ : SUCCESS in 21m 20s\n- tempest-multinode-full http://logs.openstack.org/43/623543/37/check/tempest-multinode-full/a33e272/ : SUCCESS in 1h 46m 35s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/37/check/tempest-slow-py3/0f3378b/ : SUCCESS in 2h 05m 12s","accounts_in_message":[],"_revision_number":37},{"id":"70d8a652d3167770ffa5d8dc130b7912689ff832","author":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"date":"2019-03-01 19:07:49.000000000","message":"Patch Set 37:\n\nBuild failed.  For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures\n\n- EMC_VxFlexOS_NOVA http://publiclogs.emc.com/43/623543/37/check/EMC_VxFlexOS_NOVA/29b6930/EMC_VxFlexOS_NOVA/None : NOT_REGISTERED\n\nLeave a comment with \u0027run-dell-emc-vxflexos\u0027 to trigger a recheck, for more information about CI, please see https://wiki.openstack.org/wiki/ThirdPartySystems/Dell_EMC_VxFlexOS_CI","accounts_in_message":[],"_revision_number":37},{"id":"9d66f44be8c8d7ed4ce099bfc807ac6eede12500","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-03-01 23:41:49.000000000","message":"Patch Set 36:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-36 : FAILURE \n\nSee https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI for rechecking and info.","accounts_in_message":[],"_revision_number":36},{"id":"42006387e8a164945da83b6ab6537fea0cb72004","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-03-02 02:57:24.000000000","message":"Patch Set 37:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-37 : FAILURE \n\nSee https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI for rechecking and info.","accounts_in_message":[],"_revision_number":37},{"id":"5673e23c58091d31e1d3d05a9a6f7f57a20af49e","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-03-03 10:06:54.000000000","message":"Patch Set 37:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/37/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/5136d2e : SUCCESS in 1h 16m 01s","accounts_in_message":[],"_revision_number":37},{"id":"7bd366076ebeda36d090b393801cef961c622143","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-04 09:10:07.000000000","message":"Uploaded patch set 38: Patch Set 37 was rebased.","accounts_in_message":[],"_revision_number":38},{"id":"b42b149e032e93262455813ea5287eace2ad3180","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-03-04 09:11:01.000000000","message":"Patch Set 38:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":38},{"id":"5f01633f8db382c758d9f1909bed9f0de2d4242a","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-03-04 10:31:47.000000000","message":"Patch Set 38:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/38/check/nova-out-of-tree-pvm/7d37673 : FAILURE in 45m 43s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/38/check/nova-in-tree-pvm/1278714 : FAILURE in 44m 19s","accounts_in_message":[],"_revision_number":38},{"id":"020777ead83107aaedbfc021b8d9df2d29308612","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-03-04 10:40:30.000000000","message":"Patch Set 38:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-28594 : SUCCESS in 1h 23m 26s","accounts_in_message":[],"_revision_number":38},{"id":"7cbb3d2421c0d4be32f22f072297c99e2d36860e","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-03-04 11:27:55.000000000","message":"Patch Set 38: Verified+1\n\nBuild succeeded (check pipeline).\n\n- grenade-py3 http://logs.openstack.org/43/623543/38/check/grenade-py3/7a71aa6/ : SUCCESS in 1h 01m 43s\n- tempest-full-py3 http://logs.openstack.org/43/623543/38/check/tempest-full-py3/24c5fbc/ : SUCCESS in 1h 34m 00s\n- openstack-tox-cover http://logs.openstack.org/43/623543/38/check/openstack-tox-cover/394d8ca/cover/ : SUCCESS in 15m 48s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/38/check/openstack-tox-lower-constraints/3cb05e8/ : SUCCESS in 12m 23s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/38/check/openstack-tox-pep8/a706cb7/ : SUCCESS in 10m 21s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/38/check/openstack-tox-py27/5091734/ : SUCCESS in 12m 35s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/38/check/openstack-tox-py35/c6e97d8/ : SUCCESS in 14m 00s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/38/check/openstack-tox-py36/afa4567/ : SUCCESS in 11m 04s\n- openstack-tox-docs http://logs.openstack.org/43/623543/38/check/openstack-tox-docs/21d37c3/html/ : SUCCESS in 6m 20s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/38/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/4333db8/ : SUCCESS in 47m 54s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/38/check/devstack-plugin-ceph-tempest/548e2c4/ : SUCCESS in 1h 25m 34s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/38/check/legacy-grenade-dsvm-neutron-multinode-live-migration/17702d0/ : SUCCESS in 1h 05m 46s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/38/check/neutron-grenade-multinode/1452a25/ : SUCCESS in 1h 11m 47s\n- nova-live-migration http://logs.openstack.org/43/623543/38/check/nova-live-migration/e7c21c8/ : SUCCESS in 47m 57s\n- nova-next http://logs.openstack.org/43/623543/38/check/nova-next/11a4c5d/ : SUCCESS in 1h 58m 53s\n- nova-tox-functional http://logs.openstack.org/43/623543/38/check/nova-tox-functional/eea52b6/ : SUCCESS in 18m 53s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/38/check/nova-tox-functional-py35/f4a5ff6/ : SUCCESS in 19m 02s\n- tempest-multinode-full http://logs.openstack.org/43/623543/38/check/tempest-multinode-full/41e3544/ : SUCCESS in 1h 37m 53s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/38/check/tempest-slow-py3/1292019/ : SUCCESS in 2h 10m 35s","accounts_in_message":[],"_revision_number":38},{"id":"419c9b21171d147da9c9cc23e85d977d78477316","author":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"date":"2019-03-04 11:28:35.000000000","message":"Patch Set 38:\n\nBuild failed.  For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures\n\n- EMC_VxFlexOS_NOVA http://publiclogs.emc.com/43/623543/38/check/EMC_VxFlexOS_NOVA/9146581/EMC_VxFlexOS_NOVA/None : NOT_REGISTERED\n\nLeave a comment with \u0027run-dell-emc-vxflexos\u0027 to trigger a recheck, for more information about CI, please see https://wiki.openstack.org/wiki/ThirdPartySystems/Dell_EMC_VxFlexOS_CI","accounts_in_message":[],"_revision_number":38},{"id":"d76d0403826bdc454f65803c2118d74d3413bd1d","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-03-04 11:33:06.000000000","message":"Patch Set 38:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/38 : SUCCESS in 2h 17m 49s","accounts_in_message":[],"_revision_number":38},{"id":"513072bcc2054b9f22a6a2e8dd4af6ee26be27c8","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-03-04 12:51:04.000000000","message":"Patch Set 38:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-38 : SUCCESS \n\nhttps://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI","accounts_in_message":[],"_revision_number":38},{"id":"ee551def8f49abaf1571da7790cf2927049407f6","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-03-04 12:51:26.000000000","message":"Patch Set 38:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/38/check-vote/ext-nova-zuul/1e6ae8c : SUCCESS in 55m 03s","accounts_in_message":[],"_revision_number":38},{"id":"26f6868eabb43edd076d1c6c5fc73dd0b884e140","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-04 15:13:36.000000000","message":"Uploaded patch set 39.","accounts_in_message":[],"_revision_number":39},{"id":"195d66c9637026cfa1c44063da3cb399c4c4456e","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-03-04 15:14:02.000000000","message":"Patch Set 39:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":39},{"id":"1c2ebf8edd711f35d799640ed52aefc62fcc4117","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-03-04 15:44:09.000000000","message":"Patch Set 39:\n\nBuild failed. Test completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. For contact and more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- tempest-dsvm-full-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/39/check/tempest-dsvm-full-xenial/db9af62/ : FAILURE in 15m 05s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/39/check/tempest-dsvm-full-xenial-py3/5af90c9/ : FAILURE in 13m 59s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/43/623543/39/check/grenade-dsvm-xenial/cdfc0a9/ : FAILURE in 12m 48s (non-voting)","accounts_in_message":[],"_revision_number":39},{"id":"c6034fdd36c7f0ae0c8355ce72300f302b6db17c","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-03-04 15:58:00.000000000","message":"Patch Set 39:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/39/check/nova-out-of-tree-pvm/4abc1a3 : FAILURE in 43m 37s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/39/check/nova-in-tree-pvm/f80b78a : FAILURE in 42m 41s","accounts_in_message":[],"_revision_number":39},{"id":"deec3176983ec312ac606938de97978a647a3b6b","author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"date":"2019-03-04 16:14:41.000000000","message":"Patch Set 39: Code-Review+2\n\n(19 comments)\n\nCouple of nits and I\u0027d personally like to see  \u0027pf_interface_name\u0027 -\u003e \u0027parent_ifname\u0027, but both a nice-to-haves. Other than that, I\u0027m happy with this now from the PCI side of things","accounts_in_message":[],"_revision_number":39},{"id":"e1d3f458f1eb1a6c42a883804e04f33977246562","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2019-03-04 16:22:26.000000000","message":"Patch Set 39: Workflow-1\n\n(1 comment)\n\nDropping quickly a -1 because I think we have an upgrade issue. I\u0027ll review the other things later.","accounts_in_message":[],"_revision_number":39},{"id":"5df09ddb5074df6d12fd9af37c3af5887d0566cc","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2019-03-04 16:22:38.000000000","message":"Patch Set 39: Code-Review-1 -Workflow\n\nShit, wrong button","accounts_in_message":[],"_revision_number":39},{"id":"3ae5244bf45f6442441bfd937ddfc9808e915540","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2019-03-04 16:44:11.000000000","message":"Patch Set 39: Code-Review+1\n\n(1 comment)\n\nChanging my vote to a soft -1 begging for documentation","accounts_in_message":[],"_revision_number":39},{"id":"9d180340f5441ce6f44402c39848b3a0df2e6b97","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2019-03-04 16:44:17.000000000","message":"Patch Set 39: Code-Review-1","accounts_in_message":[],"_revision_number":39},{"id":"8c736c85df01f28a0e5eb996bb87f7d8f02044a1","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-04 16:47:27.000000000","message":"Patch Set 39:\n\n(1 comment)","accounts_in_message":[],"_revision_number":39},{"id":"e2cc3c4ae106ae563f50309e1e63dd9673040a01","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-03-04 17:02:38.000000000","message":"Patch Set 39:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-28615 : SUCCESS in 1h 48m 30s","accounts_in_message":[],"_revision_number":39},{"id":"db47ef0ae0adc568ad1c07186909940f0e3075c6","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-04 17:03:16.000000000","message":"Patch Set 39:\n\n(3 comments)","accounts_in_message":[],"_revision_number":39},{"id":"880f305de6283a62e0dd1f90819b7d9eb4357d0e","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2019-03-04 17:05:31.000000000","message":"Patch Set 39:\n\n(6 comments)\n\nI\u0027m very afraid of us doing N Placement calls just for getting a RP name where N potentially be large.","accounts_in_message":[],"_revision_number":39},{"id":"2881bea21574b047defd00b5f7adee8385fd1d9d","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-04 17:15:45.000000000","message":"Patch Set 39:\n\n(1 comment)","accounts_in_message":[],"_revision_number":39},{"id":"f8126360c45ce038154dae6f1ab5897428fe4926","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-04 17:24:46.000000000","message":"Patch Set 39: Workflow-1\n\nTop of the really good review comments I have a functional-py35 specific error in some SRIOV test that I need to fix.\n\n{9} nova.tests.functional.libvirt.test_pci_sriov_servers.SRIOVServersTest.test_create_server_with_VF_no_PF [] ... inprogress\n{31} nova.tests.functional.libvirt.test_pci_sriov_servers.SRIOVServersTest.test_create_server_with_PF_no_VF [] ... inprogress\n{60} nova.tests.functional.libvirt.test_pci_sriov_servers.SRIOVServersTest.test_create_server_with_pci_dev_and_numa_fails [] ... inprogress\n{56} nova.tests.functional.libvirt.test_pci_sriov_servers.SRIOVServersTest.test_create_server_with_VF [] ... inprogress\n{53} nova.tests.functional.libvirt.test_pci_sriov_servers.SRIOVServersTest.test_create_server_with_PF [] ... inprogress\n{44} nova.tests.functional.libvirt.test_pci_sriov_servers.SRIOVServersTest.test_create_server_with_pci_dev_and_numa [] ... inprogress\nunorderable types: NoneType() \u003e datetime.datetime()","accounts_in_message":[],"_revision_number":39},{"id":"c1c8e4c16eb4bd16f740da9a62cd9e94dcef0a78","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-03-04 17:26:16.000000000","message":"Patch Set 39: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- grenade-py3 http://logs.openstack.org/43/623543/39/check/grenade-py3/e97d422/ : FAILURE in 6m 41s\n- tempest-full-py3 http://logs.openstack.org/43/623543/39/check/tempest-full-py3/3dff0ad/ : SUCCESS in 1h 27m 48s\n- openstack-tox-cover http://logs.openstack.org/43/623543/39/check/openstack-tox-cover/6fb48f9/cover/ : SUCCESS in 17m 27s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/39/check/openstack-tox-lower-constraints/8cb8d4b/ : SUCCESS in 14m 04s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/39/check/openstack-tox-pep8/8b34b37/ : SUCCESS in 9m 22s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/39/check/openstack-tox-py27/3764b3a/ : SUCCESS in 12m 41s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/39/check/openstack-tox-py35/5aafc39/ : SUCCESS in 12m 24s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/39/check/openstack-tox-py36/0ad9a50/ : SUCCESS in 10m 51s\n- openstack-tox-docs http://logs.openstack.org/43/623543/39/check/openstack-tox-docs/7d249bb/html/ : SUCCESS in 6m 02s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/39/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/b3d9062/ : SUCCESS in 47m 17s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/39/check/devstack-plugin-ceph-tempest/cd69c4d/ : SUCCESS in 1h 20m 29s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/39/check/legacy-grenade-dsvm-neutron-multinode-live-migration/a964c40/ : SUCCESS in 1h 09m 32s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/39/check/neutron-grenade-multinode/a87f78d/ : SUCCESS in 1h 16m 03s\n- nova-live-migration http://logs.openstack.org/43/623543/39/check/nova-live-migration/9d35084/ : SUCCESS in 50m 35s\n- nova-lvm http://logs.openstack.org/43/623543/39/check/nova-lvm/e58eae5/ : SUCCESS in 58m 59s (non-voting)\n- nova-next http://logs.openstack.org/43/623543/39/check/nova-next/31fc971/ : SUCCESS in 2h 04m 31s\n- nova-tox-functional http://logs.openstack.org/43/623543/39/check/nova-tox-functional/2c45313/ : SUCCESS in 19m 57s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/39/check/nova-tox-functional-py35/3d8e70b/ : FAILURE in 17m 31s\n- tempest-multinode-full http://logs.openstack.org/43/623543/39/check/tempest-multinode-full/806c74d/ : SUCCESS in 1h 45m 52s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/39/check/tempest-slow-py3/0738169/ : SUCCESS in 2h 09m 20s","accounts_in_message":[],"_revision_number":39},{"id":"81d49a0f9c0d693177ab171ab0213fb6ac59297b","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-03-04 19:08:39.000000000","message":"Patch Set 39:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/39 : FAILURE in 2h 39m 04s","accounts_in_message":[],"_revision_number":39},{"id":"84840591ec2a8680731ac283c44da83d959b6903","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-03-04 19:33:00.000000000","message":"Patch Set 39:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/39/check-vote/ext-nova-zuul/dfface9 : SUCCESS in 1h 05m 02s","accounts_in_message":[],"_revision_number":39},{"id":"7c0787a3a36cb1a43c1fe42f1e87b7603f3cb916","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-03-04 19:38:18.000000000","message":"Patch Set 39:\n\n(7 comments)","accounts_in_message":[],"_revision_number":39},{"id":"36989200e7c494e1cfb3d4228dc058f570ad76ed","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-03-04 19:39:05.000000000","message":"Patch Set 39: Code-Review-1\n\nthis is a pretty soft -1 mainly want to make sure that\nwe test both macvtap sriov and direct","accounts_in_message":[],"_revision_number":39},{"id":"98628e3c86f26f9eb8efd11c37b138637bbe62f2","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-03-04 22:09:02.000000000","message":"Patch Set 39:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/39/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/1cb8b08 : SUCCESS in 1h 13m 53s","accounts_in_message":[],"_revision_number":39},{"id":"dcc90c06d40e187cfde1340685fe02d7c8cae1f0","author":{"_account_id":9732,"name":"Mellanox CI","email":"mlnx-openstack-ci@dev.mellanox.co.il","username":"mellanox","tags":["SERVICE_USER"]},"date":"2019-03-05 04:16:25.000000000","message":"Patch Set 39:\n\nBuild succeeded.\n\n- Nova-ML2-Sriov http://13.74.249.42/43/623543/39/check-nova/Nova-ML2-Sriov/d4bd234 : SUCCESS in 1h 24m 48s (non-voting)\n- Nova-MACVTAP-ML2-Sriov http://13.74.249.42/43/623543/39/check-nova/Nova-MACVTAP-ML2-Sriov/a59e3b1 : SUCCESS in 1h 07m 23s (non-voting)\n- NVMe http://13.74.249.42/43/623543/39/check-nova/NVMe/44b81c5 : SUCCESS in 45m 35s (non-voting)\n\nTo re-run the job post \u0027recheck nova-mlnx\u0027 comment. For more information visit https://wiki.openstack.org/wiki/ThirdPartySystems/Mellanox_CI","accounts_in_message":[],"_revision_number":39},{"id":"c7063337e1be729763b80450bbf637bde38840d6","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-05 11:49:11.000000000","message":"Uploaded patch set 40.","accounts_in_message":[],"_revision_number":40},{"id":"b99be1835ef917b566b22bdf0b20b7a5e2558e35","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-03-05 11:49:39.000000000","message":"Patch Set 40:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":40},{"id":"f2d98e813893f6837c82fcac7c524a14f1621563","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-05 11:51:24.000000000","message":"Patch Set 40:\n\n(28 comments)\n\nThanks for the excellent reviews. I think I managed to fix / answer all your concerns and also fixed the failing functional-py35 run.","accounts_in_message":[],"_revision_number":40},{"id":"ea5695ff5c4ec4a946fd50dee3df8221f4729d8b","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-03-05 12:34:55.000000000","message":"Patch Set 40:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/40/check/nova-out-of-tree-pvm/a47d202 : FAILURE in 44m 31s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/40/check/nova-in-tree-pvm/ab89c62 : FAILURE in 42m 40s","accounts_in_message":[],"_revision_number":40},{"id":"bdc34dd61ee0e8419bb3040ac091658a8c78dca4","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-03-05 12:49:18.000000000","message":"Patch Set 39:\n\n(4 comments)","accounts_in_message":[],"_revision_number":39},{"id":"92051909f0dc10ce9c3de36a95af6eb243ef6644","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-03-05 12:58:01.000000000","message":"Patch Set 40:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-28674 : SUCCESS in 1h 05m 17s","accounts_in_message":[],"_revision_number":40},{"id":"c1f2f5a9e559b05badeef447f0661d9a70fa290b","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-05 13:13:04.000000000","message":"Patch Set 40:\n\n(4 comments)","accounts_in_message":[],"_revision_number":40},{"id":"1a14572c07622fb15daa1a1f13bdac60ca7ede87","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-03-05 13:49:54.000000000","message":"Patch Set 40: Code-Review+1\n\n(1 comment)\n\nya so i think this is ok for stein with some followups \nwork to do in train to make this a little more robust.","accounts_in_message":[],"_revision_number":40},{"id":"a44cbd342cf5375e57c5cd4363ae97173eb6ba63","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2019-03-05 14:09:01.000000000","message":"Patch Set 40: Code-Review+2\n\n(8 comments)","accounts_in_message":[],"_revision_number":40},{"id":"f362a6477477d9d9dcb0233751c764f70363b4b5","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-03-05 14:12:13.000000000","message":"Patch Set 40:\n\nFor rechecking only on the Cloudbase Nova Hyper-V CI, add a review comment with run-Cloudbase Nova Hyper-V CI\n\n- nova http://cloudbase-ci.com/nova/623543/40 : FAILURE in 2h 22m 10s","accounts_in_message":[],"_revision_number":40},{"id":"b87ddcc00ff59a8bffce6ee86420d75bda48dd35","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-03-05 14:13:35.000000000","message":"Patch Set 40: Verified+1\n\nBuild succeeded (check pipeline).\n\n- grenade-py3 http://logs.openstack.org/43/623543/40/check/grenade-py3/730fff2/ : SUCCESS in 1h 11m 22s\n- tempest-full-py3 http://logs.openstack.org/43/623543/40/check/tempest-full-py3/3154ea9/ : SUCCESS in 1h 33m 47s\n- openstack-tox-cover http://logs.openstack.org/43/623543/40/check/openstack-tox-cover/efa3739/cover/ : SUCCESS in 18m 48s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/40/check/openstack-tox-lower-constraints/c37ca7d/ : SUCCESS in 14m 13s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/40/check/openstack-tox-pep8/caeef16/ : SUCCESS in 11m 13s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/40/check/openstack-tox-py27/f8ac010/ : SUCCESS in 13m 07s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/40/check/openstack-tox-py35/9272fce/ : SUCCESS in 13m 32s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/40/check/openstack-tox-py36/0b371b1/ : SUCCESS in 14m 10s\n- openstack-tox-docs http://logs.openstack.org/43/623543/40/check/openstack-tox-docs/fa43027/html/ : SUCCESS in 6m 16s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/40/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/f4d1169/ : SUCCESS in 50m 33s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/40/check/devstack-plugin-ceph-tempest/96bcd4f/ : SUCCESS in 1h 21m 31s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/40/check/legacy-grenade-dsvm-neutron-multinode-live-migration/38110c0/ : SUCCESS in 1h 17m 17s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/40/check/neutron-grenade-multinode/d5e3f38/ : SUCCESS in 1h 16m 25s\n- nova-live-migration http://logs.openstack.org/43/623543/40/check/nova-live-migration/e003f37/ : SUCCESS in 50m 41s\n- nova-lvm http://logs.openstack.org/43/623543/40/check/nova-lvm/9b6facc/ : SUCCESS in 1h 05m 07s (non-voting)\n- nova-next http://logs.openstack.org/43/623543/40/check/nova-next/ded23a1/ : SUCCESS in 2h 03m 27s\n- nova-tox-functional http://logs.openstack.org/43/623543/40/check/nova-tox-functional/6f41cec/ : SUCCESS in 20m 22s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/40/check/nova-tox-functional-py35/25ca388/ : SUCCESS in 17m 10s\n- tempest-multinode-full http://logs.openstack.org/43/623543/40/check/tempest-multinode-full/f0c06d9/ : SUCCESS in 1h 54m 02s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/40/check/tempest-slow-py3/1676e06/ : SUCCESS in 2h 17m 06s","accounts_in_message":[],"_revision_number":40},{"id":"4596f689d4f0fa21ecac7a9d2e70a0dd218f9a4c","author":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"date":"2019-03-05 14:13:55.000000000","message":"Patch Set 40:\n\nBuild failed.  For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures\n\n- EMC_VxFlexOS_NOVA http://publiclogs.emc.com/43/623543/40/check/EMC_VxFlexOS_NOVA/8cc12e8/EMC_VxFlexOS_NOVA/None : NOT_REGISTERED\n\nLeave a comment with \u0027run-dell-emc-vxflexos\u0027 to trigger a recheck, for more information about CI, please see https://wiki.openstack.org/wiki/ThirdPartySystems/Dell_EMC_VxFlexOS_CI","accounts_in_message":[],"_revision_number":40},{"id":"19ea8b19e0ad759cc6a68db7334ba60ddde4b6dc","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-05 14:49:40.000000000","message":"Uploaded patch set 41.","accounts_in_message":[],"_revision_number":41},{"id":"a470ec9bcfc7f161f7d15821d553711beb182763","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-05 14:50:01.000000000","message":"Patch Set 41:\n\n(5 comments)","accounts_in_message":[],"_revision_number":41},{"id":"188343b5e250f101123a68b0c2cf2f16e7daefd0","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-03-05 14:50:10.000000000","message":"Patch Set 41:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":41},{"id":"b92d280c1123c204ba627139cef3a85d735ef4a6","author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"date":"2019-03-05 14:57:13.000000000","message":"Patch Set 41: Code-Review+2\n\n+2 tadaaaaam","accounts_in_message":[],"_revision_number":41},{"id":"4fbfbaf42e93c0968e47966ed7a05faa2edec391","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-03-05 15:32:52.000000000","message":"Patch Set 40:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-40 : FAILURE \n\nSee https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI for rechecking and info.","accounts_in_message":[],"_revision_number":40},{"id":"711e69f186db04829b5b502a06cb65ae077d3a95","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-03-05 15:34:34.000000000","message":"Patch Set 41:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/41/check/nova-out-of-tree-pvm/3be665b : FAILURE in 43m 55s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/41/check/nova-in-tree-pvm/b6d40d3 : FAILURE in 43m 27s","accounts_in_message":[],"_revision_number":41},{"id":"63274db35fa8c96493216519ab90f283d95ec89a","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-03-05 16:26:34.000000000","message":"Patch Set 41:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-28683 : SUCCESS in 1h 36m 20s","accounts_in_message":[],"_revision_number":41},{"id":"24e2b80a8150be101fbf8f2c938f70f364b435bf","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2019-03-05 16:53:18.000000000","message":"Uploaded patch set 42: Patch Set 41 was rebased.","accounts_in_message":[],"_revision_number":42},{"id":"30dee1cabfd75a8ff3c8ce4c68f71deddb7956e6","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-03-05 16:53:49.000000000","message":"Patch Set 42:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-intel-nfv-xenial tempest-dsvm-intel-nfv-xenial : SKIPPED (non-voting)\n- tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial tempest-dsvm-ovsdpdk-nfv-networking-xenial : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":42},{"id":"a4f94162773bb440f27ad43bb31ffc5296a1f9c3","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-03-05 17:36:51.000000000","message":"Patch Set 42:\n\nBuild failed. Comment \u0027powervm: recheck\u0027 to recheck.\n For 3rd party CI contact info: https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_PowerVM_CI\n\n- nova-out-of-tree-pvm http://184.172.12.213/43/623543/42/check/nova-out-of-tree-pvm/00c8f87 : FAILURE in 42m 54s\n- nova-in-tree-pvm http://184.172.12.213/43/623543/42/check/nova-in-tree-pvm/1adcdb2 : FAILURE in 42m 41s","accounts_in_message":[],"_revision_number":42},{"id":"8db23cbf3d6cc47959bca86941ecdd43816a32f2","author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"date":"2019-03-05 17:53:36.000000000","message":"Patch Set 42: Code-Review+2 Workflow+1","accounts_in_message":[],"_revision_number":42},{"id":"6b81cab344d3e3d4d9e394abe26cdeea51550a73","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-03-05 18:36:43.000000000","message":"Patch Set 42:\n\nTesting completed on the zVM Driver CI system check-nova pipeline.  To recheck only the zVM driver plugins, submit a comment with only zvm: recheck in the comment. Contact information: zvmosci@us.ibm.com. For information see https://wiki.openstack.org/wiki/ZVMDriver.\n\n- check-nova-master http://extbasicopstackcilog01.podc.sl.edst.ibm.com/test_logs/jenkins-check-nova-master-28694 : SUCCESS in 1h 40m 14s","accounts_in_message":[],"_revision_number":42},{"id":"726f2ed31c79209656de45294a255c2a83e09741","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-03-05 19:53:17.000000000","message":"Patch Set 42:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/623543/42 : SUCCESS in 2h 59m 16s","accounts_in_message":[],"_revision_number":42},{"id":"a92f4c84928e90f7be00e43a920ac5c70d71aa32","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-03-05 20:50:57.000000000","message":"Patch Set 42: Verified+1\n\nBuild succeeded (check pipeline).\n\n- grenade-py3 http://logs.openstack.org/43/623543/42/check/grenade-py3/e69f35b/ : SUCCESS in 1h 08m 19s\n- tempest-full-py3 http://logs.openstack.org/43/623543/42/check/tempest-full-py3/533de2b/ : SUCCESS in 1h 18m 59s\n- openstack-tox-cover http://logs.openstack.org/43/623543/42/check/openstack-tox-cover/c220740/cover/ : SUCCESS in 15m 21s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/42/check/openstack-tox-lower-constraints/73b305e/ : SUCCESS in 13m 25s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/42/check/openstack-tox-pep8/7e21674/ : SUCCESS in 10m 11s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/42/check/openstack-tox-py27/48d05fd/ : SUCCESS in 13m 49s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/42/check/openstack-tox-py35/5eb11fb/ : SUCCESS in 12m 09s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/42/check/openstack-tox-py36/7db46ef/ : SUCCESS in 13m 00s\n- openstack-tox-docs http://logs.openstack.org/43/623543/42/check/openstack-tox-docs/613818d/html/ : SUCCESS in 7m 52s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/43/623543/42/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/04f6107/ : SUCCESS in 46m 33s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/43/623543/42/check/devstack-plugin-ceph-tempest/c33db40/ : SUCCESS in 1h 17m 24s (non-voting)\n- legacy-grenade-dsvm-neutron-multinode-live-migration http://logs.openstack.org/43/623543/42/check/legacy-grenade-dsvm-neutron-multinode-live-migration/d909d6a/ : SUCCESS in 1h 00m 41s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/43/623543/42/check/neutron-grenade-multinode/c754e57/ : SUCCESS in 1h 30m 00s\n- nova-live-migration http://logs.openstack.org/43/623543/42/check/nova-live-migration/ade173f/ : SUCCESS in 49m 05s\n- nova-lvm http://logs.openstack.org/43/623543/42/check/nova-lvm/1a48846/ : SUCCESS in 1h 04m 12s (non-voting)\n- nova-next http://logs.openstack.org/43/623543/42/check/nova-next/605519f/ : SUCCESS in 1h 57m 05s\n- nova-tox-functional http://logs.openstack.org/43/623543/42/check/nova-tox-functional/8592e31/ : SUCCESS in 20m 18s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/42/check/nova-tox-functional-py35/0f9637b/ : SUCCESS in 17m 36s\n- tempest-multinode-full http://logs.openstack.org/43/623543/42/check/tempest-multinode-full/2d3cfc3/ : SUCCESS in 1h 41m 20s (non-voting)\n- tempest-slow-py3 http://logs.openstack.org/43/623543/42/check/tempest-slow-py3/6181601/ : SUCCESS in 2h 03m 42s","accounts_in_message":[],"_revision_number":42},{"id":"da5976a8a77160fbbd0d9e31fb039c4d75106a5e","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-03-05 20:51:35.000000000","message":"Patch Set 42: -Verified\n\nStarting gate jobs.","accounts_in_message":[],"_revision_number":42},{"id":"168d0f24ebcaa4b7794a30af0723c327510b8299","author":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"date":"2019-03-05 20:51:41.000000000","message":"Patch Set 42:\n\nBuild failed.  For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures\n\n- EMC_VxFlexOS_NOVA http://publiclogs.emc.com/43/623543/42/check/EMC_VxFlexOS_NOVA/0ab98b2/EMC_VxFlexOS_NOVA/None : NOT_REGISTERED\n\nLeave a comment with \u0027run-dell-emc-vxflexos\u0027 to trigger a recheck, for more information about CI, please see https://wiki.openstack.org/wiki/ThirdPartySystems/Dell_EMC_VxFlexOS_CI","accounts_in_message":[],"_revision_number":42},{"id":"4a8fb44a7c84859954cd0157b7791c13e0ff1994","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-03-05 22:00:41.000000000","message":"Patch Set 42:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-43-623543-42 : SUCCESS \n\nhttps://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI","accounts_in_message":[],"_revision_number":42},{"id":"9dadac6ad9807db1b9f669a57bb844238456fc2c","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-03-05 22:48:26.000000000","message":"Patch Set 42:\n\nBuild succeeded\n\n- dsvm-nova http://207.189.188.190/logs/43/623543/42/check-vote/ext-nova-zuul/ee821b7 : SUCCESS in 55m 47s","accounts_in_message":[],"_revision_number":42},{"id":"f3ad4f51cea60843c4f9a878b7b6f540ce070817","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-03-06 00:08:01.000000000","message":"Patch Set 42: Verified+2\n\nBuild succeeded (gate pipeline).\n\n- grenade-py3 http://logs.openstack.org/43/623543/42/gate/grenade-py3/3d4a71b/ : SUCCESS in 1h 00m 21s\n- tempest-full-py3 http://logs.openstack.org/43/623543/42/gate/tempest-full-py3/be95eff/ : SUCCESS in 1h 34m 34s\n- openstack-tox-lower-constraints http://logs.openstack.org/43/623543/42/gate/openstack-tox-lower-constraints/9f3a82d/ : SUCCESS in 12m 59s\n- openstack-tox-pep8 http://logs.openstack.org/43/623543/42/gate/openstack-tox-pep8/8b899e1/ : SUCCESS in 11m 54s\n- openstack-tox-py27 http://logs.openstack.org/43/623543/42/gate/openstack-tox-py27/f4e37c6/ : SUCCESS in 17m 29s\n- openstack-tox-py35 http://logs.openstack.org/43/623543/42/gate/openstack-tox-py35/fd61675/ : SUCCESS in 13m 31s\n- openstack-tox-py36 http://logs.openstack.org/43/623543/42/gate/openstack-tox-py36/eadb7d7/ : SUCCESS in 11m 46s\n- openstack-tox-docs http://logs.openstack.org/43/623543/42/gate/openstack-tox-docs/3f93f92/html/ : SUCCESS in 6m 22s\n- nova-live-migration http://logs.openstack.org/43/623543/42/gate/nova-live-migration/0205d9c/ : SUCCESS in 47m 47s\n- nova-tox-functional http://logs.openstack.org/43/623543/42/gate/nova-tox-functional/02b6fed/ : SUCCESS in 19m 31s\n- nova-tox-functional-py35 http://logs.openstack.org/43/623543/42/gate/nova-tox-functional-py35/5b24a2b/ : SUCCESS in 17m 55s\n- nova-next http://logs.openstack.org/43/623543/42/gate/nova-next/046e7c5/ : SUCCESS in 2h 26m 13s\n- tempest-slow-py3 http://logs.openstack.org/43/623543/42/gate/tempest-slow-py3/0474923/ : SUCCESS in 2h 17m 57s","accounts_in_message":[],"_revision_number":42},{"id":"2f62faeba9515f4b4da269ae218dbad073e6f9f4","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-03-06 00:08:02.000000000","message":"Change has been successfully merged by Zuul","accounts_in_message":[],"_revision_number":42},{"id":"05cbb5e5c8b539847a59608313c4f8427156e37a","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-03-06 04:03:59.000000000","message":"Patch Set 42:\n\nTesting succeeded on ubuntu-xenial-s390x. For rechecking only on the ubuntu-xenail-s390x CI, add a review comment with recheck-zkvm. Contact info: zkvm-ci@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/ThirdPartySystems/IBM_zKVM_CI\n\n- check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x http://sng01.objectstorage.softlayer.net/v1/AUTH_1940ea10-6e82-4501-b2f9-eb236510e575/ibmzkvmci/production/623543/42/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/ade5fbc : SUCCESS in 1h 22m 46s","accounts_in_message":[],"_revision_number":42}],"current_revision_number":42,"current_revision":"c02e213d507c830427a86d6a4bb4f7a2f5158590","revisions":{"f94564f89029abcec31dd6c059fa76a723ecde03":{"kind":"REWORK","_number":1,"created":"2018-12-07 16:18:19.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/1"}}},"commit":{"parents":[{"commit":"7d3af66e78fd5675e51506d89e8b9fc0adefb0e1","subject":"Remove port allocation during detach","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/7d3af66e78fd5675e51506d89e8b9fc0adefb0e1"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-07 16:03:54.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-07 16:03:54.000000000","tz":60},"subject":"Ensure that allocated PF matches the used PF","message":"Ensure that allocated PF matches the used PF\n\nA neutron port can be created with sriov vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bw request, then the\nnova scheduler\u0027s PciPassthroughFilter checks if a PCI device is available\nfor such request. This check is only based on the physnet of the neutron\nport and the physnet tag in the pci whitelist config. But it does not\nconsider that which PF provides the bandwidth.\n\nThe currently unsupported case is when a single compute node has more\nthan one PFs that are connected to the same physnet. This two PFs can have\ntotally different bandwidth inventories in placement. (E.g. PF1 has\nplenty of bandwidth available and PF2 has no bandwidth configured at all).\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF2 still has available VFs even if the bandwidtht from the port\nis fulfilled from PF1 which in return might not have available VFs any\nmore.\n\nMoreover the PciClaim has the same logic as the Filter so it will claim\nthe VF from PF2 while the bandwidth was allocated from PF1 in placement.\n\nTODO:\n * RPs are named after the device name, PCI request are identified by\n   PCI address. We need to be able to map between the two to know that\n   what PCI device can be selected based on the RP uuid that provides\n   the bandwidth.\n * Use a more generic base class for the functional test as the current\n   one creates an unnecessary ovs RP tree and we anyhow need to add more\n   sriov device RPs to placement.\n * Make the functional test show the missing mapping logic in\n * PciPassthroughFilter and in PciClaim\n * Add the missing logic :)\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/f94564f89029abcec31dd6c059fa76a723ecde03"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/f94564f89029abcec31dd6c059fa76a723ecde03"}]},"branch":"refs/heads/master"},"b5d2950b9f3b8e5ffbbef503078bc4f4d9782328":{"kind":"TRIVIAL_REBASE","_number":2,"created":"2018-12-10 09:43:58.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/2"}}},"commit":{"parents":[{"commit":"d26a1af3d8e8591b9855c40f01a8f5e009641fbf","subject":"Remove port allocation during detach","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/d26a1af3d8e8591b9855c40f01a8f5e009641fbf"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-07 16:03:54.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-10 09:43:31.000000000","tz":60},"subject":"Ensure that allocated PF matches the used PF","message":"Ensure that allocated PF matches the used PF\n\nA neutron port can be created with sriov vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bw request, then the\nnova scheduler\u0027s PciPassthroughFilter checks if a PCI device is available\nfor such request. This check is only based on the physnet of the neutron\nport and the physnet tag in the pci whitelist config. But it does not\nconsider that which PF provides the bandwidth.\n\nThe currently unsupported case is when a single compute node has more\nthan one PFs that are connected to the same physnet. This two PFs can have\ntotally different bandwidth inventories in placement. (E.g. PF1 has\nplenty of bandwidth available and PF2 has no bandwidth configured at all).\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF2 still has available VFs even if the bandwidtht from the port\nis fulfilled from PF1 which in return might not have available VFs any\nmore.\n\nMoreover the PciClaim has the same logic as the Filter so it will claim\nthe VF from PF2 while the bandwidth was allocated from PF1 in placement.\n\nTODO:\n * RPs are named after the device name, PCI request are identified by\n   PCI address. We need to be able to map between the two to know that\n   what PCI device can be selected based on the RP uuid that provides\n   the bandwidth.\n * Use a more generic base class for the functional test as the current\n   one creates an unnecessary ovs RP tree and we anyhow need to add more\n   sriov device RPs to placement.\n * Make the functional test show the missing mapping logic in\n * PciPassthroughFilter and in PciClaim\n * Add the missing logic :)\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b5d2950b9f3b8e5ffbbef503078bc4f4d9782328"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b5d2950b9f3b8e5ffbbef503078bc4f4d9782328"}]},"branch":"refs/heads/master"},"8cd86cdd3d1e12a750e2e3a381e1397291407ae9":{"kind":"REWORK","_number":3,"created":"2018-12-10 13:20:00.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/3"}}},"commit":{"parents":[{"commit":"b6fb980e4bda03f7203c0b2418ea5fbea0703e21","subject":"Refactor PortResourceRequestBasedSchedulingTestBase","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b6fb980e4bda03f7203c0b2418ea5fbea0703e21"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-10 13:18:33.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-10 13:18:33.000000000","tz":60},"subject":"Ensure that allocated PF matches the used PF","message":"Ensure that allocated PF matches the used PF\n\nA neutron port can be created with sriov vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bw request, then the\nnova scheduler\u0027s PciPassthroughFilter checks if a PCI device is available\nfor such request. This check is only based on the physnet of the neutron\nport and the physnet tag in the pci whitelist config. But it does not\nconsider that which PF provides the bandwidth.\n\nThe currently unsupported case is when a single compute node has more\nthan one PFs that are connected to the same physnet. This two PFs can have\ntotally different bandwidth inventories in placement. (E.g. PF2 has\nplenty of bandwidth available and PF3 has no bandwidth configured at all).\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the PciClaim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch adds a functional test case to that shows the failure in the\nabove use case.\n\nTODO:\n * add the missing logic in PciClaim\n * add the missing logic if PciPassthroughFilter\n * device RPs are named after the device name, PCI request are identified by\n   PCI address. We need to be able to map between the two to know that\n   what PCI device can be selected based on the RP uuid that provides\n   the bandwidth.\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/8cd86cdd3d1e12a750e2e3a381e1397291407ae9"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/8cd86cdd3d1e12a750e2e3a381e1397291407ae9"}]},"branch":"refs/heads/master"},"536693c0d8f25bb77d45864e1fb0c1963c078ca1":{"kind":"REWORK","_number":4,"created":"2018-12-11 16:29:19.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/4","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/4","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/4"}}},"commit":{"parents":[{"commit":"b6fb980e4bda03f7203c0b2418ea5fbea0703e21","subject":"Refactor PortResourceRequestBasedSchedulingTestBase","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b6fb980e4bda03f7203c0b2418ea5fbea0703e21"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-10 13:18:33.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-11 16:28:19.000000000","tz":60},"subject":"Ensure that allocated PF matches the used PF","message":"Ensure that allocated PF matches the used PF\n\nA neutron port can be created with sriov vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bw request, then the\nnova scheduler\u0027s PciPassthroughFilter checks if a PCI device is available\nfor such request. This check is only based on the physnet of the neutron\nport and the physnet tag in the pci whitelist config. But it does not\nconsider that which PF provides the bandwidth.\n\nThe currently unsupported case is when a single compute node has more\nthan one PFs that are connected to the same physnet. This two PFs can have\ntotally different bandwidth inventories in placement. (E.g. PF2 has\nplenty of bandwidth available and PF3 has no bandwidth configured at all).\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the PciClaim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch adds a functional test case to that shows the failure in the\nabove use case.\n\nTODO:\n  * split up the patch to smaller pieces (object change, conf change,\n    manager change)\n  * refactor manager code to smaller functions\n  * document the new pci whitelist flag\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/536693c0d8f25bb77d45864e1fb0c1963c078ca1"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/536693c0d8f25bb77d45864e1fb0c1963c078ca1"}]},"branch":"refs/heads/master"},"c0106691ba708b0cf48fd0dfebd60b2195968bf4":{"kind":"REWORK","_number":5,"created":"2018-12-12 17:07:39.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/5","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/5","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/5"}}},"commit":{"parents":[{"commit":"b6fb980e4bda03f7203c0b2418ea5fbea0703e21","subject":"Refactor PortResourceRequestBasedSchedulingTestBase","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b6fb980e4bda03f7203c0b2418ea5fbea0703e21"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-10 13:18:33.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-12 17:07:30.000000000","tz":60},"subject":"Ensure that allocated PF matches the used PF","message":"Ensure that allocated PF matches the used PF\n\nA neutron port can be created with sriov vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bw request, then the\nnova scheduler\u0027s PciPassthroughFilter checks if a PCI device is available\nfor such request. This check is only based on the physnet of the neutron\nport and the physnet tag in the pci whitelist config. But it does not\nconsider that which PF provides the bandwidth.\n\nThe currently unsupported case is when a single compute node has more\nthan one PFs that are connected to the same physnet. This two PFs can have\ntotally different bandwidth inventories in placement. (E.g. PF2 has\nplenty of bandwidth available and PF3 has no bandwidth configured at all).\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the PciClaim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch adds a functional test case to that shows the failure in the\nabove use case.\n\nTODO:\n  * split up the patch to smaller pieces (object change, conf change,\n    manager change)\n  * refactor manager code to smaller functions\n  * document the new pci whitelist flag\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c0106691ba708b0cf48fd0dfebd60b2195968bf4"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c0106691ba708b0cf48fd0dfebd60b2195968bf4"}]},"branch":"refs/heads/master"},"ba6f4a26c29df2c68a48fca52d74a7b039d4080b":{"kind":"TRIVIAL_REBASE","_number":6,"created":"2018-12-14 14:36:54.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/6","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/6","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/6"}}},"commit":{"parents":[{"commit":"c1a13b6de9a720d88d5cc7cce0694b472d9cca6e","subject":"Refactor PortResourceRequestBasedSchedulingTestBase","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c1a13b6de9a720d88d5cc7cce0694b472d9cca6e"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-10 13:18:33.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 14:27:10.000000000","tz":60},"subject":"Ensure that allocated PF matches the used PF","message":"Ensure that allocated PF matches the used PF\n\nA neutron port can be created with sriov vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bw request, then the\nnova scheduler\u0027s PciPassthroughFilter checks if a PCI device is available\nfor such request. This check is only based on the physnet of the neutron\nport and the physnet tag in the pci whitelist config. But it does not\nconsider that which PF provides the bandwidth.\n\nThe currently unsupported case is when a single compute node has more\nthan one PFs that are connected to the same physnet. This two PFs can have\ntotally different bandwidth inventories in placement. (E.g. PF2 has\nplenty of bandwidth available and PF3 has no bandwidth configured at all).\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the PciClaim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch adds a functional test case to that shows the failure in the\nabove use case.\n\nTODO:\n  * split up the patch to smaller pieces (object change, conf change,\n    manager change)\n  * refactor manager code to smaller functions\n  * document the new pci whitelist flag\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/ba6f4a26c29df2c68a48fca52d74a7b039d4080b"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/ba6f4a26c29df2c68a48fca52d74a7b039d4080b"}]},"branch":"refs/heads/master"},"ac94c57b62aad27745dc7f8b8f35ae5554b359c8":{"kind":"TRIVIAL_REBASE_WITH_MESSAGE_UPDATE","_number":7,"created":"2018-12-14 16:53:22.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/7","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/7","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/7"}}},"commit":{"parents":[{"commit":"1d17e100142d7464d17b9ee0c11df7f6287f4de3","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/1d17e100142d7464d17b9ee0c11df7f6287f4de3"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * refactor manager code to smaller functions\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/ac94c57b62aad27745dc7f8b8f35ae5554b359c8"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/ac94c57b62aad27745dc7f8b8f35ae5554b359c8"}]},"branch":"refs/heads/master"},"c97f01c7acfc6495565ff24c285f9d86e2d27484":{"kind":"TRIVIAL_REBASE","_number":8,"created":"2018-12-14 17:45:41.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/8","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/8","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/8"}}},"commit":{"parents":[{"commit":"3ff10737e6cf4178d9694fcd2879314ffa18ca40","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/3ff10737e6cf4178d9694fcd2879314ffa18ca40"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 17:41:41.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * refactor manager code to smaller functions\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c97f01c7acfc6495565ff24c285f9d86e2d27484"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c97f01c7acfc6495565ff24c285f9d86e2d27484"}]},"branch":"refs/heads/master"},"cec90a53344f4ff0d3df2b95d31deb725fbf5b18":{"kind":"TRIVIAL_REBASE","_number":9,"created":"2018-12-18 15:49:46.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/9","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/9","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/9 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/9 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/9 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/9"}}},"commit":{"parents":[{"commit":"5b0aad610b1569bf1eab4f756158269793163c9e","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/5b0aad610b1569bf1eab4f756158269793163c9e"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-18 15:38:12.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * refactor manager code to smaller functions\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/cec90a53344f4ff0d3df2b95d31deb725fbf5b18"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/cec90a53344f4ff0d3df2b95d31deb725fbf5b18"}]},"branch":"refs/heads/master"},"3764d9fb096cb83bd95fb72464682f0c63ac2742":{"kind":"TRIVIAL_REBASE","_number":10,"created":"2018-12-19 15:49:06.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/10","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/10","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/10 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/10 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/10 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/10"}}},"commit":{"parents":[{"commit":"861c2286dc40388bca5dc2c553d87366b6912555","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/861c2286dc40388bca5dc2c553d87366b6912555"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-19 15:45:20.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * refactor manager code to smaller functions\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/3764d9fb096cb83bd95fb72464682f0c63ac2742"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/3764d9fb096cb83bd95fb72464682f0c63ac2742"}]},"branch":"refs/heads/master"},"b0aa904eed078a2a529e50071b13fa35fd6c8a28":{"kind":"TRIVIAL_REBASE","_number":11,"created":"2018-12-20 10:16:35.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/11","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/11","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/11 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/11 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/11 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/11"}}},"commit":{"parents":[{"commit":"a7f0e3affcc893c537e512239564b5136c0a2f7b","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a7f0e3affcc893c537e512239564b5136c0a2f7b"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-20 10:13:46.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * refactor manager code to smaller functions\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b0aa904eed078a2a529e50071b13fa35fd6c8a28"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b0aa904eed078a2a529e50071b13fa35fd6c8a28"}]},"branch":"refs/heads/master"},"4e240ef1ed141f4a2e73b7bd73b65ca447b66619":{"kind":"TRIVIAL_REBASE","_number":12,"created":"2018-12-20 16:00:39.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/12","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/12","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/12 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/12 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/12 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/12"}}},"commit":{"parents":[{"commit":"2d9e1a399b1668e3b60dc684d596e206688bdf50","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/2d9e1a399b1668e3b60dc684d596e206688bdf50"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-20 16:00:14.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * refactor manager code to smaller functions\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/4e240ef1ed141f4a2e73b7bd73b65ca447b66619"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/4e240ef1ed141f4a2e73b7bd73b65ca447b66619"}]},"branch":"refs/heads/master"},"5e746f4935ee77fc37345a95f8d75b174e2ada57":{"kind":"REWORK","_number":13,"created":"2019-01-14 16:29:33.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/13","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/13","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/13 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/13 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/13 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/13"}}},"commit":{"parents":[{"commit":"0abebe46613361522ea32caad7434bf1e3257393","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/0abebe46613361522ea32caad7434bf1e3257393"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-01-14 16:28:43.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * refactor manager code to smaller functions\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/5e746f4935ee77fc37345a95f8d75b174e2ada57"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/5e746f4935ee77fc37345a95f8d75b174e2ada57"}]},"branch":"refs/heads/master"},"333759ec9c1d3e9478a4403380c6f79139dd5d67":{"kind":"REWORK","_number":14,"created":"2019-01-24 15:29:40.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/14","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/14","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/14 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/14 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/14 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/14"}}},"commit":{"parents":[{"commit":"a9c42886755dc9e8f5a28aa4f6a9c18addcfe1e1","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a9c42886755dc9e8f5a28aa4f6a9c18addcfe1e1"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-01-24 15:28:26.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/333759ec9c1d3e9478a4403380c6f79139dd5d67"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/333759ec9c1d3e9478a4403380c6f79139dd5d67"}]},"branch":"refs/heads/master"},"f4f2f36330edf823f92ef148cb0db88469e89214":{"kind":"TRIVIAL_REBASE","_number":15,"created":"2019-01-24 16:21:55.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/15","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/15","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/15 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/15 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/15 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/15"}}},"commit":{"parents":[{"commit":"f70efb21e19216ef2cc25edf3a729f6d21a894b2","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/f70efb21e19216ef2cc25edf3a729f6d21a894b2"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-01-24 16:12:33.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/f4f2f36330edf823f92ef148cb0db88469e89214"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/f4f2f36330edf823f92ef148cb0db88469e89214"}]},"branch":"refs/heads/master"},"232be3e9b9e67a6b6e4785d6738b87e13ed29958":{"kind":"TRIVIAL_REBASE","_number":16,"created":"2019-01-26 16:32:54.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/16","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/16","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/16 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/16 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/16 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/16"}}},"commit":{"parents":[{"commit":"fb89ab08528ba668d9773ab8b4e7e92ae77b232b","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/fb89ab08528ba668d9773ab8b4e7e92ae77b232b"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-01-26 16:32:36.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/232be3e9b9e67a6b6e4785d6738b87e13ed29958"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/232be3e9b9e67a6b6e4785d6738b87e13ed29958"}]},"branch":"refs/heads/master"},"a4e4b3c9e2ffccd9cb73196f0a617685cca81955":{"kind":"TRIVIAL_REBASE","_number":17,"created":"2019-01-28 14:51:40.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/17","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/17","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/17 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/17 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/17 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/17"}}},"commit":{"parents":[{"commit":"a3bb1ded1e6973370af397931928fe0a68fd33ff","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a3bb1ded1e6973370af397931928fe0a68fd33ff"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-01-28 14:51:11.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a4e4b3c9e2ffccd9cb73196f0a617685cca81955"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a4e4b3c9e2ffccd9cb73196f0a617685cca81955"}]},"branch":"refs/heads/master"},"b526e0f574f3b4accb03c95ffbe7396f69973bbf":{"kind":"TRIVIAL_REBASE","_number":18,"created":"2019-02-05 10:54:46.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/18","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/18","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/18 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/18 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/18 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/18"}}},"commit":{"parents":[{"commit":"ff7929e427c34c428eff7bae42d67736e4a51a05","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/ff7929e427c34c428eff7bae42d67736e4a51a05"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-05 10:50:22.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * add functional test\n    * sriov port without bandwidth works\n    * bandwidth available in one PF but VF available only on the other\n      PF where bandwdith is not available\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b526e0f574f3b4accb03c95ffbe7396f69973bbf"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b526e0f574f3b4accb03c95ffbe7396f69973bbf"}]},"branch":"refs/heads/master"},"bf0ea0bd41438aa7819e8ebc3e34d6fbbe46ed1d":{"kind":"REWORK","_number":19,"created":"2019-02-05 15:42:49.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/19","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/19","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/19 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/19 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/19 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/19"}}},"commit":{"parents":[{"commit":"ff7929e427c34c428eff7bae42d67736e4a51a05","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/ff7929e427c34c428eff7bae42d67736e4a51a05"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-05 15:42:06.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/bf0ea0bd41438aa7819e8ebc3e34d6fbbe46ed1d"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/bf0ea0bd41438aa7819e8ebc3e34d6fbbe46ed1d"}]},"branch":"refs/heads/master"},"6608f3e345b46be8f46ce43877bdd17ffbcc16af":{"kind":"TRIVIAL_REBASE","_number":20,"created":"2019-02-06 15:16:54.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/20","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/20","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/20 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/20 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/20 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/20"}}},"commit":{"parents":[{"commit":"aeb16b49bdf1ee0a4fc790c4313a052f585934a6","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/aeb16b49bdf1ee0a4fc790c4313a052f585934a6"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-06 15:12:08.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/6608f3e345b46be8f46ce43877bdd17ffbcc16af"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/6608f3e345b46be8f46ce43877bdd17ffbcc16af"}]},"branch":"refs/heads/master"},"341fbad68981eacac67696a52327a705b9f72555":{"kind":"TRIVIAL_REBASE","_number":21,"created":"2019-02-08 01:07:13.000000000","uploader":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"ref":"refs/changes/43/623543/21","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/21","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/21 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/21 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/21 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/21"}}},"commit":{"parents":[{"commit":"b824bb75d698f932d1a1cb04053c11a5067c1163","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b824bb75d698f932d1a1cb04053c11a5067c1163"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-02-08 01:06:53.000000000","tz":-300},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/341fbad68981eacac67696a52327a705b9f72555"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/341fbad68981eacac67696a52327a705b9f72555"}]},"branch":"refs/heads/master"},"307c7c3f8801486582ae2cbd6e5b9e71d5990db3":{"kind":"TRIVIAL_REBASE","_number":22,"created":"2019-02-12 09:46:07.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/22","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/22","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/22 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/22 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/22 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/22"}}},"commit":{"parents":[{"commit":"010fc0208379575eedc1c315f54e39af9fb3cd06","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/010fc0208379575eedc1c315f54e39af9fb3cd06"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-12 09:41:39.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nTODO:\n  * unit test coverage\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/307c7c3f8801486582ae2cbd6e5b9e71d5990db3"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/307c7c3f8801486582ae2cbd6e5b9e71d5990db3"}]},"branch":"refs/heads/master"},"77d567b8211e5032bcff415dfbe91ef12d0cb658":{"kind":"REWORK","_number":23,"created":"2019-02-12 13:49:22.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/23","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/23","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/23 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/23 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/23 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/23"}}},"commit":{"parents":[{"commit":"010fc0208379575eedc1c315f54e39af9fb3cd06","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/010fc0208379575eedc1c315f54e39af9fb3cd06"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-12 13:49:06.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/77d567b8211e5032bcff415dfbe91ef12d0cb658"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/77d567b8211e5032bcff415dfbe91ef12d0cb658"}]},"branch":"refs/heads/master"},"16a4de500f0b504dc2f62a4fd8b883eb7c5c6962":{"kind":"TRIVIAL_REBASE","_number":24,"created":"2019-02-12 16:06:04.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/24","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/24","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/24 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/24 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/24 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/24"}}},"commit":{"parents":[{"commit":"42ce42c4a4c985b4406c57859788ae888b97457e","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/42ce42c4a4c985b4406c57859788ae888b97457e"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-12 15:46:14.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/16a4de500f0b504dc2f62a4fd8b883eb7c5c6962"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/16a4de500f0b504dc2f62a4fd8b883eb7c5c6962"}]},"branch":"refs/heads/master"},"9b2c6fb753aa7b89ea7655ab06d7c1fd477a0aef":{"kind":"TRIVIAL_REBASE","_number":25,"created":"2019-02-13 10:04:58.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/25","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/25","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/25 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/25 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/25 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/25"}}},"commit":{"parents":[{"commit":"16dc22eed14193f1162211c679199ee01c254425","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/16dc22eed14193f1162211c679199ee01c254425"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-13 09:57:40.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/9b2c6fb753aa7b89ea7655ab06d7c1fd477a0aef"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/9b2c6fb753aa7b89ea7655ab06d7c1fd477a0aef"}]},"branch":"refs/heads/master"},"a8d4a5d1e11fc2371098eb797d7a2282c1c58b36":{"kind":"TRIVIAL_REBASE","_number":26,"created":"2019-02-15 13:24:07.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/26","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/26","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/26 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/26 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/26 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/26"}}},"commit":{"parents":[{"commit":"c0367da2ff08fdfbbadd064661135ba42703f982","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c0367da2ff08fdfbbadd064661135ba42703f982"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-15 13:23:55.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a8d4a5d1e11fc2371098eb797d7a2282c1c58b36"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a8d4a5d1e11fc2371098eb797d7a2282c1c58b36"}]},"branch":"refs/heads/master"},"7785ea3ca00eaf8555cb38f19f4c2b5397acf2aa":{"kind":"TRIVIAL_REBASE","_number":27,"created":"2019-02-15 13:38:03.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/27","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/27","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/27 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/27 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/27 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/27"}}},"commit":{"parents":[{"commit":"9fda2f71f0adb829bbbfbe45ed6131d057421972","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/9fda2f71f0adb829bbbfbe45ed6131d057421972"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-15 13:37:47.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/7785ea3ca00eaf8555cb38f19f4c2b5397acf2aa"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/7785ea3ca00eaf8555cb38f19f4c2b5397acf2aa"}]},"branch":"refs/heads/master"},"0336d4a80075dbfdc9623d93c7be9d95517c563d":{"kind":"TRIVIAL_REBASE","_number":28,"created":"2019-02-18 13:14:02.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/28","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/28","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/28 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/28 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/28 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/28"}}},"commit":{"parents":[{"commit":"6d8274968c55321633924a51f1d99790e18ab9a9","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/6d8274968c55321633924a51f1d99790e18ab9a9"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-18 13:09:48.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/0336d4a80075dbfdc9623d93c7be9d95517c563d"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/0336d4a80075dbfdc9623d93c7be9d95517c563d"}]},"branch":"refs/heads/master"},"a430071f56026a90a2e3dd0442a1f0dd002c75bf":{"kind":"TRIVIAL_REBASE","_number":29,"created":"2019-02-18 13:31:53.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/29","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/29","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/29 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/29 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/29 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/29"}}},"commit":{"parents":[{"commit":"5cd81786490fc4632ec628cd61332bd268b5e030","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/5cd81786490fc4632ec628cd61332bd268b5e030"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-18 13:19:03.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a430071f56026a90a2e3dd0442a1f0dd002c75bf"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a430071f56026a90a2e3dd0442a1f0dd002c75bf"}]},"branch":"refs/heads/master"},"8a2fe36fd56e1627c46afa4599a9c3d0ea3a5791":{"kind":"TRIVIAL_REBASE","_number":30,"created":"2019-02-20 08:16:43.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/30","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/30","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/30 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/30 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/30 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/30"}}},"commit":{"parents":[{"commit":"6f0a9583cf099cd0e7ccd1b103aa1db9454ee632","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/6f0a9583cf099cd0e7ccd1b103aa1db9454ee632"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-20 08:16:34.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/8a2fe36fd56e1627c46afa4599a9c3d0ea3a5791"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/8a2fe36fd56e1627c46afa4599a9c3d0ea3a5791"}]},"branch":"refs/heads/master"},"8ee18f55d1a2d8abb40d35d378518c05b55d472d":{"kind":"TRIVIAL_REBASE","_number":31,"created":"2019-02-21 11:45:01.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/31","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/31","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/31 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/31 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/31 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/31"}}},"commit":{"parents":[{"commit":"2fe38963f5f152f4bc6037b01486322e1f5da29d","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/2fe38963f5f152f4bc6037b01486322e1f5da29d"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-21 11:40:11.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/8ee18f55d1a2d8abb40d35d378518c05b55d472d"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/8ee18f55d1a2d8abb40d35d378518c05b55d472d"}]},"branch":"refs/heads/master"},"55bcc241167b9aafdeafd7419d8dcc007dbd0c2a":{"kind":"TRIVIAL_REBASE","_number":32,"created":"2019-02-27 13:14:30.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/32","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/32","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/32 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/32 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/32 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/32"}}},"commit":{"parents":[{"commit":"d2a6db6b81057318b09af0d9498934fe2298a896","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/d2a6db6b81057318b09af0d9498934fe2298a896"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-27 13:12:22.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/55bcc241167b9aafdeafd7419d8dcc007dbd0c2a"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/55bcc241167b9aafdeafd7419d8dcc007dbd0c2a"}]},"branch":"refs/heads/master"},"0b828ec49db7b08065d0e654fe863a9149824e3b":{"kind":"TRIVIAL_REBASE","_number":33,"created":"2019-02-27 13:25:41.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/33","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/33","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/33 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/33 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/33 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/33"}}},"commit":{"parents":[{"commit":"82875ec1713297627ba7e3b04a3604654e3fc547","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/82875ec1713297627ba7e3b04a3604654e3fc547"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-27 13:15:11.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/0b828ec49db7b08065d0e654fe863a9149824e3b"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/0b828ec49db7b08065d0e654fe863a9149824e3b"}]},"branch":"refs/heads/master"},"01f73c6485556fce36c89ccdce7eab6d75d797c9":{"kind":"TRIVIAL_REBASE","_number":34,"created":"2019-02-27 17:08:37.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/34","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/34","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/34 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/34 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/34 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/34"}}},"commit":{"parents":[{"commit":"bfff37becf21dd8d6c31ea81faa8c8b996011e29","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/bfff37becf21dd8d6c31ea81faa8c8b996011e29"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-02-27 17:08:25.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/01f73c6485556fce36c89ccdce7eab6d75d797c9"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/01f73c6485556fce36c89ccdce7eab6d75d797c9"}]},"branch":"refs/heads/master"},"a8d488ccdef6c0cdbb511cdbae42e17649ade43a":{"kind":"REWORK","_number":35,"created":"2019-03-01 13:03:53.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/35","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/35","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/35 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/35 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/35 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/35"}}},"commit":{"parents":[{"commit":"9358a6646e9b822cfe9e98300ce41a3351d973e6","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/9358a6646e9b822cfe9e98300ce41a3351d973e6"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-03-01 13:03:27.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a8d488ccdef6c0cdbb511cdbae42e17649ade43a"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a8d488ccdef6c0cdbb511cdbae42e17649ade43a"}]},"branch":"refs/heads/master"},"65e7024f581ba1bc353b5cffbbdaec1d6c1de81d":{"kind":"TRIVIAL_REBASE","_number":36,"created":"2019-03-01 13:04:39.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/36","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/36","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/36 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/36 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/36 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/36"}}},"commit":{"parents":[{"commit":"b03b0ea1fac64f2627928e01748d3546baf2fa8a","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/b03b0ea1fac64f2627928e01748d3546baf2fa8a"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-03-01 13:04:39.000000000","tz":0},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/65e7024f581ba1bc353b5cffbbdaec1d6c1de81d"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/65e7024f581ba1bc353b5cffbbdaec1d6c1de81d"}]},"branch":"refs/heads/master"},"0cc0eb17c481e013711b81c4b5427a3bf5cef8d4":{"kind":"TRIVIAL_REBASE","_number":37,"created":"2019-03-01 15:51:34.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/37","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/37","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/37 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/37 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/37 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/37"}}},"commit":{"parents":[{"commit":"798122270a53829706d244534d72ed4264f17a1b","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/798122270a53829706d244534d72ed4264f17a1b"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-03-01 15:51:11.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/0cc0eb17c481e013711b81c4b5427a3bf5cef8d4"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/0cc0eb17c481e013711b81c4b5427a3bf5cef8d4"}]},"branch":"refs/heads/master"},"d4a7a8b78c9ea7bee8327b32b71f68894162f3d0":{"kind":"TRIVIAL_REBASE","_number":38,"created":"2019-03-04 09:10:07.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/38","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/38","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/38 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/38 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/38 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/38"}}},"commit":{"parents":[{"commit":"c6fddd785df4efd0acaa3817c1471ab45cdeab57","subject":"Add pf_interface_name tag to passthrough_whitelist","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c6fddd785df4efd0acaa3817c1471ab45cdeab57"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-03-04 09:07:49.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can havee plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe  InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF based on the value of the\n``pf_interface_name`` tag in the pci/passthrough_whitelist config\noption introduced in the previous patch.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/d4a7a8b78c9ea7bee8327b32b71f68894162f3d0"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/d4a7a8b78c9ea7bee8327b32b71f68894162f3d0"}]},"branch":"refs/heads/master"},"7143131c8b1ae0c68060d16df45c6a877422d167":{"kind":"REWORK","_number":39,"created":"2019-03-04 15:13:36.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/39","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/39","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/39 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/39 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/39 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/39"}}},"commit":{"parents":[{"commit":"727b942a88a812afb7368b4d7d3c314a4f8554ed","subject":"Merge \"Record requester in the InstancePCIRequest\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/727b942a88a812afb7368b4d7d3c314a4f8554ed"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-03-04 15:13:15.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is only based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. But it does not consider that which PF\nprovides the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PFs which are connected to the same\nphysnet. This two PFs can have totally different bandwidth inventories\nin placement. For example PF2 can have plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter migth accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the pci claim has the same logic as the Filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the pci claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The pci claim code knows about the PF\ninterface name of each available VF from the virt driver reporting the\n\u0027pf_interface_name\u0027 key as part of the return value of the\nget_available_resource() driver call.\n\nThe current patch extends the libvirt driver to provider PF interface\nname informaton. Besides the libvirt driver the xenapi driver also\nsupport SRIOV VF handling but this patch does not extend the xenapi\ndriver. So for the xenapi the above described configuration currently\nkept unsupported.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/7143131c8b1ae0c68060d16df45c6a877422d167"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/7143131c8b1ae0c68060d16df45c6a877422d167"}]},"branch":"refs/heads/master"},"a3dc1ac8b25e4ab1daf9216b234ed29b3955d56d":{"kind":"REWORK","_number":40,"created":"2019-03-05 11:49:11.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/40","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/40","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/40 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/40 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/40 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/40"}}},"commit":{"parents":[{"commit":"727b942a88a812afb7368b4d7d3c314a4f8554ed","subject":"Merge \"Record requester in the InstancePCIRequest\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/727b942a88a812afb7368b4d7d3c314a4f8554ed"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-03-05 11:44:53.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. It does not consider the actual PF\nproviding the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PF which are connected to the same\nphysnet. These PFs can have totally different bandwidth inventories\nin placement. For example PF2 can have plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter might accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the PCI claim has the same logic as the filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the PCI claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The PCI claim code knows about the PF\ninterface name of each available VF from the virt driver reporting the\n\u0027parent_ifname\u0027 key as part of the return value of the\nget_available_resource() driver call.\n\nThe PCI claim process is not changed as it already enforces that\nevery fields from the request matches with the fields of the selected\ndevice pool.\n\nThe current patch extends the libvirt driver to provider PF interface\nname information. Besides the libvirt driver the xenapi driver also\nsupport SRIOV VF handling but this patch does not extend the xenapi\ndriver. So for the xenapi the above described configuration currently\nkept unsupported.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a3dc1ac8b25e4ab1daf9216b234ed29b3955d56d"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a3dc1ac8b25e4ab1daf9216b234ed29b3955d56d"}]},"branch":"refs/heads/master"},"ecea762eb9f6a15f1006ad574c5ab6c8a9cb24c5":{"kind":"REWORK","_number":41,"created":"2019-03-05 14:49:40.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/41","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/41","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/41 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/41 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/41 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/41"}}},"commit":{"parents":[{"commit":"727b942a88a812afb7368b4d7d3c314a4f8554ed","subject":"Merge \"Record requester in the InstancePCIRequest\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/727b942a88a812afb7368b4d7d3c314a4f8554ed"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-03-05 14:49:26.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. It does not consider the actual PF\nproviding the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PF which are connected to the same\nphysnet. These PFs can have totally different bandwidth inventories\nin placement. For example PF2 can have plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter might accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the PCI claim has the same logic as the filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the PCI claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The PCI claim code knows about the PF\ninterface name of each available VF from the virt driver reporting the\n\u0027parent_ifname\u0027 key as part of the return value of the\nget_available_resource() driver call.\n\nThe PCI claim process is not changed as it already enforces that\nevery fields from the request matches with the fields of the selected\ndevice pool.\n\nThe current patch extends the libvirt driver to provider PF interface\nname information. Besides the libvirt driver the xenapi driver also\nsupport SRIOV VF handling but this patch does not extend the xenapi\ndriver. So for the xenapi the above described configuration currently\nkept unsupported.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/ecea762eb9f6a15f1006ad574c5ab6c8a9cb24c5"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/ecea762eb9f6a15f1006ad574c5ab6c8a9cb24c5"}]},"branch":"refs/heads/master"},"c02e213d507c830427a86d6a4bb4f7a2f5158590":{"kind":"TRIVIAL_REBASE","_number":42,"created":"2019-03-05 16:53:18.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/43/623543/42","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/43/623543/42","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/42 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/42 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/43/623543/42 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/43/623543/42"}}},"commit":{"parents":[{"commit":"c43c1d3fb9da5dd0a13e1f15623a696212f095ff","subject":"Merge \"libvirt: Omit needless check on \u0027CONF.serial_console\u0027\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c43c1d3fb9da5dd0a13e1f15623a696212f095ff"}]}],"author":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2018-12-14 16:23:00.000000000","tz":60},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@ericsson.com","date":"2019-03-05 16:48:29.000000000","tz":60},"subject":"Ensure that bandwidth and VF are from the same PF","message":"Ensure that bandwidth and VF are from the same PF\n\nA neutron port can be created with direct vnic type and also it can have\nbandwidth resource request at the same time. In this case placement will\noffer allocation candidates that could fulfill the bandwidth request, then\nthe nova scheduler\u0027s PciPassthroughFilter checks if a PCI device, a VF,\nis available for such request. This check is based on the physnet\nof the neutron port and the physical_network tag in the\npci/passthrough_whitelist config. It does not consider the actual PF\nproviding the bandwidth.\n\nThe currently unsupported case is when a single compute node has\nwhitelisted VFs from more than one PF which are connected to the same\nphysnet. These PFs can have totally different bandwidth inventories\nin placement. For example PF2 can have plenty of bandwidth available\nand PF3 has no bandwidth configured at all.\n\nIn this case the PciPassthroughFilter might accept the host simply\nbecause PF3 still has available VFs even if the bandwidth from the port\nis fulfilled from PF2 which in return might not have available VFs any\nmore.\n\nMoreover the PCI claim has the same logic as the filter so it will claim\nthe VF from PF3 while the bandwidth was allocated from PF2 in placement.\n\nThis patch does not try to solve the issue in the PciPassthroughFilter but\nit does solves the issue in the pci claim. This means that after\nsuccessful scheduling the pci claim can still fail if bandwidth is\nallocated from one PF but a VF is not available from that specific PF\nany more. This will lead to re-schedule.\n\nMaking the PciPassthroughFilter smart enough is complicated because:\n* The filters are not knowing about placement allocation candidates at\n  all\n* The filters are working per compute host not per allocation\n  candidates. If there are two allocation candidates for the same host\n  then nova will only try to filter for the first one. [1][2]\n\nThis patch applies the following logic:\n\nThe compute manager checks the InstancePCIRequest ovos in a given\nboot request and maps each of them to the neutron port that requested\nthe PCI device. Then it maps the neutron port to the physical device\nRP in the placement allocation made for this server. Then the spec in\nthe InstancePCIRequest is extended with the interface name of the PF\nfrom where the bandwidth was allocated from based on the name of the\ndevice RP. Then the PCI claim will enforce that the PF interface\nname in the request matches the interface name of the PF from where\nthe VF is selected from. The PCI claim code knows about the PF\ninterface name of each available VF from the virt driver reporting the\n\u0027parent_ifname\u0027 key as part of the return value of the\nget_available_resource() driver call.\n\nThe PCI claim process is not changed as it already enforces that\nevery fields from the request matches with the fields of the selected\ndevice pool.\n\nThe current patch extends the libvirt driver to provider PF interface\nname information. Besides the libvirt driver the xenapi driver also\nsupport SRIOV VF handling but this patch does not extend the xenapi\ndriver. So for the xenapi the above described configuration currently\nkept unsupported.\n\nI know that this feels complicated but it is necessary becase VFs has\nnot been counted as resources in placement yet.\n\n[1] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L239\n[2] https://github.com/openstack/nova/blob/f6996903d2ef0fdb40135b506c83ed6517b28e19/nova/scheduler/filter_scheduler.py#L426\n\nblueprint: bandwidth-resource-provider\n\nChange-Id: I038867c4094d79ae4a20615ab9c9f9e38fcc2e0a\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c02e213d507c830427a86d6a4bb4f7a2f5158590"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/c02e213d507c830427a86d6a4bb4f7a2f5158590"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}