)]}'
{"id":"openstack%2Fdevstack~379543","triplet_id":"openstack%2Fdevstack~master~I9f44803cf04b572074bdb4b97ee58827c5611514","project":"openstack/devstack","branch":"master","topic":"default-pool-to-fixed","hashtags":[],"change_id":"I9f44803cf04b572074bdb4b97ee58827c5611514","subject":"Use FIXED_RANGE(_V6) as default subnet pool range","status":"ABANDONED","created":"2016-09-29 15:30:49.000000000","updated":"2016-11-02 22:41:10.000000000","total_comment_count":7,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"f50aeca0ce44c98e75245c94bba479edfec22f7f","_number":379543,"virtual_id_number":379543,"owner":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"actions":{},"labels":{"Verified":{"disliked":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"all":[{"value":-1,"date":"2016-10-14 20:29:59.000000000","_account_id":3,"name":"Jenkins","username":"jenkins"},{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},{"value":0,"date":"2016-09-30 19:32:27.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":14760,"name":"John L. Villalovos","email":"openstack.org@sodarock.com","username":"jlvillal"},{"_account_id":10379,"name":"Rajini Karthik","email":"rrajini@gmail.com","username":"rajinir"},{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},{"_account_id":14287,"name":"Waldemar Znoinski","email":"wznoinsk@redhat.com","username":"wznoinsk"},{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},{"date":"2016-09-30 20:42:45.000000000","_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"date":"2016-10-12 00:16:20.000000000","_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},{"_account_id":20498,"name":"Spyros Trigazis","email":"spyridon.trigazis@cern.ch","username":"strigazi"},{"date":"2016-10-12 00:23:06.000000000","_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},{"date":"2016-09-30 20:36:55.000000000","_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"date":"2016-10-12 16:34:18.000000000","_account_id":15321,"name":"Matthew Van Dijk","email":"mvandijk@tesora.com","username":"mvandijk"},{"_account_id":6524,"name":"Henry Gessau","email":"HenryG@gessau.net","username":"gessau"}],"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":{"recommended":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"disliked":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"all":[{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":3,"name":"Jenkins","username":"jenkins"},{"value":-1,"date":"2016-10-01 07:21:08.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},{"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":14760,"name":"John L. Villalovos","email":"openstack.org@sodarock.com","username":"jlvillal"},{"value":1,"date":"2016-10-03 18:33:10.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":10379,"name":"Rajini Karthik","email":"rrajini@gmail.com","username":"rajinir"},{"value":1,"date":"2016-09-30 19:30:16.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},{"value":-1,"date":"2016-10-04 00:50:24.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},{"value":1,"date":"2016-09-30 21:58:53.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":14287,"name":"Waldemar Znoinski","email":"wznoinsk@redhat.com","username":"wznoinsk"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},{"value":1,"date":"2016-10-03 19:53:59.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":20498,"name":"Spyros Trigazis","email":"spyridon.trigazis@cern.ch","username":"strigazi"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},{"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":15321,"name":"Matthew Van Dijk","email":"mvandijk@tesora.com","username":"mvandijk"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":6524,"name":"Henry Gessau","email":"HenryG@gessau.net","username":"gessau"}],"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":"","value":-1,"default_value":0,"optional":true},"Workflow":{"all":[{"_account_id":3,"name":"Jenkins","username":"jenkins"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"date":"2016-09-30 21:35:33.000000000","_account_id":14760,"name":"John L. Villalovos","email":"openstack.org@sodarock.com","username":"jlvillal"},{"_account_id":10379,"name":"Rajini Karthik","email":"rrajini@gmail.com","username":"rajinir"},{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},{"_account_id":14287,"name":"Waldemar Znoinski","email":"wznoinsk@redhat.com","username":"wznoinsk"},{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},{"_account_id":20498,"name":"Spyros Trigazis","email":"spyridon.trigazis@cern.ch","username":"strigazi"},{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"_account_id":15321,"name":"Matthew Van Dijk","email":"mvandijk@tesora.com","username":"mvandijk"},{"_account_id":6524,"name":"Henry Gessau","email":"HenryG@gessau.net","username":"gessau"}],"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":2},"_account_id":3,"name":"Jenkins","username":"jenkins"},{"value":0,"permitted_voting_range":{"min":-1,"max":2},"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_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":2},"_account_id":14760,"name":"John L. Villalovos","email":"openstack.org@sodarock.com","username":"jlvillal"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":10379,"name":"Rajini Karthik","email":"rrajini@gmail.com","username":"rajinir"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":14287,"name":"Waldemar Znoinski","email":"wznoinsk@redhat.com","username":"wznoinsk"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":2},"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":20498,"name":"Spyros Trigazis","email":"spyridon.trigazis@cern.ch","username":"strigazi"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_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":2},"_account_id":15321,"name":"Matthew Van Dijk","email":"mvandijk@tesora.com","username":"mvandijk"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":6524,"name":"Henry Gessau","email":"HenryG@gessau.net","username":"gessau"}],"values":{"-1":"Branch Freeze"," 0":"No Priority","+1":"Important Change","+2":"Gate Blocker Fix / Urgent Change"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":3,"name":"Jenkins","username":"jenkins"},{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},{"_account_id":6524,"name":"Henry Gessau","email":"HenryG@gessau.net","username":"gessau"},{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},{"_account_id":10379,"name":"Rajini Karthik","email":"rrajini@gmail.com","username":"rajinir"},{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},{"_account_id":14287,"name":"Waldemar Znoinski","email":"wznoinsk@redhat.com","username":"wznoinsk"},{"_account_id":14760,"name":"John L. Villalovos","email":"openstack.org@sodarock.com","username":"jlvillal"},{"_account_id":15321,"name":"Matthew Van Dijk","email":"mvandijk@tesora.com","username":"mvandijk"},{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},{"_account_id":20498,"name":"Spyros Trigazis","email":"spyridon.trigazis@cern.ch","username":"strigazi"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2016-09-29 16:20:47.000000000","updated_by":{"_account_id":6524,"name":"Henry Gessau","email":"HenryG@gessau.net","username":"gessau"},"reviewer":{"_account_id":6524,"name":"Henry Gessau","email":"HenryG@gessau.net","username":"gessau"},"state":"REVIEWER"},{"updated":"2016-09-30 09:32:18.000000000","updated_by":{"_account_id":14287,"name":"Waldemar Znoinski","email":"wznoinsk@redhat.com","username":"wznoinsk"},"reviewer":{"_account_id":14287,"name":"Waldemar Znoinski","email":"wznoinsk@redhat.com","username":"wznoinsk"},"state":"REVIEWER"},{"updated":"2016-09-30 17:44:18.000000000","updated_by":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"reviewer":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"state":"REVIEWER"},{"updated":"2016-09-30 19:30:16.000000000","updated_by":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"reviewer":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"state":"REVIEWER"},{"updated":"2016-09-30 19:32:27.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":"2016-09-30 20:36:55.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":"2016-09-30 20:42:45.000000000","updated_by":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"reviewer":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2016-09-30 21:35:33.000000000","updated_by":{"_account_id":14760,"name":"John L. Villalovos","email":"openstack.org@sodarock.com","username":"jlvillal"},"reviewer":{"_account_id":14760,"name":"John L. Villalovos","email":"openstack.org@sodarock.com","username":"jlvillal"},"state":"REVIEWER"},{"updated":"2016-09-30 21:58:53.000000000","updated_by":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"reviewer":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"state":"REVIEWER"},{"updated":"2016-10-01 07:21:08.000000000","updated_by":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"reviewer":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"state":"REVIEWER"},{"updated":"2016-10-03 18:33:10.000000000","updated_by":{"_account_id":10379,"name":"Rajini Karthik","email":"rrajini@gmail.com","username":"rajinir"},"reviewer":{"_account_id":10379,"name":"Rajini Karthik","email":"rrajini@gmail.com","username":"rajinir"},"state":"REVIEWER"},{"updated":"2016-10-03 19:53:59.000000000","updated_by":{"_account_id":20498,"name":"Spyros Trigazis","email":"spyridon.trigazis@cern.ch","username":"strigazi"},"reviewer":{"_account_id":20498,"name":"Spyros Trigazis","email":"spyridon.trigazis@cern.ch","username":"strigazi"},"state":"REVIEWER"},{"updated":"2016-10-04 00:50:24.000000000","updated_by":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"reviewer":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"state":"REVIEWER"},{"updated":"2016-10-12 00:23:06.000000000","updated_by":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"reviewer":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"state":"REVIEWER"},{"updated":"2016-10-12 16:34:18.000000000","updated_by":{"_account_id":15321,"name":"Matthew Van Dijk","email":"mvandijk@tesora.com","username":"mvandijk"},"reviewer":{"_account_id":15321,"name":"Matthew Van Dijk","email":"mvandijk@tesora.com","username":"mvandijk"},"state":"REVIEWER"},{"updated":"2016-10-14 20:29:59.000000000","updated_by":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"reviewer":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"state":"REVIEWER"}],"messages":[{"id":"f46029194a130be212c201cb04f155a21c0492dd","author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"date":"2016-09-29 15:30:49.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"d6f62dc4588f46ff9422bed47d8499b65c4c7ff9","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2016-09-29 15:31:04.000000000","message":"Patch Set 1:\n\nTesting completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. Contact info: kvmpower@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- check-ibm-tempest-dsvm-full check-ibm-tempest-dsvm-full : SKIPPED (non-voting)","accounts_in_message":[],"_revision_number":1},{"id":"16b8c8ce361289150e3f60ac0092f1cb338c2613","author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"date":"2016-09-29 16:03:40.000000000","message":"Patch Set 1:\n\n(2 comments)\n\nI support the idea in general, but I think having pools contain more than one subnet by default would be pretty nice, see inline comments.\n\nAlso I still do not understand how you can be sure that you can use 10.1.0.0/20 without issues if your cloud provider uses all of 10/8.","accounts_in_message":[],"_revision_number":1},{"id":"fe26ee6081b31775e49f4a741fb6e40d7e790da5","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2016-09-29 17:19:44.000000000","message":"Patch Set 1:\n\nBuild failed.  To recheck use \u0027xenserver: recheck\u0027.  For 3rd party ci contact info: https://wiki.openstack.org/wiki/ThirdPartySystems\n\n- dsvm-tempest-nova-network http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/43/379543/1/check/dsvm-tempest-nova-network/45eb32b : FAILURE in 26m 56s\n- dsvm-tempest-neutron-network http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/43/379543/1/check/dsvm-tempest-neutron-network/3717d02 : SUCCESS in 1h 48m 04s (non-voting)","accounts_in_message":[],"_revision_number":1},{"id":"5fc763837320d3513afb62602f56603d2cda5234","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2016-09-29 18:10:51.000000000","message":"Patch Set 1:\n\nBuild succeeded (check pipeline).\n\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial http://intel-openstack-ci-logs.ovh/43/379543/1/check/tempest-dsvm-ovsdpdk-nfv-networking-xenial/c14aee0 : FAILURE in 1h 03m 15s (non-voting)\n- tempest-dsvm-ovsdpdk-nfv-networking-centos http://intel-openstack-ci-logs.ovh/43/379543/1/check/tempest-dsvm-ovsdpdk-nfv-networking-centos/c84139e : SUCCESS in 1h 06m 14s (non-voting)\n- tempest-dsvm-full-nfv-xenial http://intel-openstack-ci-logs.ovh/43/379543/1/check/tempest-dsvm-full-nfv-xenial/9c4cd96 : FAILURE in 2h 04m 45s (non-voting)","accounts_in_message":[],"_revision_number":1},{"id":"0c680de0cd9469b33b0abc13c560b427e502377c","author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"date":"2016-09-29 18:27:55.000000000","message":"Patch Set 1:\n\nSo indeed we do need a subnet pool with at least two subnets, otherwise tempest.api.compute.admin.test_auto_allocate_network.AutoAllocateNetworkTest.test_server_multi_create_auto_allocate will fail.\n\nAs a maybe easier shortterm solution please also have a look at https://review.openstack.org/379521","accounts_in_message":[],"_revision_number":1},{"id":"a4f0caab8bf2079f2776519b29cbd3dc6b9647e2","author":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"date":"2016-09-29 22:03:09.000000000","message":"Patch Set 1: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see http://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n- gate-tempest-dsvm-neutron-full-ubuntu-xenial http://logs.openstack.org/43/379543/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/8d108f9/ : FAILURE in 42m 57s\n- gate-grenade-dsvm-neutron-ubuntu-xenial http://logs.openstack.org/43/379543/1/check/gate-grenade-dsvm-neutron-ubuntu-xenial/f810b06/ : SUCCESS in 54m 30s\n- gate-tempest-dsvm-full-ubuntu-xenial http://logs.openstack.org/43/379543/1/check/gate-tempest-dsvm-full-ubuntu-xenial/b867b3b/ : SUCCESS in 1h 02m 35s\n- gate-grenade-dsvm-ubuntu-xenial http://logs.openstack.org/43/379543/1/check/gate-grenade-dsvm-ubuntu-xenial/d9541a2/ : SUCCESS in 47m 23s\n- gate-devstack-docs-ubuntu-xenial http://docs-draft.openstack.org/43/379543/1/check/gate-devstack-docs-ubuntu-xenial/c832f71//doc/build/html/ : SUCCESS in 2m 59s\n- gate-devstack-bashate http://logs.openstack.org/43/379543/1/check/gate-devstack-bashate/79be45e/ : SUCCESS in 2m 05s\n- gate-devstack-unit-tests http://logs.openstack.org/43/379543/1/check/gate-devstack-unit-tests/741e732/ : SUCCESS in 3m 06s\n- gate-tempest-dsvm-ironic-ipa-wholedisk-agent_ssh-tinyipa-nv http://logs.openstack.org/43/379543/1/check/gate-tempest-dsvm-ironic-ipa-wholedisk-agent_ssh-tinyipa-nv/49c975b/ : SUCCESS in 24m 04s (non-voting)\n- gate-devstack-dsvm-updown http://logs.openstack.org/43/379543/1/check/gate-devstack-dsvm-updown/81829f8/ : SUCCESS in 22m 08s\n- gate-tempest-dsvm-neutron-identity-v3-only-full-ubuntu-xenial-nv http://logs.openstack.org/43/379543/1/check/gate-tempest-dsvm-neutron-identity-v3-only-full-ubuntu-xenial-nv/84f874a/ : FAILURE in 1h 10m 22s (non-voting)\n- gate-swift-dsvm-functional-ubuntu-xenial-nv http://logs.openstack.org/43/379543/1/check/gate-swift-dsvm-functional-ubuntu-xenial-nv/759ba0e/ : SUCCESS in 24m 49s (non-voting)\n- gate-tempest-dsvm-multinode-full-ubuntu-xenial http://logs.openstack.org/43/379543/1/check/gate-tempest-dsvm-multinode-full-ubuntu-xenial/317e4d5/ : FAILURE in 49m 33s (non-voting)\n- gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial http://logs.openstack.org/43/379543/1/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial/9d8a54f/ : FAILURE in 51m 08s (non-voting)\n- gate-grenade-dsvm-multinode http://logs.openstack.org/43/379543/1/check/gate-grenade-dsvm-multinode/6a5d218/ : SUCCESS in 28m 41s\n- gate-grenade-dsvm-neutron-multinode http://logs.openstack.org/43/379543/1/check/gate-grenade-dsvm-neutron-multinode/d657e0e/ : SUCCESS in 33m 06s\n- gate-tempest-dsvm-platform-centos7-nv http://logs.openstack.org/43/379543/1/check/gate-tempest-dsvm-platform-centos7-nv/3c392a7/ : FAILURE in 1h 23m 44s (non-voting)\n- gate-tempest-dsvm-platform-fedora24-nv http://logs.openstack.org/43/379543/1/check/gate-tempest-dsvm-platform-fedora24-nv/e54bd37/ : FAILURE in 1m 06s (non-voting)","accounts_in_message":[],"_revision_number":1},{"id":"6d3c4b40ace49ff00adf27a28c7679a4d69ada50","author":{"_account_id":14287,"name":"Waldemar Znoinski","email":"wznoinsk@redhat.com","username":"wznoinsk"},"date":"2016-09-30 09:32:18.000000000","message":"Patch Set 1: Code-Review-1\n\nif we\u0027d default SUBNETPOOL_PREFIX -\u003e FIXED_RANGE it would be a convenience for the first timers (one less setting to worry about) but since subnet pools provide a slightly different functionality to fixed ranged IPs op/dev should be aware of these differences when setting SUBNETPOOL_PREFIX_*","accounts_in_message":[],"_revision_number":1},{"id":"91180d7f4ad3b9fcb00e6156a3a355a93bebf440","author":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"date":"2016-09-30 17:35:49.000000000","message":"Patch Set 1: Code-Review+2\n\nLet\u0027s at least move the subnet pool allocations to use settings that people are familiar with, and have worked for years. Perhaps the defaults for subnetpools were not thought out well enough, and were specific to a certain environment.","accounts_in_message":[],"_revision_number":1},{"id":"aefaa7fce18dd4658c76beb52cfbe1f62b503985","author":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"date":"2016-09-30 17:36:44.000000000","message":"Patch Set 1:\n\nWe should have a separate patch that increases FIXED_RANGE_V6, then stack this on top","accounts_in_message":[],"_revision_number":1},{"id":"cb46d91e3bb02d69bc7dda9db71c57b512802642","author":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"date":"2016-09-30 17:44:18.000000000","message":"Patch Set 1: Code-Review+1\n\nsorry meant to +1 this, not +2","accounts_in_message":[],"_revision_number":1},{"id":"d2b414c2cf496af43531ac5cb23d0f6d0599efc9","author":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"date":"2016-09-30 18:33:44.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"7a326ed4738cd05de05265f0b66d6b8977845e39","author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"date":"2016-09-30 19:30:16.000000000","message":"Patch Set 2: Code-Review+1","accounts_in_message":[],"_revision_number":2},{"id":"0721ea58e45973fc1885a216c4b6ae7ece63b314","author":{"_account_id":10118,"name":"IBM PowerKVM CI","email":"kvmpower@linux.vnet.ibm.com","username":"powerkvm","tags":["SERVICE_USER"]},"date":"2016-09-30 19:32:27.000000000","message":"Patch Set 2:\n\nTesting completed on IBM PowerKVM platform. For rechecking only on the IBM PowerKVM CI, add a review comment with pkvm: recheck. Contact info: kvmpower@linux.vnet.ibm.com. For more information, see https://wiki.openstack.org/wiki/PowerKVM\n\n- check-ibm-tempest-dsvm-full http://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/devstack/43/379543/2/check/check-ibm-tempest-dsvm-full/4f59ec4/ : SUCCESS in 58m 23s (non-voting)","accounts_in_message":[],"_revision_number":2},{"id":"6651113f199d893ab0ad269fb0f4df3fcbb37739","author":{"_account_id":16376,"name":"Intel NFV CI","email":"openstack-nfv-ci@intel.com","username":"intel-nfv-ci","tags":["SERVICE_USER"]},"date":"2016-09-30 20:36:55.000000000","message":"Patch Set 2:\n\nBuild failed (check pipeline). To recheck leave a comment with \u0027intel-nfv-ci recheck\u0027. For more info go to https://wiki.openstack.org/wiki/ThirdPartySystems/Intel_NFV_CI.\n\n- tempest-dsvm-ovsdpdk-nfv-networking-xenial http://intel-openstack-ci-logs.ovh/43/379543/2/check/tempest-dsvm-ovsdpdk-nfv-networking-xenial/56bf053 : SUCCESS in 59m 32s\n- tempest-dsvm-ovsdpdk-nfv-networking-centos http://intel-openstack-ci-logs.ovh/43/379543/2/check/tempest-dsvm-ovsdpdk-nfv-networking-centos/804b842 : SUCCESS in 58m 49s (non-voting)\n- tempest-dsvm-full-nfv-xenial http://intel-openstack-ci-logs.ovh/43/379543/2/check/tempest-dsvm-full-nfv-xenial/ad68ef0 : FAILURE in 2h 02m 51s","accounts_in_message":[],"_revision_number":2},{"id":"df5da5b7eb66cd1ce7b6064fa42be50691be7403","author":{"_account_id":10385,"name":"Citrix XenServer CI","username":"citrix_xenserver_ci","tags":["SERVICE_USER"]},"date":"2016-09-30 20:42:45.000000000","message":"Patch Set 2:\n\nBuild succeeded.\n\n- dsvm-tempest-nova-network http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/43/379543/2/check/dsvm-tempest-nova-network/8055606 : SUCCESS in 1h 22m 36s\n- dsvm-tempest-neutron-network http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/43/379543/2/check/dsvm-tempest-neutron-network/1ff5c9a : SUCCESS in 1h 45m 00s (non-voting)","accounts_in_message":[],"_revision_number":2},{"id":"10c60a471721790a9f7de8d0c021f7664da23ed5","author":{"_account_id":5263,"name":"Jeremy Stanley","display_name":"fungi","email":"fungi@yuggoth.org","username":"fungi","status":"missing, presumed fed"},"date":"2016-09-30 21:58:53.000000000","message":"Patch Set 2: Code-Review+1","accounts_in_message":[],"_revision_number":2},{"id":"c6096e86d853bd16ce11d3f58114a99f7cafe9cf","author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"date":"2016-10-01 07:21:08.000000000","message":"Patch Set 2: Code-Review-1\n\n(2 comments)","accounts_in_message":[],"_revision_number":2},{"id":"c8f631b0997fc7c9006244e546e712aab25f6eff","author":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"date":"2016-10-01 16:35:13.000000000","message":"Patch Set 2: Verified+1\n\nBuild succeeded (check pipeline).\n\n- gate-tempest-dsvm-neutron-full-ubuntu-xenial http://logs.openstack.org/43/379543/2/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/61a8883/ : SUCCESS in 46m 02s\n- gate-grenade-dsvm-neutron-ubuntu-xenial http://logs.openstack.org/43/379543/2/check/gate-grenade-dsvm-neutron-ubuntu-xenial/fe51230/ : SUCCESS in 30m 35s\n- gate-tempest-dsvm-full-ubuntu-xenial http://logs.openstack.org/43/379543/2/check/gate-tempest-dsvm-full-ubuntu-xenial/34bad82/ : SUCCESS in 36m 11s\n- gate-grenade-dsvm-ubuntu-xenial http://logs.openstack.org/43/379543/2/check/gate-grenade-dsvm-ubuntu-xenial/d0b1e6e/ : SUCCESS in 24m 16s\n- gate-devstack-docs-ubuntu-xenial http://docs-draft.openstack.org/43/379543/2/check/gate-devstack-docs-ubuntu-xenial/f938035//doc/build/html/ : SUCCESS in 1m 54s\n- gate-devstack-bashate http://logs.openstack.org/43/379543/2/check/gate-devstack-bashate/3506dd0/ : SUCCESS in 2m 28s\n- gate-devstack-unit-tests http://logs.openstack.org/43/379543/2/check/gate-devstack-unit-tests/6f73471/ : SUCCESS in 1m 59s\n- gate-tempest-dsvm-ironic-ipa-wholedisk-agent_ssh-tinyipa-nv http://logs.openstack.org/43/379543/2/check/gate-tempest-dsvm-ironic-ipa-wholedisk-agent_ssh-tinyipa-nv/14884e5/ : SUCCESS in 23m 32s (non-voting)\n- gate-devstack-dsvm-updown http://logs.openstack.org/43/379543/2/check/gate-devstack-dsvm-updown/d31d4db/ : SUCCESS in 15m 27s\n- gate-tempest-dsvm-neutron-identity-v3-only-full-ubuntu-xenial-nv http://logs.openstack.org/43/379543/2/check/gate-tempest-dsvm-neutron-identity-v3-only-full-ubuntu-xenial-nv/aab99c0/ : SUCCESS in 1h 09m 48s (non-voting)\n- gate-swift-dsvm-functional-ubuntu-xenial-nv http://logs.openstack.org/43/379543/2/check/gate-swift-dsvm-functional-ubuntu-xenial-nv/cd416cd/ : SUCCESS in 20m 03s (non-voting)\n- gate-tempest-dsvm-multinode-full-ubuntu-xenial http://logs.openstack.org/43/379543/2/check/gate-tempest-dsvm-multinode-full-ubuntu-xenial/678d28a/ : FAILURE in 50m 00s (non-voting)\n- gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial http://logs.openstack.org/43/379543/2/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial/4e9bce9/ : SUCCESS in 50m 56s (non-voting)\n- gate-grenade-dsvm-multinode http://logs.openstack.org/43/379543/2/check/gate-grenade-dsvm-multinode/f3d3f1e/ : SUCCESS in 26m 37s\n- gate-grenade-dsvm-neutron-multinode http://logs.openstack.org/43/379543/2/check/gate-grenade-dsvm-neutron-multinode/395fa43/ : SUCCESS in 1h 02m 03s\n- gate-tempest-dsvm-platform-centos7-nv http://logs.openstack.org/43/379543/2/check/gate-tempest-dsvm-platform-centos7-nv/37c1df2/ : SUCCESS in 46m 25s (non-voting)\n- gate-tempest-dsvm-platform-fedora24-nv http://logs.openstack.org/43/379543/2/check/gate-tempest-dsvm-platform-fedora24-nv/a599d23/ : SUCCESS in 1h 22m 21s (non-voting)","accounts_in_message":[],"_revision_number":2},{"id":"0ca9f0a6bad72f4e0f9c87a46beaefcd9e3495e7","author":{"_account_id":10379,"name":"Rajini Karthik","email":"rrajini@gmail.com","username":"rajinir"},"date":"2016-10-03 18:33:10.000000000","message":"Patch Set 2: Code-Review+1\n\nRelated patch - https://review.openstack.org/#/c/378063/","accounts_in_message":[],"_revision_number":2},{"id":"f57931ccbd0b3c5cc1ed2fda318976fad263f665","author":{"_account_id":20498,"name":"Spyros Trigazis","email":"spyridon.trigazis@cern.ch","username":"strigazi"},"date":"2016-10-03 19:53:59.000000000","message":"Patch Set 2: Code-Review+1\n\nThanks, this change unblocks magnum\u0027s gate.","accounts_in_message":[],"_revision_number":2},{"id":"d1db164738e3c005939aac60974134ebb948c136","author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"date":"2016-10-04 00:50:24.000000000","message":"Patch Set 2: Code-Review-1\n\n(1 comment)","accounts_in_message":[],"_revision_number":2},{"id":"ed99527294ea08cc0370af54f0bec9aa04265619","author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"date":"2016-10-04 00:57:11.000000000","message":"Patch Set 2:\n\nI am not particularly fond of the the fact that we\u0027re tying SUBNETPOOL_PREFIX with FIXED_RANGE when they are not strictly the same thing, but I am happy to see my -1 overruled.","accounts_in_message":[],"_revision_number":2},{"id":"cf1b16fca4653ab92abd161b0979e13fa8c43af6","author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"date":"2016-10-04 01:04:49.000000000","message":"Patch Set 2:\n\n\u003e I am not particularly fond of the the fact that we\u0027re tying\n \u003e SUBNETPOOL_PREFIX with FIXED_RANGE when they are not strictly the\n \u003e same thing, but I am happy to see my -1 overruled.\n\nTalked to Clark on [1]. This is basically a soft revert of [2], I might as well suggest to put the values back to what they were.\n\n[1] http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2016-10-04.log.html#t2016-10-04T00:44:50\n[2] https://review.openstack.org/#/c/283289","accounts_in_message":[],"_revision_number":2},{"id":"7a019f6f65820eb7d06c0ffd940f901232397477","author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"date":"2016-10-12 00:13:50.000000000","message":"Patch Set 2:\n\nI ended up doing more digging and I believe I found the culprit in [1]. Subnetpools per se are nothing but a mechanism to allocate private logical networks out of a predefined pool, surely we can shrink the pool but I wonder if the newly introduced logic has caused more trouble than it\u0027s worth (see bug 1628267 for details).\n\n[1] https://review.openstack.org/#/c/356026/","accounts_in_message":[],"_revision_number":2},{"id":"c84468a8726828c5b4cf2f0bb83467432b8d1671","author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"date":"2016-10-12 00:16:20.000000000","message":"Patch Set 2:\n\nTo reiterate what the commit message has said. The whole point of this change is to explicitly use FIXED_RANGE and NOT use another variable because this is the source of the regression in the first place. The configuration API devstack previously exposes is to use FIXED_RANGE to avoid these overlaps. But the switch to completely independent variables ignores anyone who has previously set this variable to avoid conflicts.\n\nI do not think we should do this because it is the source of the regression. We could indeed just edit the subnet pool variables and hope that we don\u0027t conflict anywhere or we can fix the problem by actually fixing it.","accounts_in_message":[],"_revision_number":2},{"id":"0f2870255e3d5c048fab1af8a3cfe88b34a4d55c","author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"date":"2016-10-12 00:18:31.000000000","message":"Patch Set 2:\n\n\u003e To reiterate what the commit message has said. The whole point of\n \u003e this change is to explicitly use FIXED_RANGE and NOT use another\n \u003e variable because this is the source of the regression in the first\n \u003e place. The configuration API devstack previously exposes is to use\n \u003e FIXED_RANGE to avoid these overlaps. But the switch to completely\n \u003e independent variables ignores anyone who has previously set this\n \u003e variable to avoid conflicts.\n \u003e \n \u003e I do not think we should do this because it is the source of the\n \u003e regression. We could indeed just edit the subnet pool variables and\n \u003e hope that we don\u0027t conflict anywhere or we can fix the problem by\n \u003e actually fixing it.\n\nI think this is not a regression, the error is introduced by [1], I\u0027d almost be tempted to say that the actual fix is a revert of that one.\n\n[1] https://review.openstack.org/#/c/356026/","accounts_in_message":[],"_revision_number":2},{"id":"13f3389c03fc6319e5b28c7e8abf574445bae2fb","author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"date":"2016-10-12 00:23:06.000000000","message":"Patch Set 2:\n\n(2 comments)","accounts_in_message":[],"_revision_number":2},{"id":"919536ecdbfbb665c7f11d869b43549982439a27","author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"date":"2016-10-12 00:25:28.000000000","message":"Patch Set 2:\n\n\u003e \u003e To reiterate what the commit message has said. The whole point of\n \u003e \u003e this change is to explicitly use FIXED_RANGE and NOT use another\n \u003e \u003e variable because this is the source of the regression in the\n \u003e first\n \u003e \u003e place. The configuration API devstack previously exposes is to\n \u003e use\n \u003e \u003e FIXED_RANGE to avoid these overlaps. But the switch to completely\n \u003e \u003e independent variables ignores anyone who has previously set this\n \u003e \u003e variable to avoid conflicts.\n \u003e \u003e\n \u003e \u003e I do not think we should do this because it is the source of the\n \u003e \u003e regression. We could indeed just edit the subnet pool variables\n \u003e and\n \u003e \u003e hope that we don\u0027t conflict anywhere or we can fix the problem by\n \u003e \u003e actually fixing it.\n \u003e \n \u003e I think this is not a regression, the error is introduced by [1],\n \u003e I\u0027d almost be tempted to say that the actual fix is a revert of\n \u003e that one.\n \u003e \n \u003e [1] https://review.openstack.org/#/c/356026/\n\nThat would be one way to fix it, but aiui we already rely on larger subnet pools for several tests (though I may have misunderstood that) so there was a desire to roll forward and keep the tests working rather than revert a whole bunch of things.","accounts_in_message":[],"_revision_number":2},{"id":"d48f7b41a6ac251aaecd36f02a8db4fe7eb117de","author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"date":"2016-10-12 00:31:44.000000000","message":"Patch Set 2:\n\n\u003e \u003e \u003e To reiterate what the commit message has said. The whole point\n \u003e of\n \u003e \u003e \u003e this change is to explicitly use FIXED_RANGE and NOT use\n \u003e another\n \u003e \u003e \u003e variable because this is the source of the regression in the\n \u003e \u003e first\n \u003e \u003e \u003e place. The configuration API devstack previously exposes is to\n \u003e \u003e use\n \u003e \u003e \u003e FIXED_RANGE to avoid these overlaps. But the switch to\n \u003e completely\n \u003e \u003e \u003e independent variables ignores anyone who has previously set\n \u003e this\n \u003e \u003e \u003e variable to avoid conflicts.\n \u003e \u003e \u003e\n \u003e \u003e \u003e I do not think we should do this because it is the source of\n \u003e the\n \u003e \u003e \u003e regression. We could indeed just edit the subnet pool variables\n \u003e \u003e and\n \u003e \u003e \u003e hope that we don\u0027t conflict anywhere or we can fix the problem\n \u003e by\n \u003e \u003e \u003e actually fixing it.\n \u003e \u003e\n \u003e \u003e I think this is not a regression, the error is introduced by [1],\n \u003e \u003e I\u0027d almost be tempted to say that the actual fix is a revert of\n \u003e \u003e that one.\n \u003e \u003e\n \u003e \u003e [1] https://review.openstack.org/#/c/356026/\n \u003e \n \u003e That would be one way to fix it, but aiui we already rely on larger\n \u003e subnet pools for several tests (though I may have misunderstood\n \u003e that) so there was a desire to roll forward and keep the tests\n \u003e working rather than revert a whole bunch of things.\n\nThe only tempest tests that need subnetpools are the auto-topology ones and they only need a handful of subnets, not hundreds. To me the smoking gun [1] is telling me that we merged it without fully understanding the consequences. Besides, I am not sure why that patch was allowed in the first place. Forcing subnet creations out of a subnet pool when available is clearly altering how devstack always worked and I would have been opposed to it without fully understanding the actual need behind it.","accounts_in_message":[],"_revision_number":2},{"id":"6e0969a748436f44128d5c8ad69766165a64c6b1","author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"date":"2016-10-12 00:35:27.000000000","message":"Patch Set 2:\n\n\u003e \u003e \u003e I think this is not a regression, the error is introduced by\n \u003e [1],\n \u003e \u003e \u003e I\u0027d almost be tempted to say that the actual fix is a revert of\n \u003e \u003e \u003e that one.\n \u003e \u003e \u003e\n \u003e \u003e \u003e [1] https://review.openstack.org/#/c/356026/\n \u003e \u003e\n \u003e \u003e That would be one way to fix it, but aiui we already rely on\n \u003e larger\n \u003e \u003e subnet pools for several tests (though I may have misunderstood\n \u003e \u003e that) so there was a desire to roll forward and keep the tests\n \u003e \u003e working rather than revert a whole bunch of things.\n \u003e \n \u003e The only tempest tests that need subnetpools are the auto-topology\n \u003e ones and they only need a handful of subnets, not hundreds. To me\n \u003e the smoking gun [1] is telling me that we merged it without fully\n \u003e understanding the consequences. Besides, I am not sure why that\n \u003e patch was allowed in the first place. Forcing subnet creations out\n \u003e of a subnet pool when available is clearly altering how devstack\n \u003e always worked and I would have been opposed to it without fully\n \u003e understanding the actual need behind it.\n\nYou should be able to propose the revert of [1] and have it be self tested. Just have to recheck if the multinode jobs don\u0027t land in osic.","accounts_in_message":[],"_revision_number":2},{"id":"e3de523d8c2d25dfd8bcd8f6ae0eb50fa0da5731","author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"date":"2016-10-12 00:41:52.000000000","message":"Patch Set 2:\n\n\u003e \u003e \u003e \u003e I think this is not a regression, the error is introduced by\n \u003e \u003e [1],\n \u003e \u003e \u003e \u003e I\u0027d almost be tempted to say that the actual fix is a revert\n \u003e of\n \u003e \u003e \u003e \u003e that one.\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e [1] https://review.openstack.org/#/c/356026/\n \u003e \u003e \u003e\n \u003e \u003e \u003e That would be one way to fix it, but aiui we already rely on\n \u003e \u003e larger\n \u003e \u003e \u003e subnet pools for several tests (though I may have misunderstood\n \u003e \u003e \u003e that) so there was a desire to roll forward and keep the tests\n \u003e \u003e \u003e working rather than revert a whole bunch of things.\n \u003e \u003e\n \u003e \u003e The only tempest tests that need subnetpools are the\n \u003e auto-topology\n \u003e \u003e ones and they only need a handful of subnets, not hundreds. To me\n \u003e \u003e the smoking gun [1] is telling me that we merged it without fully\n \u003e \u003e understanding the consequences. Besides, I am not sure why that\n \u003e \u003e patch was allowed in the first place. Forcing subnet creations\n \u003e out\n \u003e \u003e of a subnet pool when available is clearly altering how devstack\n \u003e \u003e always worked and I would have been opposed to it without fully\n \u003e \u003e understanding the actual need behind it.\n \u003e \n \u003e You should be able to propose the revert of [1] and have it be self\n \u003e tested. Just have to recheck if the multinode jobs don\u0027t land in\n \u003e osic.\n\nAlso we really really need documentation for this stuff especially if it is going to be turned on by default. It isn\u0027t clear at first glance if neutron is setting the route or devstack (looks like devstack based on the proposed possible revert) or why editing the routing table is desired in the first place (allows VMs to talk to hypervisors via their tenant networks which is weird).\n\nIf we decide that we cannot re consume FIXED_RANGE as the designator for a safe subnet range here then we also need to make sure we document how to avoid these conflicts (what vars to set) and make sure we set them for the gate jobs before we start relying on this. And probably have a big warning for \"Hey this changed you may need to set these new vars\" in release notes or something.","accounts_in_message":[],"_revision_number":2},{"id":"80252182032721579dafb206b18fec9e8a04008c","author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"date":"2016-10-12 00:46:24.000000000","message":"Patch Set 2:\n\n\u003e \u003e \u003e \u003e \u003e I think this is not a regression, the error is introduced\n \u003e by\n \u003e \u003e \u003e [1],\n \u003e \u003e \u003e \u003e \u003e I\u0027d almost be tempted to say that the actual fix is a\n \u003e revert\n \u003e \u003e of\n \u003e \u003e \u003e \u003e \u003e that one.\n \u003e \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e \u003e [1] https://review.openstack.org/#/c/356026/\n \u003e \u003e \u003e \u003e\n \u003e \u003e \u003e \u003e That would be one way to fix it, but aiui we already rely on\n \u003e \u003e \u003e larger\n \u003e \u003e \u003e \u003e subnet pools for several tests (though I may have\n \u003e misunderstood\n \u003e \u003e \u003e \u003e that) so there was a desire to roll forward and keep the\n \u003e tests\n \u003e \u003e \u003e \u003e working rather than revert a whole bunch of things.\n \u003e \u003e \u003e\n \u003e \u003e \u003e The only tempest tests that need subnetpools are the\n \u003e \u003e auto-topology\n \u003e \u003e \u003e ones and they only need a handful of subnets, not hundreds. To\n \u003e me\n \u003e \u003e \u003e the smoking gun [1] is telling me that we merged it without\n \u003e fully\n \u003e \u003e \u003e understanding the consequences. Besides, I am not sure why that\n \u003e \u003e \u003e patch was allowed in the first place. Forcing subnet creations\n \u003e \u003e out\n \u003e \u003e \u003e of a subnet pool when available is clearly altering how\n \u003e devstack\n \u003e \u003e \u003e always worked and I would have been opposed to it without fully\n \u003e \u003e \u003e understanding the actual need behind it.\n \u003e \u003e\n \u003e \u003e You should be able to propose the revert of [1] and have it be\n \u003e self\n \u003e \u003e tested. Just have to recheck if the multinode jobs don\u0027t land in\n \u003e \u003e osic.\n \u003e \n \u003e Also we really really need documentation for this stuff especially\n \u003e if it is going to be turned on by default. It isn\u0027t clear at first\n \u003e glance if neutron is setting the route or devstack (looks like\n \u003e devstack based on the proposed possible revert) or why editing the\n \u003e routing table is desired in the first place (allows VMs to talk to\n \u003e hypervisors via their tenant networks which is weird).\n \u003e \n \u003e If we decide that we cannot re consume FIXED_RANGE as the\n \u003e designator for a safe subnet range here then we also need to make\n \u003e sure we document how to avoid these conflicts (what vars to set)\n \u003e and make sure we set them for the gate jobs before we start relying\n \u003e on this. And probably have a big warning for \"Hey this changed you\n \u003e may need to set these new vars\" in release notes or something.\n\nI agree on both counts, for a moment I thought this was my fault but I can see it\u0027s not :P\n\nI now feel that this change is no longer valid because by tweaking the range we\u0027re only making the problem slightly less likely but a misconfiguration is still possible due to how the routing table is fiddled with.","accounts_in_message":[],"_revision_number":2},{"id":"2522e7727d276d3cf18f786b6778f502524d4276","author":{"_account_id":15321,"name":"Matthew Van Dijk","email":"mvandijk@tesora.com","username":"mvandijk"},"date":"2016-10-12 16:34:18.000000000","message":"Patch Set 2:\n\nThe reason behind review.openstack.org/356026 was that the v4 subnet pool was being overlapped by the FIXED_RANGE, and all the routing etc was based on the FIXED_RANGE. Reverting the change isn\u0027t helpful in that sense.\n\nWe wanted to make use of subnet pools, and my belief was that they should be used by default (that was a mistake). Why would we encourage the manual management of subnets when we have a mechanism that does the work for us?\n\nThe patch missed two points though - keeping the current behaviour as default and taking a closer look at the subnet pool range. Between this proposed patch, once an agreement has landed about the values to use, and review.openstack.org/378063, these points will be settled.","accounts_in_message":[],"_revision_number":2},{"id":"8b455f6507e0cdc23209156d250ac370d61a871e","author":{"_account_id":3,"name":"Jenkins","username":"jenkins"},"date":"2016-10-14 20:29:59.000000000","message":"Patch Set 2: 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":2},{"id":"61f6c51f4cba2bea65abb72f33bc80e68389c888","author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"date":"2016-11-02 22:41:10.000000000","message":"Abandoned\n\nThis was solved in another manner.","accounts_in_message":[],"_revision_number":2}],"current_revision_number":2,"current_revision":"7dec9a64ab7f180fb960edeb669be2eb3f394213","revisions":{"69a59f2f373dbc6f7556d162dfed665a5ac2811a":{"kind":"REWORK","_number":1,"created":"2016-09-29 15:30:49.000000000","uploader":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"ref":"refs/changes/43/379543/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/devstack","ref":"refs/changes/43/379543/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/devstack refs/changes/43/379543/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/devstack refs/changes/43/379543/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/devstack refs/changes/43/379543/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/devstack refs/changes/43/379543/1"}}},"commit":{"parents":[{"commit":"ced511c593c68764d007f8b559099d353bae6f45","subject":"Merge \"Work around issue in glance_store swift driver\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/devstack/commit/ced511c593c68764d007f8b559099d353bae6f45"}]}],"author":{"name":"Clark Boylan","email":"clark.boylan@gmail.com","date":"2016-09-29 15:27:37.000000000","tz":-420},"committer":{"name":"Clark Boylan","email":"clark.boylan@gmail.com","date":"2016-09-29 15:27:37.000000000","tz":-420},"subject":"Use FIXED_RANGE(_V6) as default subnet pool range","message":"Use FIXED_RANGE(_V6) as default subnet pool range\n\nIt turns out that many people have already chosen fixed ranges that work\nfor their environments. They have done so to avoid conflicts with\nexisting networking ranges and routing. The change to use 10.0.0.0/8 and\napply routes for this network to neutron interfaces prevents anyone from\nusing networks within that range for anything else.\n\nFor example imagine you have a cloud provider that provides private IPv4\naddresses allocated out of ranges in 10.0.0.0/8 and they do all public\nnetworking over ipv6. This change to devstack prevents you from using\nthose private networks properly after starting neutron with devstack.\nHowever, in situations like this FIXED_RANGE should already represent a\nsafe range to use so just use it.\n\nChange-Id: I9f44803cf04b572074bdb4b97ee58827c5611514\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/devstack/commit/69a59f2f373dbc6f7556d162dfed665a5ac2811a"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/devstack/commit/69a59f2f373dbc6f7556d162dfed665a5ac2811a"}]},"branch":"refs/heads/master"},"7dec9a64ab7f180fb960edeb669be2eb3f394213":{"kind":"REWORK","_number":2,"created":"2016-09-30 18:33:44.000000000","uploader":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"ref":"refs/changes/43/379543/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/devstack","ref":"refs/changes/43/379543/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/devstack refs/changes/43/379543/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/devstack refs/changes/43/379543/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/devstack refs/changes/43/379543/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/devstack refs/changes/43/379543/2"}}},"commit":{"parents":[{"commit":"ced511c593c68764d007f8b559099d353bae6f45","subject":"Merge \"Work around issue in glance_store swift driver\"","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/devstack/commit/ced511c593c68764d007f8b559099d353bae6f45"}]}],"author":{"name":"Clark Boylan","email":"clark.boylan@gmail.com","date":"2016-09-29 15:27:37.000000000","tz":-420},"committer":{"name":"Sean M. Collins","email":"sean@coreitpro.com","date":"2016-09-30 18:19:09.000000000","tz":-240},"subject":"Use FIXED_RANGE(_V6) as default subnet pool range","message":"Use FIXED_RANGE(_V6) as default subnet pool range\n\nIt turns out that many people have already chosen fixed ranges that work\nfor their environments. They have done so to avoid conflicts with\nexisting networking ranges and routing. The change to use 10.0.0.0/8 and\napply routes for this network to neutron interfaces prevents anyone from\nusing networks within that range for anything else.\n\nFor example imagine you have a cloud provider that provides private IPv4\naddresses allocated out of ranges in 10.0.0.0/8 and they do all public\nnetworking over ipv6. This change to devstack prevents you from using\nthose private networks properly after starting neutron with devstack.\nHowever, in situations like this FIXED_RANGE should already represent a\nsafe range to use so just use it.\n\nFIXED_RANGE_V6 is also increased to a /56 so that individual /64s can\nbe allocated for tenant networks.\n\nCo-Authored-By: Sean M. Collins \u003csean@coreitpro.com\u003e\n\nChange-Id: I9f44803cf04b572074bdb4b97ee58827c5611514\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/devstack/commit/7dec9a64ab7f180fb960edeb669be2eb3f394213"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/devstack/commit/7dec9a64ab7f180fb960edeb669be2eb3f394213"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}