)]}'
{"id":"openstack%2Fnova~656885","triplet_id":"openstack%2Fnova~master~Ic5fadd69722b430c07739eb37295eedcd2621f35","project":"openstack/nova","branch":"master","topic":"routed-networks-scheduling","hashtags":[],"change_id":"Ic5fadd69722b430c07739eb37295eedcd2621f35","subject":"WIP: Hey let\u0027s support routed networks y\u0027all!","status":"ABANDONED","created":"2019-05-02 22:13:06.000000000","updated":"2021-03-08 18:54:08.000000000","total_comment_count":8,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"aa56c1048731d9b2e2c481a41e198c340202ecb8","_number":656885,"virtual_id_number":656885,"owner":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"actions":{},"labels":{"Verified":{"disliked":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},{"date":"2020-04-13 07:57:49.000000000","_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},{"value":0,"date":"2020-03-03 21:33:28.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},{"value":0,"date":"2020-03-03 19:04:26.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},{"date":"2020-03-03 18:02:13.000000000","_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},{"tag":"autogenerated:zuul:check","value":-1,"date":"2020-03-04 01:09:31.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},{"date":"2020-03-03 20:00:04.000000000","_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"_account_id":21798,"name":"Bernard Cafarelli","email":"bcafarel@redhat.com","username":"bcafarel"},{"date":"2020-07-15 21:36:42.000000000","_account_id":9452,"name":"James Penick","email":"penick@verizonmedia.com","username":"epim"},{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"date":"2020-07-16 07:46:26.000000000","_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"_account_id":23871,"name":"MargaritaShakhova","email":"shakhova.margarita@gmail.com","username":"MargaritaShakhova"}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","value":-1,"default_value":0,"optional":true},"Code-Review":{"all":[{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":21798,"name":"Bernard Cafarelli","email":"bcafarel@redhat.com","username":"bcafarel"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":9452,"name":"James Penick","email":"penick@verizonmedia.com","username":"epim"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":23871,"name":"MargaritaShakhova","email":"shakhova.margarita@gmail.com","username":"MargaritaShakhova"}],"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":{"all":[{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","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":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},{"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},{"value":0,"permitted_voting_range":{"min":-1,"max":0},"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"_account_id":21798,"name":"Bernard Cafarelli","email":"bcafarel@redhat.com","username":"bcafarel"},{"_account_id":9452,"name":"James Penick","email":"penick@verizonmedia.com","username":"epim"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"_account_id":23871,"name":"MargaritaShakhova","email":"shakhova.margarita@gmail.com","username":"MargaritaShakhova"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true},"Review-Priority":{"all":[{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":21798,"name":"Bernard Cafarelli","email":"bcafarel@redhat.com","username":"bcafarel"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":9452,"name":"James Penick","email":"penick@verizonmedia.com","username":"epim"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":23871,"name":"MargaritaShakhova","email":"shakhova.margarita@gmail.com","username":"MargaritaShakhova"}],"values":{" 0":"Default Priority","+1":"Contributor Review Promise","+2":"Core Review Promise"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},{"_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":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},{"_account_id":9452,"name":"James Penick","email":"penick@verizonmedia.com","username":"epim"},{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"_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":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":21798,"name":"Bernard Cafarelli","email":"bcafarel@redhat.com","username":"bcafarel"},{"_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":23871,"name":"MargaritaShakhova","email":"shakhova.margarita@gmail.com","username":"MargaritaShakhova"},{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},{"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2019-05-02 22:40:44.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-05-02 22:41:39.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":"2019-05-02 23:58:54.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-05-03 01:09:07.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-05-03 01:29:07.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-05-03 09:33:34.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-05-03 10:45:07.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-05-03 20:26:37.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-05-03 21:05:21.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":"2019-05-05 14:45:38.000000000","updated_by":{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},"reviewer":{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},"state":"REVIEWER"},{"updated":"2019-05-21 17:45:18.000000000","updated_by":{"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},"reviewer":{"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},"state":"REVIEWER"},{"updated":"2019-07-23 22:21:37.000000000","updated_by":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"reviewer":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"state":"REVIEWER"},{"updated":"2019-09-12 16:48:02.000000000","updated_by":{"_account_id":23871,"name":"MargaritaShakhova","email":"shakhova.margarita@gmail.com","username":"MargaritaShakhova"},"reviewer":{"_account_id":23871,"name":"MargaritaShakhova","email":"shakhova.margarita@gmail.com","username":"MargaritaShakhova"},"state":"REVIEWER"},{"updated":"2019-09-25 16:22:08.000000000","updated_by":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"reviewer":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"state":"REVIEWER"},{"updated":"2019-11-07 04:11:30.000000000","updated_by":{"_account_id":21798,"name":"Bernard Cafarelli","email":"bcafarel@redhat.com","username":"bcafarel"},"reviewer":{"_account_id":21798,"name":"Bernard Cafarelli","email":"bcafarel@redhat.com","username":"bcafarel"},"state":"REVIEWER"},{"updated":"2019-11-29 18:43:44.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":"2020-02-26 13:56:02.000000000","updated_by":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"reviewer":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"state":"REVIEWER"},{"updated":"2020-02-27 00:23:05.000000000","updated_by":{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},"reviewer":{"_account_id":26458,"name":"Brin Zhang","email":"zhangbailin@inspur.com","username":"zhangbailin"},"state":"REVIEWER"},{"updated":"2020-03-03 18:02:13.000000000","updated_by":{"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},"reviewer":{"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},"state":"REVIEWER"},{"updated":"2020-03-03 19:04:26.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":"2020-03-03 20:00:04.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":"2020-03-03 21:33:28.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":"2020-03-04 01:09:31.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":"2020-04-13 07:57:49.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"},{"updated":"2020-07-15 21:36:42.000000000","updated_by":{"_account_id":9452,"name":"James Penick","email":"penick@verizonmedia.com","username":"epim"},"reviewer":{"_account_id":9452,"name":"James Penick","email":"penick@verizonmedia.com","username":"epim"},"state":"REVIEWER"},{"updated":"2020-07-16 07:46:26.000000000","updated_by":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"reviewer":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"state":"REVIEWER"}],"messages":[{"id":"18b632aa954ce3e5957e82d936256596bd3f4f3e","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-05-02 22:13:06.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"dbde7079822325fcb19af4d3a13a864ca92bdb3a","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-05-02 22:13:39.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":"939e2c059aa8227cc17e45e2340ccc878060f51d","author":{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},"date":"2019-05-02 22:15:37.000000000","message":"Patch Set 1:\n\nBuild failed\n\n- check-dsvm-tempest-vz7-exe-minimal http://openstack-3rd-party-virtuozzo-ci-logs.virtuozzo.com/85/656885/1/check/check-dsvm-tempest-vz7-exe-minimal/4009e9e : FAILURE in 52s\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":"df29b748287c35cd51c130057380c382802baeef","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-05-02 22:17:21.000000000","message":"Patch Set 1:\n\n(1 comment)","accounts_in_message":[],"_revision_number":1},{"id":"79b70a0470dcc1eeeab642ff718bc9ef53d8fcfe","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-05-02 22:18:17.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/656885/1/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/bc31765 : FAILURE in 4m 26s","accounts_in_message":[],"_revision_number":1},{"id":"9d5874011eb24b8bb9ef907862a9dfae87e5a485","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-05-02 22:35:57.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"7fc1d89b33846d3af7fc7383a727259345d730a9","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-05-02 22:36:28.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":"09ad5f1bbebb385a2e07205eb07f990f06be26be","author":{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},"date":"2019-05-02 22:37:18.000000000","message":"Patch Set 2:\n\nBuild failed\n\n- check-dsvm-tempest-vz7-exe-minimal http://openstack-3rd-party-virtuozzo-ci-logs.virtuozzo.com/85/656885/2/check/check-dsvm-tempest-vz7-exe-minimal/d143eb7 : FAILURE in 28s\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":2},{"id":"99c32355213a64c05287a5ab518591d09d2938ea","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-05-02 22:40:14.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"2348981f5e450442c511b0fbb1386be63cae2b36","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2019-05-02 22:40:44.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":"58d8ae680f4b11ae675d5adf3b2d9d583a6c3b11","author":{"_account_id":16898,"name":"Virtuozzo CI","email":"virtuozzo6-ci@virtuozzo.com","username":"virtuozzo6-ci","tags":["SERVICE_USER"]},"date":"2019-05-02 22:41:39.000000000","message":"Patch Set 3:\n\nBuild failed\n\n- check-dsvm-tempest-vz7-exe-minimal http://openstack-3rd-party-virtuozzo-ci-logs.virtuozzo.com/85/656885/3/check/check-dsvm-tempest-vz7-exe-minimal/ee823c7 : FAILURE in 27s\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":"047a5885c9887862511b421ff87ff0b99a95b846","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2019-05-02 22:43:19.000000000","message":"Patch Set 1:\n\n* pci-test http://52.27.155.124/pci/656885/1 : SUCCESS","accounts_in_message":[],"_revision_number":1},{"id":"61ed6c5b2b18e4ecab1a540c71fb5b291e6fc56c","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2019-05-02 22:48:17.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/656885/3/check-tempest-dsvm-neutron-full-ubuntu-xenial-s390x/b67cc21 : FAILURE in 4m 51s","accounts_in_message":[],"_revision_number":3},{"id":"907145a20a455d269729014a4f2686be7cd994b0","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2019-05-02 23:41:52.000000000","message":"Patch Set 2:\n\n* pci-test http://52.27.155.124/pci/656885/2 : SUCCESS","accounts_in_message":[],"_revision_number":2},{"id":"a9b73d1c015e04b13a0e51be9bac4381a97411fe","author":{"_account_id":15751,"name":"Intel PCI CI","email":"pci-ci@intel.com","username":"intelpcici","tags":["SERVICE_USER"]},"date":"2019-05-02 23:58:54.000000000","message":"Patch Set 3:\n\n* pci-test http://52.27.155.124/pci/656885/3 : SUCCESS","accounts_in_message":[],"_revision_number":3},{"id":"6131f5967593c6745fa97ca75356e55763ef0bcc","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2019-05-03 00:25:38.000000000","message":"Patch Set 3:\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-31504 : FAILURE in 1h 44m 12s","accounts_in_message":[],"_revision_number":3},{"id":"ca2394a3eb59c5907b19e5747f57cfd8a0aa1872","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-05-03 01:08:42.000000000","message":"Patch Set 3: Verified+1\n\nBuild succeeded (check pipeline).\n\n- grenade-py3 http://logs.openstack.org/85/656885/3/check/grenade-py3/03d30b2/ : SUCCESS in 1h 10m 37s\n- tempest-full-py3 http://logs.openstack.org/85/656885/3/check/tempest-full-py3/4621063/ : SUCCESS in 1h 45m 57s\n- openstack-tox-cover http://logs.openstack.org/85/656885/3/check/openstack-tox-cover/5de8159/cover/ : SUCCESS in 20m 16s\n- openstack-tox-lower-constraints http://logs.openstack.org/85/656885/3/check/openstack-tox-lower-constraints/0886c9a/ : SUCCESS in 13m 21s\n- openstack-tox-pep8 http://logs.openstack.org/85/656885/3/check/openstack-tox-pep8/ec9a1af/ : SUCCESS in 10m 49s\n- openstack-tox-py27 http://logs.openstack.org/85/656885/3/check/openstack-tox-py27/11f3e33/ : SUCCESS in 17m 55s\n- openstack-tox-py36 http://logs.openstack.org/85/656885/3/check/openstack-tox-py36/1d856c9/ : SUCCESS in 12m 16s\n- openstack-tox-py37 http://logs.openstack.org/85/656885/3/check/openstack-tox-py37/ae0164e/ : SUCCESS in 10m 07s\n- openstack-tox-docs http://logs.openstack.org/85/656885/3/check/openstack-tox-docs/5ee201f/html/ : SUCCESS in 6m 54s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa http://logs.openstack.org/85/656885/3/check/ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa/e11b25f/ : SUCCESS in 1h 09m 51s (non-voting)\n- devstack-plugin-ceph-tempest http://logs.openstack.org/85/656885/3/check/devstack-plugin-ceph-tempest/0e22122/ : FAILURE in 1h 54m 18s (non-voting)\n- neutron-grenade-multinode http://logs.openstack.org/85/656885/3/check/neutron-grenade-multinode/824a0ae/ : SUCCESS in 1h 00m 53s\n- neutron-tempest-linuxbridge http://logs.openstack.org/85/656885/3/check/neutron-tempest-linuxbridge/1857f94/ : SUCCESS in 1h 21m 45s\n- nova-grenade-live-migration http://logs.openstack.org/85/656885/3/check/nova-grenade-live-migration/c5c6263/ : SUCCESS in 1h 00m 00s\n- nova-live-migration http://logs.openstack.org/85/656885/3/check/nova-live-migration/42e5046/ : SUCCESS in 55m 24s\n- nova-multi-cell http://logs.openstack.org/85/656885/3/check/nova-multi-cell/f43f05f/ : SUCCESS in 1h 37m 10s (non-voting)\n- nova-next http://logs.openstack.org/85/656885/3/check/nova-next/90856fb/ : SUCCESS in 1h 34m 40s\n- nova-tox-functional http://logs.openstack.org/85/656885/3/check/nova-tox-functional/49312be/ : SUCCESS in 17m 10s\n- nova-tox-functional-py36 http://logs.openstack.org/85/656885/3/check/nova-tox-functional-py36/f3803d5/ : SUCCESS in 17m 11s\n- tempest-slow-py3 http://logs.openstack.org/85/656885/3/check/tempest-slow-py3/e042673/ : SUCCESS in 2h 26m 32s","accounts_in_message":[],"_revision_number":3},{"id":"d3da0d8e3cb603688fcb01e2a0b6c1ddbf33fc0f","author":{"_account_id":15941,"name":"DellEMC PowerFlex CI","email":"emc.scaleio.ci@emc.com","username":"emc-scaleio-ci","tags":["SERVICE_USER"]},"date":"2019-05-03 01:09:07.000000000","message":"Patch Set 3:\n\nBuild failed.  For information on how to proceed, see https://docs.openstack.org/infra/manual/developers.html\n\n- EMC_VxFlexOS_NOVA http://publiclogs.emc.com/85/656885/3/check/EMC_VxFlexOS_NOVA/5bb95cd/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":3},{"id":"f56195155f59aeae47b403c048fe549e8ab5b777","author":{"_account_id":16128,"name":"IBM PowerVM CI","email":"powervmci@linux.vnet.ibm.com","username":"powervmci","tags":["SERVICE_USER"]},"date":"2019-05-03 01:29:07.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/85/656885/3/check/nova-out-of-tree-pvm/b9d788c : FAILURE in 2h 27m 03s\n- nova-in-tree-pvm http://184.172.12.213/85/656885/3/check/nova-in-tree-pvm/517d222 : FAILURE in 2h 48m 01s","accounts_in_message":[],"_revision_number":3},{"id":"41eca2f02ddb0ff946ac7869dc1f89761aa1d9f5","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2019-05-03 03:44:56.000000000","message":"Patch Set 3:\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/656885/3 : FAILURE in 2h 27m 37s","accounts_in_message":[],"_revision_number":3},{"id":"60ffede6316efc777d85b0c3f0bf7c52fb5a9559","author":{"_account_id":9008,"name":"VMware NSX CI","username":"vmwareminesweeper","tags":["SERVICE_USER"]},"date":"2019-05-03 09:33:34.000000000","message":"Patch Set 3:\n\nBuild failed\n\n- dsvm-nova http://207.189.188.190/logs/85/656885/3/check-vote/ext-nova-zuul/ff53940 : FAILURE in 1h 15m 20s","accounts_in_message":[],"_revision_number":3},{"id":"5d8120e20400dde0873e851f8d77197ad2c260a7","author":{"_account_id":14384,"name":"Quobyte CI","email":"openstack-ci-external@quobyte.com","username":"quobyteci","tags":["SERVICE_USER"]},"date":"2019-05-03 10:45:07.000000000","message":"Patch Set 3:\n\n* nova-quobyteci-dsvm-volume http://78.46.57.153:8081/refs-changes-85-656885-3 : FAILURE \n\nSee https://wiki.openstack.org/wiki/ThirdPartySystems/Quobyte_CI for rechecking and info.","accounts_in_message":[],"_revision_number":3},{"id":"bd7787d0b6b5712dc9015595b55e1ca4b1761138","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2019-05-03 11:47:14.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/85/656885/3/check/tempest-dsvm-full-xenial/f1455a4/ : SUCCESS in 2h 38m 43s\n- tempest-dsvm-full-xenial-py3 https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/85/656885/3/check/tempest-dsvm-full-xenial-py3/b5e0b0d/ : SUCCESS in 1h 19m 05s (non-voting)\n- grenade-dsvm-xenial https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/85/656885/3/check/grenade-dsvm-xenial/565a4ac/ : SUCCESS in 53m 43s (non-voting)","accounts_in_message":[],"_revision_number":3},{"id":"1704e9ccb94e6619c4eef224fa53cba1a09cdb92","author":{"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},"date":"2019-05-03 19:26:53.000000000","message":"Patch Set 3:\n\nHey y\u0027all, thanks for this :-)","accounts_in_message":[],"_revision_number":3},{"id":"be480ddc6aec818f961d71f6eaffb47f6b66acfd","author":{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},"date":"2019-05-03 20:03:49.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"a4e5b86ed6c37c4cdea4bfb29cf1a55e8f3265de","author":{"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},"date":"2019-05-03 20:15:16.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"e395426f59248b7fb99f8da54dfdc97179339614","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-05-03 21:01:15.000000000","message":"Patch Set 3:\n\n(3 comments)","accounts_in_message":[],"_revision_number":3},{"id":"feff9f95aa017677ac6430c9e3cb4066ef76b983","author":{"_account_id":1653,"name":"garyk","email":"gkotton@vmware.com","username":"garyk"},"date":"2019-05-05 14:45:38.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"abf42d146ee6eba38706b0b48c95a8602f0c0ca5","author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"date":"2019-05-10 12:38:08.000000000","message":"Patch Set 3:\n\nFYI: on master there are issues with routed provider networks feature, see: https://bugs.launchpad.net/neutron/+bug/1828543","accounts_in_message":[],"_revision_number":3},{"id":"cc3714fece24958b18437849b9bd60f9269e8ba2","author":{"_account_id":10962,"name":"David Bingham","email":"dbingham@godaddy.com","username":"wwriverrat"},"date":"2019-05-21 17:45:18.000000000","message":"Patch Set 3:\n\nJust a heads up to bring visibility to another routed_networks initiative...\n\nIn neutron, there is a need for allowing multiple segments to be supported by a single host. This change effectively should allow a single host to access/use/configure multiple segments of the same network. Ref: https://review.opendev.org/#/c/657170/3/specs/train/multi-segment-per-host-support.rst\n\nWe\u0027re not yet fully sure what this means to the APIs. As I stated in the spec, we have a little homework to do: \"Unknown, but expected to be minor if so. There may be data that comes back from an existing API that expects one item to be returned, when there may now be many after this change.\"","accounts_in_message":[],"_revision_number":3},{"id":"f1ef812854e5cc9924c31e57b3b6c3fc57a45f65","author":{"_account_id":23871,"name":"MargaritaShakhova","email":"shakhova.margarita@gmail.com","username":"MargaritaShakhova"},"date":"2019-09-12 16:48:02.000000000","message":"Patch Set 3: Code-Review+1","accounts_in_message":[],"_revision_number":3},{"id":"648805f3377d124892553c47a7420c9b5f30c885","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-09-25 16:24:02.000000000","message":"Patch Set 3:\n\nIt\u0027s been awhile but Miguel was asking about this and it was discussed a bit in IRC today as well:\n\nhttp://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-09-25.log.html#t2019-09-25T15:49:13\n\ntl;dr I think a good start on the routed networks stuff would be someone writing a tempest test for a multinode job that does the necessary host aggregate setup in nova and network setup in neutron such that neutron will do the placement plumbing for the resource provider aggregates and then try to boot a server with network1 in aggregate1 against host2 from aggregate2 (using microversion 2.74) and assert it fails b/c we didn\u0027t schedule properly, meaning with this change you\u0027d expect a NoValidHost failure, but without this change we\u0027d likely try to boot on host2 and fail port binding since network1 wouldn\u0027t be wired for host2.","accounts_in_message":[],"_revision_number":3},{"id":"45e77e8b22174f2338f1f8b9dbdf50d5c633dc59","author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"date":"2019-09-30 10:16:38.000000000","message":"Patch Set 3:\n\nHi Matt: The tempest test I proposed and waiting for comments if I understand well what should happen:\nhttps://review.opendev.org/665155","accounts_in_message":[],"_revision_number":3},{"id":"9316d7001eb3e335856416de1440d188dafb4342","author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"date":"2019-10-01 11:23:37.000000000","message":"Patch Set 3:\n\nHi Matt: So the main part of my yesterday\u0027s comment (sorry I was running home) was that I started some tempest tests, but kept them as WIP as I am not sure that my approach for testing routed provider net feature is good. So would be helpful to have comments about the direction/test design first. Thanks in advance","accounts_in_message":[],"_revision_number":3},{"id":"52563796cca4949879619d33ea6f38346fa4a25a","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-11-29 18:43:44.000000000","message":"Patch Set 3: Code-Review-1\n\nthis does not have a spec and while i think some fo the chagne make sense i think we shoudl modify neutron to populate the network segments as part of the neutron port create so that we dont have to look it up in nova. the other aspect that this does not adress is the availablity of ips in any given segment.\n\nideally i think we should be modelling network segments as placement aggregates, we shoudl IMO model ip subnets/capacity as a sharing resouce provider of ip resources and leverage the resource request feature that was added by gibi for the minimum bandwidth feature.\n\nnow we could declare the ip capastiy out of scope initally but i do think that it makes sense to track ip avaiabliy in placemnt as a consumable resouce. the exact form im not sure about but i think that is a seperate feature to the general problem of can i route this ip to a given host/network segment.\n\nso i think this needs a spec to flesh out some of the details to ensure we can make this work for all the move operation and not back us into a corner when it come to addressing ip aviabliy at some other point.","accounts_in_message":[],"_revision_number":3},{"id":"8a3b338015328dfe1db60ea24e27661796648278","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-11-30 14:15:44.000000000","message":"Patch Set 3:\n\nSurely this needs a blueprint and spec, yes. This was just a WIP thrown up during the Train PTG in Denver. I\u0027m obviously not actively working on this nor do I plan to. Someone that wants to make this happen (Verizon Media, GoDaddy, others?) will need to work together on this (Miguel was talking about a pop up team for this I thought at one point).","accounts_in_message":[],"_revision_number":3},{"id":"4b96a8722d8fd0bad29526af0956e57bdf4ef12c","author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"date":"2019-11-30 14:27:28.000000000","message":"Abandoned\n\nI\u0027m going to drop this since I\u0027m not working on it. It can be restored if/when someone else wants to take this over.","accounts_in_message":[],"_revision_number":3},{"id":"1ca688888323c759d7975bcbfc406cc7aea1f63f","author":{"_account_id":26970,"name":"Yang Youseok","email":"ileixe@gmail.com","username":"ileixe"},"date":"2020-02-11 04:43:49.000000000","message":"Patch Set 3:\n\nIs there any alternative for this functionality? How current routed network work without this?","accounts_in_message":[],"_revision_number":3},{"id":"becf0edddbb76ee89f8c497dce0d2acfdc82cc5a","author":{"_account_id":26970,"name":"Yang Youseok","email":"ileixe@gmail.com","username":"ileixe"},"date":"2020-02-12 06:39:36.000000000","message":"Patch Set 3:\n\nI need this functionality and seems that nobody works now, so could I go foward with this patch? Could someone can give any advice to do? or can I just keep making patchs for this?","accounts_in_message":[],"_revision_number":3},{"id":"07901825ce876dc89860fb26491c842f177a4368","author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"date":"2020-02-18 21:42:13.000000000","message":"Patch Set 3:\n\n@Yang Youseok My employer also would like to have this functionality. At the beginning of the U cycle, we offered to implement it. We were told by the Nova PTL that even if we implemented the code, he couldn\u0027t commit core reviewers time to look at our code. As a consequence, my employer told me to do something else. If you are interested, ping me and maybe together we can convince the powers of Nova to help merge this functionality","accounts_in_message":[],"_revision_number":3},{"id":"0206a73acbc370d3cee0da17dec0f3af6543a916","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2020-02-19 16:22:26.000000000","message":"Patch Set 3:\n\n\u003e At the beginning of the U cycle, we offered to implement it. We were told by the Nova PTL that even if we implemented the code, he couldn\u0027t commit core reviewers time to look at our code.\n\nAre you referring to [1]? I don\u0027t feel that\u0027s a fair interpretation of what I said -- or at least what I meant. Let me try to rephrase:\n\nNeither I nor any PTL can ever \"commit\" core reviewer time. That\u0027s just a given. Approved blueprints with ready code all compete for reviewer attention, subject to the interests and expertise of those reviewers, the squeakiness of wheels, and (to a *much* lesser extent, in my experience) stated project priorities.\n\nBut also subject to how many blueprints are in the approved pool. So, normalizing for all those other things, if your blueprint is one of 50, and we\u0027re only going to manage to land 25, yours has a 50% chance. But if your blueprint is one of 30, you\u0027ve got an 83% chance. Unless yours is one that gets cut; then you have a 0% chance. But at least you know that up front, rather than assuming \"approved\" means \"will land, barring unforseen\" and being disappointed.\n\nSo all I was saying was that I want to reduce the total approved pool.\n\nIt sounds like you assumed I had already decided to cut this one. I didn\u0027t. First of all, that\u0027s not my decision; it\u0027s the team\u0027s. Second, that exercise has *just* started [2].\n\n\u003e As a consequence, my employer told me to do something else. If you are interested, ping me and maybe together we can convince the powers of Nova to help merge this functionality\n\nAt this point we\u0027re past spec freeze. As previously agreed, this would need a blueprint and a spec (obviously we can\u0027t just use the one from newton). There\u0027s not really a hard deadline, but it seems unlikely that we can get a spec authored and approved quickly enough to reasonably qualify for an exception.\n\nIt sounds like this effort was dropped back in the Fall due to a miscommunication. For my part in that miscommunication, I apologize. All I can suggest now is that you get a jump on a blueprint and spec for Victoria (you can put the spec in the backlog/ directory [3] for now).\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-09-25.log.html#t2019-09-25T15:49:13\n[2] http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012612.html\n[3] http://specs.openstack.org/openstack/nova-specs/readme.html#backlog-specifications","accounts_in_message":[],"_revision_number":3},{"id":"a1566b7e992ccf903049a59fcad9ed3bb0464207","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2020-02-19 17:36:12.000000000","message":"Patch Set 3:\n\nfor what its worth we have downstrem in terest in this too but we were not planning to look at it until Victora at the earliest.\n\nthe current patch was not teh right approch to adress this. it was a fine poc to show that we coudl do something but as i suggested before and on the mail thread architeutly neutron shoudl be providign constratits to nova via the port with regards to placment aggreates,traits,resouce requests like we do for bandwith aware schdulign so there is work that need to be done on the neutron side first to report the subent to host mappaing via placement aggreate and then pass that info via the port to nova so we can consume it when schduling.","accounts_in_message":[],"_revision_number":3},{"id":"e4d5ae0c2a533744a2a010bbb5d327db291b057f","author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"date":"2020-02-20 07:49:18.000000000","message":"Patch Set 3:\n\n\u003e @Yang Youseok My employer also would like to have this\n \u003e functionality. At the beginning of the U cycle, we offered to\n \u003e implement it. We were told by the Nova PTL that even if we\n \u003e implemented the code, he couldn\u0027t commit core reviewers time to\n \u003e look at our code. As a consequence, my employer told me to do\n \u003e something else. If you are interested, ping me and maybe together\n \u003e we can convince the powers of Nova to help merge this functionality\n\nI can dedicate as well some time to it, and happy to help","accounts_in_message":[],"_revision_number":3},{"id":"16ddd0c0836f46cb20e34f71c88ef5ab504439dd","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2020-02-20 08:24:34.000000000","message":"Patch Set 3:\n\n\u003e \n \u003e At this point we\u0027re past spec freeze. As previously agreed, this\n \u003e would need a blueprint and a spec (obviously we can\u0027t just use the\n \u003e one from newton). There\u0027s not really a hard deadline, but it seems\n \u003e unlikely that we can get a spec authored and approved quickly\n \u003e enough to reasonably qualify for an exception.\n \u003e \n\n+100 \n\nLajos and me talked about this feature many times but I never knew and still not know what is the expected behavior of nova here, what neutron already does, and overall what is missing. So please write a spec. I\u0027m happy to review it from nova perspective. Also please take a look at [1] where Lajos tries to collect expected external behavior of this feature.\n\n[1] https://review.opendev.org/#/c/665155","accounts_in_message":[],"_revision_number":3},{"id":"10767523b30a52aea60431c7511d392f7eb028b7","author":{"_account_id":26970,"name":"Yang Youseok","email":"ileixe@gmail.com","username":"ileixe"},"date":"2020-02-25 08:36:45.000000000","message":"Patch Set 3:\n\nUnfortunately, this patch does not work without additional change. Even nova specify aggregate in the segment RP, placement has no idea to map the segment RP to compute node RP. \n\nI investigated current implementation and histories. At first, I thought IPV4_ADDRESS resource provider which current neutron provide should cover compute node resource provider since logically a segment has several compute nodes. However after reading provider model (https://docs.openstack.org/placement/latest/user/provider-tree.html) more, I found IPV4_ADDRESS resource provider is more like \u0027shared resource\u0027 used by other resource providers, and placement has the feature exactly for that (MISC_SHARES_VIA_AGGREGATE)\n\nSo, I think when Neutron made resource provider (IPV4_ADDRESS), what we need is to add the trait (MISC_SHARES_VIA_AGGREGATE) to the provider, and add aggregate to compute node providers.\n\nI\u0027m not sure it\u0027s right approach though, any advice would be appreciated.","accounts_in_message":[],"_revision_number":3},{"id":"c9c18cf2efe32ad150cfc04e23dd6dd8a3341658","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2020-02-25 12:35:04.000000000","message":"Patch Set 3:\n\nfor the direction of this feature we should ignore this patch entirly.\nnot because its entirly unworkable but this poc was just to show that we could fix this issue not how we should fix this issue.\n\nto make this work correctly neuton should create a sharing resouce provider of ips and a plamcnet aggreate per segment. the ip resouce provider(RP) should have the MISC_SHARES_VIA_AGGREGATE trait as you said and be a member of the network segment aggreate. the network segment aggreate in addtion to the sharing RP should also contain the root RP of each compute node that is connected to the network segment.\nwe should also add a new NETWORK_ROUTED trait to indicate the RP is a sharing resouce provider of routed network inventories.\n\nfor a more holistic view i think we should also be modeling all network backend like this or similar to this. for example idealy all host runing a network backend that is configured for vxlan and is managed by neutron (e.g. has the l2 agent running or is manged via an sdn contoler that is contoled by neutron) should be added to a singel vxlan placement aggreate and a shareing resprovider with an inventory of segmentaion_ids (each segment corresponds to the abiltiy to declare 1 neutron network) and the MISC_SHARES_VIA_AGGREGATE and a new NETWORK_VXLAN trait.\n\nso the poposal would be for each neutron network backend type we map connectivity using one placement aggreate per ${segmenation_type}-${physnet}-${segment} triple\nwith a  sharing RP with inventores of segmentation ids to track the available number of network that can be created.\nthe triple would be used to construct a stable uuid5 to use to identify the aggreate.\n\nin the case of routed network instead of reporting the inventory of segmentation_ids we would report ip adresses. if we create a port with ip_allocation policy\u003ddefer  the port resouce request mechanium will be used to pass a reosuce request for 1 unit of the ip address resouce class and the NETWORK_ROUTED trait but as the ip has not been allcoated no placement aggreate will be passed. if the ip_allocation policy is not set to defer then the port when it is create will be assgined an ip which would need to be claimed temporaly using a new consumer type against the sharing resouce provdier that corresponds to the segment it is allcoated form. this will require the port request feature to be extended so that the allocation can be passed form neutorn to nova,(we proably also want to pass the request for the resouce e.g. the 1 unit of ip adress resouce class, NETWORK_ROUTED trait and segment aggregate) but set a flag to indicate that it is alredy allocated and nova should merge the allocations of the vm with the allocation for the port. when nova is scheduling an instnace with ip allcoation policy imideiate the only data it will incoperate into the placment query with the appoch above it the placement aggreate as a member_of parmanter since there is already an allcation for the ip resouces.\n\nthe new consumer type will allow us to differencate between ip that are claimed by ports that are created and are unbound or port that are attached to the vm. when the port is attached to the vm either via boot or after we would either update the consumer type and consuemr uuid to be the nova and the  vm uuid (the consumer uuid would have to be the project before that its added to a vm). if the port is detached from the vm it woudl revert back.\n\nin the more complete approch above it would work similarly for non routed networks. when a neutorn network is create an allocation for 1 unit of the segmentation_id resouce class will be made against the sharing resouce provider that corresponds to the ${segmenation_type}-${physnet}-${segment} triple with the neutron consumer type. as ip allocation is not used for non routed network the behavior will be the similar to the ip_alloction defer behavior. specificaly neutorn will pass the aggreate corresponding to the triple as part of the port resouce request and nova will incoperate that into its query but it will not pass an ip_address resource request.\n\nin this model the only way a a non routed network will ever have an ip_adress resouce request assocaited with a port is if the port has a floating ip. floating ips will be handeld similarly to routed networks. each floating ip pool will be modeled as a sharing resouce provider with an ip_address inventory and a NETWORK_FLOATING_IP trait.\nwhen the user create a floating ip neuton would consume 1 allcatoion form the the corresponding aggregate RP using the neutron consumer type and setting the consumer uuid to the project.\nwhen the floating ip adress is attach to an unbound port no update to the consumer type is made. when the the port is attached to a vm or the floating ip is added to a port that is already attached to a vm the consumer type will be set to nova and the consumer uuid will be updated to the vm.\n\nthe benifit of this design beyond the fact that it allows use to model capasity of floating ips, routed networks and segmenation ids (per segmenation_type and physnet) is that by doign this though placment we will be able to both schdule on it and use it for quotas when unified limits becomes a reality.\n\nthe poc patch support none of the addtional usecases which should form path of this feature. we should not look at this as support routed netwoking. we should look at this at supporting network aware scheduling and quotas.\n\nthat is why i strongly belive we should not proceed in the direction the poc took and instead should create a pair of sibling specs to capture the design i have porposed above and detail all of the upgrade and other aspects of the changes and perhaps consider this as a cross team priority for the victoria cycle.","accounts_in_message":[],"_revision_number":3},{"id":"41ebcf530f10844a6752d0dc78cf98918d7b40e8","author":{"_account_id":26970,"name":"Yang Youseok","email":"ileixe@gmail.com","username":"ileixe"},"date":"2020-02-26 03:18:07.000000000","message":"Patch Set 3:\n\n@Sean. Wow, that\u0027s far more complex that I thought. I willing to take actions but there were many aspects that I\u0027m unaware of, it\u0027s better to wait others. Thanks.","accounts_in_message":[],"_revision_number":3},{"id":"acb457a7952f11950cbe36f98010fec6909fd71c","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2020-02-26 12:57:12.000000000","message":"Patch Set 3:\n\n\u003e for the direction of this feature we should ignore this patch\n \u003e entirly.\n \u003e not because its entirly unworkable but this poc was just to show\n \u003e that we could fix this issue not how we should fix this issue.\n \u003e \n \u003e to make this work correctly neuton should create a sharing resouce\n \u003e provider of ips and a plamcnet aggreate per segment. the ip resouce\n \u003e provider(RP) should have the MISC_SHARES_VIA_AGGREGATE trait as you\n \u003e said and be a member of the network segment aggreate. the network\n \u003e segment aggreate in addtion to the sharing RP should also contain\n \u003e the root RP of each compute node that is connected to the network\n \u003e segment.\n \u003e we should also add a new NETWORK_ROUTED trait to indicate the RP is\n \u003e a sharing resouce provider of routed network inventories.\n \u003e \n \u003e for a more holistic view i think we should also be modeling all\n \u003e network backend like this or similar to this. for example idealy\n \u003e all host runing a network backend that is configured for vxlan and\n \u003e is managed by neutron (e.g. has the l2 agent running or is manged\n \u003e via an sdn contoler that is contoled by neutron) should be added to\n \u003e a singel vxlan placement aggreate and a shareing resprovider with\n \u003e an inventory of segmentaion_ids (each segment corresponds to the\n \u003e abiltiy to declare 1 neutron network) and the MISC_SHARES_VIA_AGGREGATE\n \u003e and a new NETWORK_VXLAN trait.\n \u003e \n \u003e so the poposal would be for each neutron network backend type we\n \u003e map connectivity using one placement aggreate per ${segmenation_type}-${physnet}-${segment}\n \u003e triple\n \u003e with a  sharing RP with inventores of segmentation ids to track the\n \u003e available number of network that can be created.\n \u003e the triple would be used to construct a stable uuid5 to use to\n \u003e identify the aggreate.\n \u003e \n \u003e in the case of routed network instead of reporting the inventory of\n \u003e segmentation_ids we would report ip adresses. if we create a port\n \u003e with ip_allocation policy\u003ddefer  the port resouce request mechanium\n \u003e will be used to pass a reosuce request for 1 unit of the ip address\n \u003e resouce class and the NETWORK_ROUTED trait but as the ip has not\n \u003e been allcoated no placement aggreate will be passed. if the\n \u003e ip_allocation policy is not set to defer then the port when it is\n \u003e create will be assgined an ip which would need to be claimed\n \u003e temporaly using a new consumer type against the sharing resouce\n \u003e provdier that corresponds to the segment it is allcoated form. this\n \u003e will require the port request feature to be extended so that the\n \u003e allocation can be passed form neutorn to nova,(we proably also want\n \u003e to pass the request for the resouce e.g. the 1 unit of ip adress\n \u003e resouce class, NETWORK_ROUTED trait and segment aggregate) but set\n \u003e a flag to indicate that it is alredy allocated and nova should\n \u003e merge the allocations of the vm with the allocation for the port.\n \u003e when nova is scheduling an instnace with ip allcoation policy\n \u003e imideiate the only data it will incoperate into the placment query\n \u003e with the appoch above it the placement aggreate as a member_of\n \u003e parmanter since there is already an allcation for the ip resouces.\n \u003e \n \u003e the new consumer type will allow us to differencate between ip that\n \u003e are claimed by ports that are created and are unbound or port that\n \u003e are attached to the vm. when the port is attached to the vm either\n \u003e via boot or after we would either update the consumer type and\n \u003e consuemr uuid to be the nova and the  vm uuid (the consumer uuid\n \u003e would have to be the project before that its added to a vm). if the\n \u003e port is detached from the vm it woudl revert back.\n \u003e \n \u003e in the more complete approch above it would work similarly for non\n \u003e routed networks. when a neutorn network is create an allocation for\n \u003e 1 unit of the segmentation_id resouce class will be made against\n \u003e the sharing resouce provider that corresponds to the\n \u003e ${segmenation_type}-${physnet}-${segment} triple with the neutron\n \u003e consumer type. as ip allocation is not used for non routed network\n \u003e the behavior will be the similar to the ip_alloction defer\n \u003e behavior. specificaly neutorn will pass the aggreate corresponding\n \u003e to the triple as part of the port resouce request and nova will\n \u003e incoperate that into its query but it will not pass an ip_address\n \u003e resource request.\n \u003e \n \u003e in this model the only way a a non routed network will ever have an\n \u003e ip_adress resouce request assocaited with a port is if the port has\n \u003e a floating ip. floating ips will be handeld similarly to routed\n \u003e networks. each floating ip pool will be modeled as a sharing\n \u003e resouce provider with an ip_address inventory and a\n \u003e NETWORK_FLOATING_IP trait.\n \u003e when the user create a floating ip neuton would consume 1\n \u003e allcatoion form the the corresponding aggregate RP using the\n \u003e neutron consumer type and setting the consumer uuid to the project.\n \u003e when the floating ip adress is attach to an unbound port no update\n \u003e to the consumer type is made. when the the port is attached to a vm\n \u003e or the floating ip is added to a port that is already attached to a\n \u003e vm the consumer type will be set to nova and the consumer uuid will\n \u003e be updated to the vm.\n \u003e \n \u003e the benifit of this design beyond the fact that it allows use to\n \u003e model capasity of floating ips, routed networks and segmenation ids\n \u003e (per segmenation_type and physnet) is that by doign this though\n \u003e placment we will be able to both schdule on it and use it for\n \u003e quotas when unified limits becomes a reality.\n \u003e \n \u003e the poc patch support none of the addtional usecases which should\n \u003e form path of this feature. we should not look at this as support\n \u003e routed netwoking. we should look at this at supporting network\n \u003e aware scheduling and quotas.\n \u003e \n \u003e that is why i strongly belive we should not proceed in the\n \u003e direction the poc took and instead should create a pair of sibling\n \u003e specs to capture the design i have porposed above and detail all of\n \u003e the upgrade and other aspects of the changes and perhaps consider\n \u003e this as a cross team priority for the victoria cycle.\n\nA continuation of the discussion happened today on IRC. Here is my summary on the ML http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012846.html","accounts_in_message":[],"_revision_number":3},{"id":"3ab34addc30a152776319225af1b4ec661dd998a","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2020-02-26 13:48:05.000000000","message":"Restored\n\nI have the intention to continue this","accounts_in_message":[],"_revision_number":3},{"id":"c44676b75ebaa4fbb55124615b7fda93ff47bb1f","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2020-02-26 13:48:25.000000000","message":"Patch Set 3:\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":3},{"id":"8f8950484f5752e51451326a7424e2b60a9a3f50","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-02-26 13:48:32.000000000","message":"Patch Set 3: Verified-1\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":3},{"id":"de78b7df873709aaf711c8a1e81011e718b79823","author":{"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},"date":"2020-02-26 13:48:42.000000000","message":"Patch Set 3:\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":3},{"id":"ffb9f4d9e87d44565e9ab4e00680a3a11a974b5b","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2020-02-26 13:49:06.000000000","message":"Patch Set 3:\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":3},{"id":"a2a76905087ca132039e01329a7c488d86dc1284","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2020-02-26 13:54:48.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"f53fa2238795d4eaa4f95b2667f34eeec8f23173","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2020-02-26 13:55:11.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":"296f1494750f082bfc01593e23e73a096404937a","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2020-02-26 13:56:02.000000000","message":"Patch Set 4:\n\n(1 comment)\n\nrebased and adapted to use request_level_params in RequestSpec instead of a new field","accounts_in_message":[],"_revision_number":4},{"id":"37faaaef99bfbab0ce630ee321f40ab483124429","author":{"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},"date":"2020-02-26 14:19:59.000000000","message":"Patch Set 4:\n\nBuild failed.\n\n- pmem-tempest-plugin-filtered http://52.27.155.124/85/656885/4/check/pmem-tempest-plugin-filtered/57afe5d/ : FAILURE in 23m 57s","accounts_in_message":[],"_revision_number":4},{"id":"24f1839aa41caee35a2474dbe2b6693630b14a2f","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2020-02-26 15:02:48.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-41243 : FAILURE in 1h 06m 06s","accounts_in_message":[],"_revision_number":4},{"id":"59fdeb69e742078504d7c2128761a23a3af8b8ab","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-02-26 15:22:41.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- grenade-py3 https://zuul.opendev.org/t/openstack/build/33a6f734470d40b3b266f665f15f21dd : FAILURE in 1h 08m 27s\n- tempest-integrated-compute https://zuul.opendev.org/t/openstack/build/1585efbebd414a5083c59822684e5f1d : FAILURE in 50m 56s\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/33b539d16e804661b2227a9b4c68a2b7 : FAILURE in 19m 57s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/80aedaa9c13b4142ba0124a79594c1e9 : FAILURE in 17m 28s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/4601cf9c3ddb428fbf0c1b7d020285ec : SUCCESS in 9m 42s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/1128554d3e84489b9b9d5c637217d54d : FAILURE in 15m 27s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/b26ebb61e58d460ab179133ca2a4154c : FAILURE in 15m 55s\n- openstack-tox-py38 https://zuul.opendev.org/t/openstack/build/fb79f5b398c74849a39837fcb67e117c : FAILURE in 15m 06s (non-voting)\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/fdd52618a5bb4fb78027b5bee818e508 : SUCCESS in 12m 21s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa https://zuul.opendev.org/t/openstack/build/e130b3939d5c48f7a0d85207d58f8739 : FAILURE in 52m 45s (non-voting)\n- devstack-plugin-ceph-tempest-py3 https://zuul.opendev.org/t/openstack/build/a98fe9fe26bb48fc85f61bc275b96d52 : FAILURE in 44m 36s (non-voting)\n- neutron-tempest-linuxbridge https://zuul.opendev.org/t/openstack/build/ee4ca99f5db44f07a797a02d6106c23e : FAILURE in 41m 49s\n- nova-grenade-multinode https://zuul.opendev.org/t/openstack/build/cc5be503974e44fab1618f4edaa6459e : FAILURE in 1h 19m 27s\n- nova-live-migration https://zuul.opendev.org/t/openstack/build/d14f4e9169674a64ac960b3654abf37d : FAILURE in 50m 01s\n- nova-multi-cell https://zuul.opendev.org/t/openstack/build/4066d5982e9a4b64b79d5b519787f7d9 : FAILURE in 1h 05m 05s\n- nova-next https://zuul.opendev.org/t/openstack/build/35e6a0c4be0a42aaa8475cd373b0e4a0 : POST_FAILURE in 1h 09m 09s\n- nova-tox-functional-py36 https://zuul.opendev.org/t/openstack/build/064fe392ea3949cba9a23ed0ed611a43 : FAILURE in 23m 14s\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/ac53c5586e4a40e98624ba267078aae2 : FAILURE in 44m 26s","accounts_in_message":[],"_revision_number":4},{"id":"e1badc8c1d7fc0815a753d2ab88a8784a9ef8300","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2020-02-26 15:48:35.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/656885/4 : FAILURE in 1h 52m 58s","accounts_in_message":[],"_revision_number":4},{"id":"b50f0412e496211540bf5384de649a062fb837cb","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2020-02-26 17:12:56.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-bionic finger://zuul-v3-executor.novalocal/5aeeeda658c24c9582fc482085691bb8 : POST_FAILURE in 1h 33m 25s\n- tempest-dsvm-full-bionic-py3 https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/4/check/tempest-dsvm-full-bionic-py3/e895e91/ : FAILURE in 1h 33m 08s\n- grenade-dsvm-bionic finger://zuul-v3-executor.novalocal/058c43f3d79d454cb97a7362ffb1e8f7 : POST_FAILURE in 2h 53m 30s (non-voting)","accounts_in_message":[],"_revision_number":4},{"id":"2ecf4726a547f3741d3aa891559faee0e8ab1a37","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2020-03-02 16:58:58.000000000","message":"Uploaded patch set 5.","accounts_in_message":[],"_revision_number":5},{"id":"7d8e41317f69b945b9de97ed3cd01c993011bc67","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2020-03-02 17:15:30.000000000","message":"Patch Set 5:\n\nTesting failed ubuntu-bionic-s390x. For rechecking only on the ubuntu-bionic-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-bionic-s390x http://extbasicopstackcilog01.podc.sl.edst.ibm.com/zkvm_test_logs/production/656885/5/check-tempest-dsvm-neutron-full-ubuntu-bionic-s390x/298a4e2 : FAILURE in 16m 04s","accounts_in_message":[],"_revision_number":5},{"id":"6fc71239e364deb8206639e52ac69badc92ed88d","author":{"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},"date":"2020-03-02 17:23:17.000000000","message":"Patch Set 5:\n\nBuild SUCCESSFUL (check pipeline).\n\n- pmem-tempest-plugin-filtered http://52.27.155.124/85/656885/5/check/pmem-tempest-plugin-filtered/1d85630/ : SUCCESS in 23m 01s","accounts_in_message":[],"_revision_number":5},{"id":"3ab4418e3c5de22dcf97fc22337ce6e9677e4f64","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2020-03-02 18:57:05.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-41358 : SUCCESS in 1h 47m 33s","accounts_in_message":[],"_revision_number":5},{"id":"ae5f9286eb6e1b9592c62a831f6f541ea9b0ee2c","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2020-03-02 22:15:26.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-bionic https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/5/check/tempest-dsvm-full-bionic/e8dfc09/ : FAILURE in 9m 44s\n- tempest-dsvm-full-bionic-py3 https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/5/check/tempest-dsvm-full-bionic-py3/c1bfdd9/ : FAILURE in 8m 42s\n- grenade-dsvm-bionic https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/5/check/grenade-dsvm-bionic/98bc6ca/ : SUCCESS in 3h 05m 11s (non-voting)","accounts_in_message":[],"_revision_number":5},{"id":"832bc46e1e0cbf3423bd73c54240f47f360ddaf9","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-03-02 22:35:55.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- grenade-py3 https://zuul.opendev.org/t/openstack/build/ab4edc51861a470496d435861524df85 : SUCCESS in 1h 05m 03s\n- tempest-integrated-compute https://zuul.opendev.org/t/openstack/build/61fbfe38038e4e1f853f11a8172c57d6 : SUCCESS in 1h 24m 54s\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/00e26528375b4b9fa85d3213bef4c8df : SUCCESS in 19m 06s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/8e45b3ab996141baab6b97644506bcce : FAILURE in 15m 50s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/951151252d224f81914c7313ac887428 : SUCCESS in 10m 14s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/85d3367915aa49a1ba470562d1c5401a : SUCCESS in 22m 17s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/66abbdce1cd042faacfe2c44dc2836fc : SUCCESS in 15m 37s\n- openstack-tox-py38 https://zuul.opendev.org/t/openstack/build/03d5487ae63b4d8188d5204d15273d89 : SUCCESS in 14m 46s (non-voting)\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/cbc8797532df40be8c77071dad787dd7 : SUCCESS in 13m 51s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa https://zuul.opendev.org/t/openstack/build/9997d09009274a778d8270179f05352c : SUCCESS in 56m 44s (non-voting)\n- devstack-plugin-ceph-tempest-py3 https://zuul.opendev.org/t/openstack/build/a15f90b7caa740519af00074d84dcd71 : SUCCESS in 1h 15m 48s (non-voting)\n- neutron-tempest-linuxbridge https://zuul.opendev.org/t/openstack/build/23216fa6368d4232b8744d7f7e296ba1 : FAILURE in 57m 16s\n- nova-grenade-multinode https://zuul.opendev.org/t/openstack/build/28c7712bf61b4db6aeffe2c728b32adc : SUCCESS in 1h 26m 19s\n- nova-live-migration https://zuul.opendev.org/t/openstack/build/e2ac1f6edf4b44d5be8d902dd4f8f349 : SUCCESS in 1h 01m 22s\n- nova-multi-cell https://zuul.opendev.org/t/openstack/build/d0feff3926c440da9b454512d4d815b0 : SUCCESS in 1h 35m 25s\n- nova-next https://zuul.opendev.org/t/openstack/build/9f85a748c5ab495fac1c91277ebd466c : SUCCESS in 2h 03m 37s\n- nova-tox-functional-py36 https://zuul.opendev.org/t/openstack/build/d1d4c52a690d460b9764dce1449f2bb3 : FAILURE in 17m 59s\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/f34239d7f09a4a48a73aed1578085c41 : SUCCESS in 1h 16m 08s","accounts_in_message":[],"_revision_number":5},{"id":"f19c5228a6f02107363564ea7a54973b602d5874","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2020-03-02 23:31:43.000000000","message":"Patch Set 5:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/656885/5 : SUCCESS in 2h 40m 38s","accounts_in_message":[],"_revision_number":5},{"id":"b9ddffa7ca0587b0e16fda4e9d58be87d0998e4a","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2020-03-03 13:09:25.000000000","message":"Uploaded patch set 6.","accounts_in_message":[],"_revision_number":6},{"id":"67328481126c12705bf89d613c35cfd9e2ca87de","author":{"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},"date":"2020-03-03 13:33:37.000000000","message":"Patch Set 6:\n\nBuild SUCCESSFUL (check pipeline).\n\n- pmem-tempest-plugin-filtered http://52.27.155.124/85/656885/6/check/pmem-tempest-plugin-filtered/d12af0f/ : SUCCESS in 23m 04s","accounts_in_message":[],"_revision_number":6},{"id":"9744d6015dc91f5b894e1998248e9143c74c2b5e","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2020-03-03 14:15:13.000000000","message":"Patch Set 6:\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-41400 : SUCCESS in 1h 05m 16s","accounts_in_message":[],"_revision_number":6},{"id":"509d0093f9163a55fb0dacf724fb1458f556597f","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2020-03-03 15:37:09.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/656885/6 : FAILURE in 2h 26m 46s","accounts_in_message":[],"_revision_number":6},{"id":"b6b0abba4f2db9b072cce33e11a8b9cccc6cd47a","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2020-03-03 16:27:38.000000000","message":"Patch Set 6:\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-bionic https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/6/check/tempest-dsvm-full-bionic/f246ea5/ : SUCCESS in 1h 38m 48s\n- tempest-dsvm-full-bionic-py3 https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/6/check/tempest-dsvm-full-bionic-py3/092766b/ : SUCCESS in 1h 59m 04s\n- grenade-dsvm-bionic https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/6/check/grenade-dsvm-bionic/5ef48f1/ : POST_FAILURE in 3h 08m 52s (non-voting)","accounts_in_message":[],"_revision_number":6},{"id":"07b800bdacda0af2bdea3fa45b7eac2f05d65b19","author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"date":"2020-03-03 17:36:59.000000000","message":"Uploaded patch set 7.","accounts_in_message":[],"_revision_number":7},{"id":"be7cdee15753b0888036fd43130f361a11d18ca0","author":{"_account_id":29963,"name":"Intel_Zuul","display_name":"Intel Corporation CI","email":"intel-openstack-ci@intel.com","username":"Intel_Zuul"},"date":"2020-03-03 18:02:13.000000000","message":"Patch Set 7:\n\nBuild SUCCESSFUL (check pipeline).\n\n- pmem-tempest-plugin-filtered http://52.27.155.124/85/656885/7/check/pmem-tempest-plugin-filtered/3063fc1/ : SUCCESS in 23m 26s","accounts_in_message":[],"_revision_number":7},{"id":"f5dbdec0cc67be0be6d32f161aaf8c3a4fc6cf69","author":{"_account_id":23498,"name":"IBM zVM CI","email":"zvmosci@us.ibm.com","username":"zvmosci"},"date":"2020-03-03 19:04:26.000000000","message":"Patch Set 7:\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-41414 : SUCCESS in 1h 26m 54s","accounts_in_message":[],"_revision_number":7},{"id":"6e86ec54663f22156677b3b93bd8ab7179ff4e84","author":{"_account_id":26515,"name":"Cloudbase Nova Hyper-V CI","email":"nova_hyperv_ci@cloudbasesolutions.com","username":"nova_hyperv_ci"},"date":"2020-03-03 20:00:04.000000000","message":"Patch Set 7:\n\nBuild succeeded.\n\n- nova http://cloudbase-ci.com/nova/656885/7 : SUCCESS in 2h 22m 09s","accounts_in_message":[],"_revision_number":7},{"id":"6959fcc9703d6b36af4ad3fbe9e7ea8d0ed35e47","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2020-03-03 21:33:28.000000000","message":"Patch Set 7:\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-bionic https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/7/check/tempest-dsvm-full-bionic/13ffe19/ : SUCCESS in 1h 41m 26s\n- tempest-dsvm-full-bionic-py3 https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/7/check/tempest-dsvm-full-bionic-py3/de2e2f9/ : SUCCESS in 1h 31m 13s\n- grenade-dsvm-bionic https://oplab9.parqtec.unicamp.br/pub/ppc64el/openstack/nova/85/656885/7/check/grenade-dsvm-bionic/eaa32f1/ : SUCCESS in 3h 18m 16s (non-voting)","accounts_in_message":[],"_revision_number":7},{"id":"a5d846b5d1b5b3581286dfb80604f7016c5cdb7b","tag":"autogenerated:zuul:check","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2020-03-04 01:09:31.000000000","message":"Patch Set 7: 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 https://zuul.opendev.org/t/openstack/build/7ade88fbfa3c4d8686442d1553cc8584 : SUCCESS in 55m 46s\n- tempest-integrated-compute https://zuul.opendev.org/t/openstack/build/0f806571c3d344b5acacfdc9cf692200 : SUCCESS in 1h 40m 51s\n- openstack-tox-cover https://zuul.opendev.org/t/openstack/build/ebb0b6e320c043af8a90e9622c16c840 : SUCCESS in 20m 54s\n- openstack-tox-lower-constraints https://zuul.opendev.org/t/openstack/build/510fcc1258c74df69e485644d7e62a30 : FAILURE in 16m 17s\n- openstack-tox-pep8 https://zuul.opendev.org/t/openstack/build/1572cce0b09b444d99d1328fcf298945 : SUCCESS in 7m 23s\n- openstack-tox-py36 https://zuul.opendev.org/t/openstack/build/8f939fc36c6a432fb2243dd1f34f1348 : SUCCESS in 12m 57s\n- openstack-tox-py37 https://zuul.opendev.org/t/openstack/build/829b782726a441ada8a64cd29fef0e80 : SUCCESS in 13m 30s\n- openstack-tox-py38 https://zuul.opendev.org/t/openstack/build/77e73e14413a4288a073a1cd25c6556b : FAILURE in 9m 53s (non-voting)\n- openstack-tox-docs https://zuul.opendev.org/t/openstack/build/33d517ea68d346a99c29ade443a58945 : SUCCESS in 10m 56s\n- ironic-tempest-ipa-wholedisk-bios-agent_ipmitool-tinyipa https://zuul.opendev.org/t/openstack/build/2bcf0967aae24db39b03f24e60760320 : SUCCESS in 59m 59s (non-voting)\n- devstack-plugin-ceph-tempest-py3 https://zuul.opendev.org/t/openstack/build/5ca8f7dba56a4ea18be85810190277f0 : SUCCESS in 57m 36s (non-voting)\n- neutron-tempest-linuxbridge https://zuul.opendev.org/t/openstack/build/e5ea747f52424830bdde02383e26b334 : SUCCESS in 1h 18m 09s\n- nova-grenade-multinode https://zuul.opendev.org/t/openstack/build/59b4b2968c734930b4b2c6c73b03e281 : FAILURE in 1h 20m 46s\n- nova-live-migration https://zuul.opendev.org/t/openstack/build/fe4fc6d702dd485f97c095912d5894e6 : SUCCESS in 52m 49s\n- nova-multi-cell https://zuul.opendev.org/t/openstack/build/eacc30b4df944594a9b02c3fab71da56 : SUCCESS in 1h 38m 41s\n- nova-next https://zuul.opendev.org/t/openstack/build/2b7dad9fa3ad4b059987749d86df8807 : SUCCESS in 1h 35m 05s\n- nova-tox-functional-py36 https://zuul.opendev.org/t/openstack/build/fa3c4a3e4adf4860966d49151fd97d20 : SUCCESS in 16m 35s\n- tempest-ipv6-only https://zuul.opendev.org/t/openstack/build/ff4605c13f0c4655b29a79725990f1be : SUCCESS in 1h 09m 59s","accounts_in_message":[],"_revision_number":7},{"id":"ed0be5f1dc3a6147d17c844630efafecdcf31cc6","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2020-03-04 09:33:59.000000000","message":"Patch Set 7:\n\nTesting failed ubuntu-bionic-s390x. For rechecking only on the ubuntu-bionic-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-bionic-s390x http://extbasicopstackcilog01.podc.sl.edst.ibm.com/zkvm_test_logs/production/656885/7/check-tempest-dsvm-neutron-full-ubuntu-bionic-s390x/b30edb0 : FAILURE in 1h 24m 59s","accounts_in_message":[],"_revision_number":7},{"id":"40f29a2ac45845be18c12820aae6c5f7fe5d15ac","author":{"_account_id":14595,"name":"z Systems KVM","email":"zkvm-ci@linux.vnet.ibm.com","username":"ibm-zkvm-ci","tags":["SERVICE_USER"]},"date":"2020-04-13 07:57:49.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":"d229526a39251bff17d76939019fe6ab0eb9b91f","author":{"_account_id":9452,"name":"James Penick","email":"penick@verizonmedia.com","username":"epim"},"date":"2020-07-15 21:36:42.000000000","message":"Patch Set 7:\n\nJust throwing this out there from an operators perspective: This is something we need in our environment. \n\nWe have cases where our users want to create a public IPv4 port, boot an instance with it, then delete that instance and boot a new one with the same port. The reason is that some platform teams need to establish IP trust with external partners (like DNS, SMTP, or other externally whitelisted things). And so they need to keep that ipv4 address handy. Our networks are an L3 topology, so making sure that the newly created instance comes up in the same rack as that public IPs subnet is something that would be very valuable to us.","accounts_in_message":[],"_revision_number":7},{"id":"086b0cf7e042101b3abdf8209e86dcd26c6a14e8","author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"date":"2020-07-16 07:46:26.000000000","message":"Patch Set 7:\n\n\u003e Just throwing this out there from an operators perspective: This is\n \u003e something we need in our environment.\n \u003e \n \u003e We have cases where our users want to create a public IPv4 port,\n \u003e boot an instance with it, then delete that instance and boot a new\n \u003e one with the same port. The reason is that some platform teams need\n \u003e to establish IP trust with external partners (like DNS, SMTP, or\n \u003e other externally whitelisted things). And so they need to keep that\n \u003e ipv4 address handy. Our networks are an L3 topology, so making sure\n \u003e that the newly created instance comes up in the same rack as that\n \u003e public IPs subnet is something that would be very valuable to us.\n\nHi, there is a spec that aims to make this working: https://review.opendev.org/733703","accounts_in_message":[],"_revision_number":7},{"id":"aa56c1048731d9b2e2c481a41e198c340202ecb8","tag":"autogenerated:gerrit:abandon","author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"date":"2021-03-08 18:54:08.000000000","message":"Abandoned","accounts_in_message":[],"_revision_number":7}],"current_revision_number":7,"current_revision":"7f434375240dbc373192af65f7fd84dd9ab5e6c0","revisions":{"f1abf6306c4008e46f215839a0031920fbba8630":{"kind":"REWORK","_number":1,"created":"2019-05-02 22:13:06.000000000","uploader":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"ref":"refs/changes/85/656885/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/85/656885/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/85/656885/1"}}},"commit":{"parents":[{"commit":"11de108daaab4a70e11f13c8adca3f5926aeb540","subject":"Merge \"Pass target host to RequestGroup.in_tree\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/11de108daaab4a70e11f13c8adca3f5926aeb540"}]}],"author":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:09:00.000000000","tz":-240},"committer":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:09:00.000000000","tz":-240},"subject":"WIP: Hey let\u0027s support routed networks y\u0027all!","message":"WIP: Hey let\u0027s support routed networks y\u0027all!\n\nBased on jroll bringing this up again [1] and the\nneutron docs [2] I tried hacking something together.\n\nPer my reading of the docs, each segment is a resource\nprovider in placement and neutron creates a resource\nprovider aggregate for the segments in the same network\nand a mirrored nova host aggregate for the placement\naggregate (using the same aggregate uuid).\n\nThis tries to translate that into taking the requested\nnetworks during server create (via the request network\nid or port id), get the segment IDs per requested network,\nand then for each segment get their aggregates (maybe\nthe segments in the same network are all in the same\nresource provider aggregate, I\u0027m not sure).\n\nOnce we have all that crap, shove it in the request spec\nand translate it to required provider aggregates in the\nscheduler during GET /allocation_candidates.\n\nMISSION ACCOMPLISHED!\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-05-02.log.html#t2019-05-02T19:56:34\n[2] https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html\n\nChange-Id: Ic5fadd69722b430c07739eb37295eedcd2621f35\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/f1abf6306c4008e46f215839a0031920fbba8630"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/f1abf6306c4008e46f215839a0031920fbba8630"}]},"branch":"refs/heads/master"},"dadce377e504c2a9e61f378fa413b03c247cd7bb":{"kind":"REWORK","_number":2,"created":"2019-05-02 22:35:57.000000000","uploader":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"ref":"refs/changes/85/656885/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/85/656885/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/85/656885/2"}}},"commit":{"parents":[{"commit":"11de108daaab4a70e11f13c8adca3f5926aeb540","subject":"Merge \"Pass target host to RequestGroup.in_tree\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/11de108daaab4a70e11f13c8adca3f5926aeb540"}]}],"author":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:09:00.000000000","tz":-240},"committer":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:34:45.000000000","tz":-240},"subject":"WIP: Hey let\u0027s support routed networks y\u0027all!","message":"WIP: Hey let\u0027s support routed networks y\u0027all!\n\nBased on jroll bringing this up again [1] and the\nneutron docs [2] I tried hacking something together.\n\nPer my reading of the docs, each segment is a resource\nprovider in placement and neutron creates a resource\nprovider aggregate for the segments in the same network\nand a mirrored nova host aggregate for the placement\naggregate (using the same aggregate uuid).\n\nThis tries to translate that into taking the requested\nnetworks during server create (via the request network\nid or port id), get the segment IDs per requested network,\nand then for each segment get their aggregates (maybe\nthe segments in the same network are all in the same\nresource provider aggregate, I\u0027m not sure).\n\nOnce we have all that crap, shove it in the request spec\nand translate it to required provider aggregates in the\nscheduler during GET /allocation_candidates.\n\nObviously needs testing, documentation, things like\nmove operations don\u0027t work (would need to recalculate\nthe routed network segment aggregates on each pass\nthrough the scheduler since you could attach/detach\nports in between server create and migrate).\n\nMISSION ACCOMPLISHED!\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-05-02.log.html#t2019-05-02T19:56:34\n[2] https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html\n\nChange-Id: Ic5fadd69722b430c07739eb37295eedcd2621f35\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/dadce377e504c2a9e61f378fa413b03c247cd7bb"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/dadce377e504c2a9e61f378fa413b03c247cd7bb"}]},"branch":"refs/heads/master"},"06a12809da7bcb99d8f494fb3ee982cd4fe0e526":{"kind":"REWORK","_number":3,"created":"2019-05-02 22:40:14.000000000","uploader":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"ref":"refs/changes/85/656885/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/85/656885/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/85/656885/3"}}},"commit":{"parents":[{"commit":"11de108daaab4a70e11f13c8adca3f5926aeb540","subject":"Merge \"Pass target host to RequestGroup.in_tree\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/11de108daaab4a70e11f13c8adca3f5926aeb540"}]}],"author":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:09:00.000000000","tz":-240},"committer":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:40:10.000000000","tz":-240},"subject":"WIP: Hey let\u0027s support routed networks y\u0027all!","message":"WIP: Hey let\u0027s support routed networks y\u0027all!\n\nBased on jroll bringing this up again [1] and the\nneutron docs [2] I tried hacking something together.\n\nPer my reading of the docs, each segment is a resource\nprovider in placement and neutron creates a resource\nprovider aggregate for the segments in the same network\nand a mirrored nova host aggregate for the placement\naggregate (using the same aggregate uuid).\n\nThis tries to translate that into taking the requested\nnetworks during server create (via the request network\nid or port id), get the segment IDs per requested network,\nand then for each segment get their aggregates (maybe\nthe segments in the same network are all in the same\nresource provider aggregate, I\u0027m not sure).\n\nOnce we have all that crap, shove it in the request spec\nand translate it to required provider aggregates in the\nscheduler during GET /allocation_candidates.\n\nObviously needs testing, documentation, things like\nmove operations don\u0027t work (would need to recalculate\nthe routed network segment aggregates on each pass\nthrough the scheduler since you could attach/detach\nports in between server create and migrate).\n\nMISSION ACCOMPLISHED!\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-05-02.log.html#t2019-05-02T19:56:34\n[2] https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html\n\nChange-Id: Ic5fadd69722b430c07739eb37295eedcd2621f35\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/06a12809da7bcb99d8f494fb3ee982cd4fe0e526"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/06a12809da7bcb99d8f494fb3ee982cd4fe0e526"}]},"branch":"refs/heads/master"},"2e3abe38af41a285f4495b2d2e64f4339f06c5ba":{"kind":"REWORK","_number":4,"created":"2020-02-26 13:54:48.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/85/656885/4","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/85/656885/4","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/85/656885/4"}}},"commit":{"parents":[{"commit":"a83d853610b1d9c57bb6c672cc20b07db189cc10","subject":"Merge \"Use reasonable name for provider mapping\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a83d853610b1d9c57bb6c672cc20b07db189cc10"}]}],"author":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:09:00.000000000","tz":-240},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@est.tech","date":"2020-02-26 13:52:58.000000000","tz":60},"subject":"WIP: Hey let\u0027s support routed networks y\u0027all!","message":"WIP: Hey let\u0027s support routed networks y\u0027all!\n\nBased on jroll bringing this up again [1] and the\nneutron docs [2] I tried hacking something together.\n\nPer my reading of the docs, each segment is a resource\nprovider in placement and neutron creates a resource\nprovider aggregate for the segments in the same network\nand a mirrored nova host aggregate for the placement\naggregate (using the same aggregate uuid).\n\nThis tries to translate that into taking the requested\nnetworks during server create (via the request network\nid or port id), get the segment IDs per requested network,\nand then for each segment get their aggregates (maybe\nthe segments in the same network are all in the same\nresource provider aggregate, I\u0027m not sure).\n\nOnce we have all that crap, shove it in the request spec\nand translate it to required provider aggregates in the\nscheduler during GET /allocation_candidates.\n\nObviously needs testing, documentation, things like\nmove operations don\u0027t work (would need to recalculate\nthe routed network segment aggregates on each pass\nthrough the scheduler since you could attach/detach\nports in between server create and migrate).\n\nMISSION ACCOMPLISHED!\n\nTODO:\n* test coverage both unit and functional\n* documentation\n* update request_spec during move ops\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-05-02.log.html#t2019-05-02T19:56:34\n[2] https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html\n\nChange-Id: Ic5fadd69722b430c07739eb37295eedcd2621f35\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/2e3abe38af41a285f4495b2d2e64f4339f06c5ba"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/2e3abe38af41a285f4495b2d2e64f4339f06c5ba"}]},"branch":"refs/heads/master"},"936c4e51d433407aa58f197689d3dc7f40293f39":{"kind":"REWORK","_number":5,"created":"2020-03-02 16:58:58.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/85/656885/5","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/85/656885/5","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/85/656885/5"}}},"commit":{"parents":[{"commit":"a83d853610b1d9c57bb6c672cc20b07db189cc10","subject":"Merge \"Use reasonable name for provider mapping\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a83d853610b1d9c57bb6c672cc20b07db189cc10"}]}],"author":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:09:00.000000000","tz":-240},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@est.tech","date":"2020-03-02 16:55:45.000000000","tz":60},"subject":"WIP: Hey let\u0027s support routed networks y\u0027all!","message":"WIP: Hey let\u0027s support routed networks y\u0027all!\n\nBased on jroll bringing this up again [1] and the\nneutron docs [2] I tried hacking something together.\n\nPer my reading of the docs, each segment is a resource\nprovider in placement and neutron creates a resource\nprovider aggregate for the segments in the same network\nand a mirrored nova host aggregate for the placement\naggregate (using the same aggregate uuid).\n\nThis tries to translate that into taking the requested\nnetworks during server create (via the request network\nid or port id), get the segment IDs per requested network,\nand then for each segment get their aggregates (maybe\nthe segments in the same network are all in the same\nresource provider aggregate, I\u0027m not sure).\n\nOnce we have all that crap, shove it in the request spec\nand translate it to required provider aggregates in the\nscheduler during GET /allocation_candidates.\n\nObviously needs testing, documentation, things like\nmove operations don\u0027t work (would need to recalculate\nthe routed network segment aggregates on each pass\nthrough the scheduler since you could attach/detach\nports in between server create and migrate).\n\nMISSION ACCOMPLISHED!\n\nTODO:\n* test coverage both unit and functional\n* documentation\n* update request_spec during move ops\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-05-02.log.html#t2019-05-02T19:56:34\n[2] https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html\n\nChange-Id: Ic5fadd69722b430c07739eb37295eedcd2621f35\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/936c4e51d433407aa58f197689d3dc7f40293f39"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/936c4e51d433407aa58f197689d3dc7f40293f39"}]},"branch":"refs/heads/master"},"f33a49bf6b8c55eb762504bbb0990fde5a10c0c0":{"kind":"REWORK","_number":6,"created":"2020-03-03 13:09:25.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/85/656885/6","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/85/656885/6","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/85/656885/6"}}},"commit":{"parents":[{"commit":"a83d853610b1d9c57bb6c672cc20b07db189cc10","subject":"Merge \"Use reasonable name for provider mapping\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a83d853610b1d9c57bb6c672cc20b07db189cc10"}]}],"author":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:09:00.000000000","tz":-240},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@est.tech","date":"2020-03-03 13:05:04.000000000","tz":60},"subject":"WIP: Hey let\u0027s support routed networks y\u0027all!","message":"WIP: Hey let\u0027s support routed networks y\u0027all!\n\nBased on jroll bringing this up again [1] and the\nneutron docs [2] I tried hacking something together.\n\nPer my reading of the docs, each segment is a resource\nprovider in placement and neutron creates a resource\nprovider aggregate for the segments in the same network\nand a mirrored nova host aggregate for the placement\naggregate (using the same aggregate uuid).\n\nThis tries to translate that into taking the requested\nnetworks during server create (via the request network\nid or port id), get the segment IDs per requested network,\nand then for each segment get their aggregates (maybe\nthe segments in the same network are all in the same\nresource provider aggregate, I\u0027m not sure).\n\nOnce we have all that crap, shove it in the request spec\nand translate it to required provider aggregates in the\nscheduler during GET /allocation_candidates.\n\nObviously needs testing, documentation, things like\nmove operations don\u0027t work (would need to recalculate\nthe routed network segment aggregates on each pass\nthrough the scheduler since you could attach/detach\nports in between server create and migrate).\n\nMISSION ACCOMPLISHED!\n\nTODO:\n* test coverage both unit and functional\n* documentation\n* update request_spec during move ops\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-05-02.log.html#t2019-05-02T19:56:34\n[2] https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html\n\nChange-Id: Ic5fadd69722b430c07739eb37295eedcd2621f35\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/f33a49bf6b8c55eb762504bbb0990fde5a10c0c0"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/f33a49bf6b8c55eb762504bbb0990fde5a10c0c0"}]},"branch":"refs/heads/master"},"7f434375240dbc373192af65f7fd84dd9ab5e6c0":{"kind":"REWORK","_number":7,"created":"2020-03-03 17:36:59.000000000","uploader":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"ref":"refs/changes/85/656885/7","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova","ref":"refs/changes/85/656885/7","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova refs/changes/85/656885/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova refs/changes/85/656885/7"}}},"commit":{"parents":[{"commit":"a83d853610b1d9c57bb6c672cc20b07db189cc10","subject":"Merge \"Use reasonable name for provider mapping\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/a83d853610b1d9c57bb6c672cc20b07db189cc10"}]}],"author":{"name":"Matt Riedemann","email":"mriedem.os@gmail.com","date":"2019-05-02 22:09:00.000000000","tz":-240},"committer":{"name":"Balazs Gibizer","email":"balazs.gibizer@est.tech","date":"2020-03-03 17:28:03.000000000","tz":60},"subject":"WIP: Hey let\u0027s support routed networks y\u0027all!","message":"WIP: Hey let\u0027s support routed networks y\u0027all!\n\nBased on jroll bringing this up again [1] and the\nneutron docs [2] I tried hacking something together.\n\nPer my reading of the docs, each segment is a resource\nprovider in placement and neutron creates a resource\nprovider aggregate for the segments in the same network\nand a mirrored nova host aggregate for the placement\naggregate (using the same aggregate uuid).\n\nThis tries to translate that into taking the requested\nnetworks during server create (via the request network\nid or port id), get the segment IDs per requested network,\nand then for each segment get their aggregates (maybe\nthe segments in the same network are all in the same\nresource provider aggregate, I\u0027m not sure).\n\nOnce we have all that crap, shove it in the request spec\nand translate it to required provider aggregates in the\nscheduler during GET /allocation_candidates.\n\nObviously needs testing, documentation, things like\nmove operations don\u0027t work (would need to recalculate\nthe routed network segment aggregates on each pass\nthrough the scheduler since you could attach/detach\nports in between server create and migrate).\n\nMISSION ACCOMPLISHED!\n\nTODO:\n* test coverage both unit and functional\n* documentation\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-05-02.log.html#t2019-05-02T19:56:34\n[2] https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html\n\nChange-Id: Ic5fadd69722b430c07739eb37295eedcd2621f35\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/7f434375240dbc373192af65f7fd84dd9ab5e6c0"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova/commit/7f434375240dbc373192af65f7fd84dd9ab5e6c0"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}