)]}'
{"specs/zero-downtime-upgrade.rst":[{"author":{"_account_id":23717,"name":"Surya Prakash Singh","email":"singh.surya64mnnit@gmail.com","username":"SuryaPrakash"},"change_message_id":"4aaea2d4c4109e57df2e9d8025a9d15a1ea74db3","unresolved":false,"context_lines":[{"line_number":16,"context_line":"mechanism via calling service CLI and total downtime is equal or larger (than)"},{"line_number":17,"context_line":"service downtime."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put beind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a71b18c_f7b23695","line":19,"range":{"start_line":19,"start_character":70,"end_line":19,"end_character":75},"updated":"2016-12-12 07:32:35.000000000","message":"s/beind/behind","commit_id":"bf2b847d8205b8d0d9e16f1d9858038975e4603d"},{"author":{"_account_id":22582,"name":"Duong Ha-Quang","email":"quangduongha@gmail.com","username":"duonghq"},"change_message_id":"84d129a866e3958732ce3e7d0ff7b320505073bf","unresolved":false,"context_lines":[{"line_number":16,"context_line":"mechanism via calling service CLI and total downtime is equal or larger (than)"},{"line_number":17,"context_line":"service downtime."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put beind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a71b18c_dd30fb58","line":19,"range":{"start_line":19,"start_character":70,"end_line":19,"end_character":75},"in_reply_to":"3a71b18c_f7b23695","updated":"2016-12-12 07:50:53.000000000","message":"Done","commit_id":"bf2b847d8205b8d0d9e16f1d9858038975e4603d"},{"author":{"_account_id":19316,"name":"Eduardo Gonzalez","email":"dabarren@gmail.com","username":"egonzalez90"},"change_message_id":"901dd802d14d91bc842f29492e140febb58c16a1","unresolved":false,"context_lines":[{"line_number":12,"context_line":"Problem description"},{"line_number":13,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Firstly, in order to upgrade OpenStack services, Kolla ultilizes these"},{"line_number":16,"context_line":"mechanism via calling service CLI and total downtime is equal or larger (than)"},{"line_number":17,"context_line":"service downtime."},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_80ae6583","line":15,"range":{"start_line":15,"start_character":55,"end_line":15,"end_character":64},"updated":"2016-12-14 08:57:00.000000000","message":"/ultilizes/utilizes","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":22582,"name":"Duong Ha-Quang","email":"quangduongha@gmail.com","username":"duonghq"},"change_message_id":"42045b3376d67ee583de31123f995ee90869fed3","unresolved":false,"context_lines":[{"line_number":12,"context_line":"Problem description"},{"line_number":13,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"Firstly, in order to upgrade OpenStack services, Kolla ultilizes these"},{"line_number":16,"context_line":"mechanism via calling service CLI and total downtime is equal or larger (than)"},{"line_number":17,"context_line":"service downtime."},{"line_number":18,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"da4df55a_7c50e4d4","line":15,"range":{"start_line":15,"start_character":55,"end_line":15,"end_character":64},"in_reply_to":"1a6eadb0_80ae6583","updated":"2016-12-28 01:39:13.000000000","message":"Done","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":14119,"name":"Sam Yaple","email":"sam+git@yaple.net","username":"SamYaple"},"change_message_id":"7382815da909b8e2f978d5e2a4a1121cb9ff7f84","unresolved":false,"context_lines":[{"line_number":16,"context_line":"mechanism via calling service CLI and total downtime is equal or larger (than)"},{"line_number":17,"context_line":"service downtime."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_cf3da28f","line":19,"updated":"2016-12-12 08:23:59.000000000","message":"This is not a requirement. I use a LB outside of kolla-ansible.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":22582,"name":"Duong Ha-Quang","email":"quangduongha@gmail.com","username":"duonghq"},"change_message_id":"ad0fee1c0cc70cb9630fa292341fbb43e4cd487d","unresolved":false,"context_lines":[{"line_number":16,"context_line":"mechanism via calling service CLI and total downtime is equal or larger (than)"},{"line_number":17,"context_line":"service downtime."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_0385b1cd","line":19,"in_reply_to":"3a71b18c_cf3da28f","updated":"2016-12-12 10:13:36.000000000","message":"Currently, in Kolla-ansible architecture, HAProxy is default and recommend component in Kolla-ansible architecture for multinode deployment.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":14119,"name":"Sam Yaple","email":"sam+git@yaple.net","username":"SamYaple"},"change_message_id":"7382815da909b8e2f978d5e2a4a1121cb9ff7f84","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"},{"line_number":23,"context_line":"user sees a downtime here, even other nodes are still running."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_8fd3aa37","line":21,"updated":"2016-12-12 08:23:59.000000000","message":"this can be solved with haproxy itself, draining connections to nodes before shutting down and restarting containers (serially). This was discussed at somepoint in the past, but no one did the work","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":14119,"name":"Sam Yaple","email":"sam+git@yaple.net","username":"SamYaple"},"change_message_id":"e1cb4404c2cf7d34d35c9462cd0c8d53fc33b23f","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"},{"line_number":23,"context_line":"user sees a downtime here, even other nodes are still running."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_57d8d053","line":21,"in_reply_to":"1a6eadb0_3aaa63d5","updated":"2016-12-13 07:03:50.000000000","message":"Without this piece for haproxy when you restart a container you are breaking connections.\n\nWhich services are you speaking of specially. Neutron has full online upgrades, as well as nova. We don\u0027t currently do them in Kolla, but they have native support for that.\n\nThe only services that I can think this would be useful for would be mariadb and rabbitmq, but buffering rabbitmq is a bad idea in general. Since you are purposing _delaying_ the connection to mariadb with buffering, i don\u0027t see how that is different than having a retry in the application itself which currently happens.\n\nMy point is what is being shown in the video can be solved by utilizing haproxy to drain and restart the servers in serial without this buffering layer. The only reason any connections fail at all is because we aren\u0027t coordinating with haproxy while doing the upgrade. This buffering is simply hiding that but holding all connections.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":19741,"name":"Hieu LE","email":"hieulq2@viettel.com.vn","username":"hieulq"},"change_message_id":"a0cbd65486c02eec61295004db00c5f605a5e111","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"},{"line_number":23,"context_line":"user sees a downtime here, even other nodes are still running."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_dac16582","line":21,"in_reply_to":"1a6eadb0_57d8d053","updated":"2016-12-13 07:24:25.000000000","message":"Sam, we have tested the online upgrades features in Neutron, Nova, KeyStone. Neutron meet some downtimes when do online schema migrating as you can see in the first part of video. Nova and KeyStone did well with online upgrade. \n\nThese above tests are normally for individual projects. In the whole system the total downtime is bigger. While you serially do online upgrade for each components, the requests sometimes can\u0027t reach the upgrading services.\n\nYour point on using HAProxy is great idea, but HAProxy can not support for some projects that currently do not support online upgrade for DB or RPC versioning like Glance, Neutron, Heat. That\u0027s why we come with this approach.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":19316,"name":"Eduardo Gonzalez","email":"dabarren@gmail.com","username":"egonzalez90"},"change_message_id":"901dd802d14d91bc842f29492e140febb58c16a1","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"},{"line_number":23,"context_line":"user sees a downtime here, even other nodes are still running."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_db020c09","line":21,"in_reply_to":"1a6eadb0_dac16582","updated":"2016-12-14 08:57:00.000000000","message":"As Sam Yaple said before, buffering in HAproxy can be avoided using admin socket in HAproxy, you can put a node in maintenance mode while waiting to end all requests to that node. This will avoid downtime on the API layer when the orchestration is properly done.\n\nFor the worker services, downtime cannot be avoided unless the service itself support zero-downtime upgrade as nova, keystone, neutron.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":22582,"name":"Duong Ha-Quang","email":"quangduongha@gmail.com","username":"duonghq"},"change_message_id":"50ddc53f128a4a5984846b6e5b1ff3894f03d963","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"},{"line_number":23,"context_line":"user sees a downtime here, even other nodes are still running."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_45b7e8d7","line":21,"in_reply_to":"1a6eadb0_db020c09","updated":"2016-12-14 15:33:31.000000000","message":"We\u0027re trying to reduce this downtime to zero with buffering layer.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":22582,"name":"Duong Ha-Quang","email":"quangduongha@gmail.com","username":"duonghq"},"change_message_id":"be3df6923a97549195a32be2287fb9f468e25a4c","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"},{"line_number":23,"context_line":"user sees a downtime here, even other nodes are still running."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_3aaa63d5","line":21,"in_reply_to":"3a71b18c_1ac26fe9","updated":"2016-12-13 00:38:05.000000000","message":"You described zero-downtime on behalf of HAProxy, which mean services must have native zero-downtime upgrade support. The bp I\u0027m proposing is targeted to zero-downtime upgrade even when services do not have native zero-downtime upgrade ability.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":14119,"name":"Sam Yaple","email":"sam+git@yaple.net","username":"SamYaple"},"change_message_id":"236f5d08ac438f4706e51081f89e0a7f003c01ae","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"},{"line_number":23,"context_line":"user sees a downtime here, even other nodes are still running."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_1ac26fe9","line":21,"in_reply_to":"3a71b18c_83a4614b","updated":"2016-12-12 11:31:37.000000000","message":"You are wrong, what i just described is zero downtime.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":22582,"name":"Duong Ha-Quang","email":"quangduongha@gmail.com","username":"duonghq"},"change_message_id":"ad0fee1c0cc70cb9630fa292341fbb43e4cd487d","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Secondly, in Kolla (especially Kolla-Ansible), every services are put behind"},{"line_number":20,"context_line":"HAProxy. So even in best case that some services support rolling upgrade (in"},{"line_number":21,"context_line":"which at some point we need to put some nodes down), but there is still a"},{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"},{"line_number":23,"context_line":"user sees a downtime here, even other nodes are still running."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_83a4614b","line":21,"in_reply_to":"3a71b18c_8fd3aa37","updated":"2016-12-12 10:13:36.000000000","message":"It will reduce the downtime but the goal of this bp is zero-downtime upgrade.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":7488,"name":"Jeffrey Zhang","email":"zhang.lei.fly@gmail.com","username":"Jeffrey4l"},"change_message_id":"7ac65d506ea6fc35d49f29cc23fb3146bd674cd0","unresolved":false,"context_lines":[{"line_number":36,"context_line":"progress and disable afterthat. Users will meet some delay while sending"},{"line_number":37,"context_line":"requests to OpenStack services but no downtime happen."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"2. Adding buffer layer for Message Queue."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"3. Upgrading process can consume lots of time in case of very big database. So"},{"line_number":42,"context_line":"this buffer layer solution is the first step to solve the problem of upgrading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_8591179c","line":39,"updated":"2016-12-14 08:18:52.000000000","message":"how?","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":22582,"name":"Duong Ha-Quang","email":"quangduongha@gmail.com","username":"duonghq"},"change_message_id":"50ddc53f128a4a5984846b6e5b1ff3894f03d963","unresolved":false,"context_lines":[{"line_number":36,"context_line":"progress and disable afterthat. Users will meet some delay while sending"},{"line_number":37,"context_line":"requests to OpenStack services but no downtime happen."},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"2. Adding buffer layer for Message Queue."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"3. Upgrading process can consume lots of time in case of very big database. So"},{"line_number":42,"context_line":"this buffer layer solution is the first step to solve the problem of upgrading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_653b049d","line":39,"in_reply_to":"1a6eadb0_8591179c","updated":"2016-12-14 15:33:31.000000000","message":"I\u0027m figuring out how to do this.","commit_id":"75c350b9604bb273b6db2153a918e719bba57ad8"},{"author":{"_account_id":23717,"name":"Surya Prakash Singh","email":"singh.surya64mnnit@gmail.com","username":"SuryaPrakash"},"change_message_id":"8d80a3dec3c5ce5db5c6cba1c1bee5d16d3c6d95","unresolved":false,"context_lines":[{"line_number":4,"context_line":""},{"line_number":5,"context_line":"OpenStack services rolling upgrade and zero-downtime upgrade implementation"},{"line_number":6,"context_line":"status is varied between services and it is still in active development."},{"line_number":7,"context_line":"Currently, Kolla only implements upgrade mechanism from services."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"As deployment tool, Kolla should support fully upgrade, capture and bring"},{"line_number":10,"context_line":"avalability of service to higher degree."}],"source_content_type":"text/x-rst","patch_set":5,"id":"dfeb2761_d5b76ed8","line":7,"range":{"start_line":7,"start_character":0,"end_line":7,"end_character":65},"updated":"2017-03-31 05:07:29.000000000","message":"Their is no tracking information of how many services kolla implemente upgrade mechanism, So it would be better if put services names here.","commit_id":"a8c38538c3103035c7291cb587689b1a0e0687c0"},{"author":{"_account_id":22582,"name":"Duong Ha-Quang","email":"quangduongha@gmail.com","username":"duonghq"},"change_message_id":"5df9401ad7359c7aa4dd8fd960aeb4a7803da045","unresolved":false,"context_lines":[{"line_number":4,"context_line":""},{"line_number":5,"context_line":"OpenStack services rolling upgrade and zero-downtime upgrade implementation"},{"line_number":6,"context_line":"status is varied between services and it is still in active development."},{"line_number":7,"context_line":"Currently, Kolla only implements upgrade mechanism from services."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"As deployment tool, Kolla should support fully upgrade, capture and bring"},{"line_number":10,"context_line":"avalability of service to higher degree."}],"source_content_type":"text/x-rst","patch_set":5,"id":"5f93b717_5119edd4","line":7,"range":{"start_line":7,"start_character":0,"end_line":7,"end_character":65},"in_reply_to":"dfeb2761_d5b76ed8","updated":"2018-01-26 07:35:14.000000000","message":"We have upgrade action on every service, but it\u0027s offline upgrade and a few services in bp/apply-service-upgrade-procedure has rolling/minimal downtime/zero downtime upgrade capability from service itself.","commit_id":"a8c38538c3103035c7291cb587689b1a0e0687c0"},{"author":{"_account_id":23717,"name":"Surya Prakash Singh","email":"singh.surya64mnnit@gmail.com","username":"SuryaPrakash"},"change_message_id":"8d80a3dec3c5ce5db5c6cba1c1bee5d16d3c6d95","unresolved":false,"context_lines":[{"line_number":6,"context_line":"status is varied between services and it is still in active development."},{"line_number":7,"context_line":"Currently, Kolla only implements upgrade mechanism from services."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"As deployment tool, Kolla should support fully upgrade, capture and bring"},{"line_number":10,"context_line":"avalability of service to higher degree."},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dfeb2761_15c5d63c","line":9,"range":{"start_line":9,"start_character":0,"end_line":9,"end_character":18},"updated":"2017-03-31 05:07:29.000000000","message":"*As a deployment tool*","commit_id":"a8c38538c3103035c7291cb587689b1a0e0687c0"},{"author":{"_account_id":23717,"name":"Surya Prakash Singh","email":"singh.surya64mnnit@gmail.com","username":"SuryaPrakash"},"change_message_id":"8d80a3dec3c5ce5db5c6cba1c1bee5d16d3c6d95","unresolved":false,"context_lines":[{"line_number":22,"context_line":"chance HAProxy does not realize that current node is down when upgrading, so"},{"line_number":23,"context_line":"user sees a downtime here, even other nodes are still running."},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Thirdly, as the deployment tool, users need Kolla fully supporting the"},{"line_number":26,"context_line":"rolling-upgrade features from OpenStack services and toward the zero-downtime"},{"line_number":27,"context_line":"goals. Currently, because OpenStack services are in development for"},{"line_number":28,"context_line":"rolling-upgrade (with minimal downtime), so the total downtime of the whole"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dfeb2761_b50aaa87","line":25,"range":{"start_line":25,"start_character":9,"end_line":25,"end_character":31},"updated":"2017-03-31 05:07:29.000000000","message":"*As a deployment tool*","commit_id":"a8c38538c3103035c7291cb587689b1a0e0687c0"},{"author":{"_account_id":23717,"name":"Surya Prakash Singh","email":"singh.surya64mnnit@gmail.com","username":"SuryaPrakash"},"change_message_id":"c21abafcad9cc9e4c61fb000df1dec5bbed9e963","unresolved":false,"context_lines":[{"line_number":29,"context_line":"OpenStack system deployed by Kolla is a gap we need to solve."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"Proposed change"},{"line_number":32,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"1. Adding buffer layer to HAProxy, this layer serves as HTTP(s) requests"},{"line_number":35,"context_line":"buffering, storing requests in memory. Buffering can be enabled in upgrading"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5f93b717_16aa57d1","line":32,"range":{"start_line":32,"start_character":15,"end_line":32,"end_character":16},"updated":"2018-01-28 06:15:21.000000000","message":"nit, on extra underline mark;)","commit_id":"b6cfc2b3c446296aa509adbd4b1d3101234c3661"},{"author":{"_account_id":22629,"name":"Michal Nasiadka","email":"mnasiadka@gmail.com","username":"mnasiadka"},"change_message_id":"3b196ad10b620fb87574bf74344d0d12451c927d","unresolved":false,"context_lines":[{"line_number":115,"context_line":"----------"},{"line_number":116,"context_line":"1. Containerize buffering layer"},{"line_number":117,"context_line":"2. Implement buffer deployment and control mechanism in Ansible"},{"line_number":118,"context_line":"3. Implement buffer deployment and control mechanism in Kubernetes"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Documentation Impact"},{"line_number":121,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_5103ef0d","line":118,"updated":"2018-08-09 14:30:23.000000000","message":"Is this part of retired kolla-kubernetes or is it an openstack-helm goal?","commit_id":"844932816094f990af2ae78b3f375fe2e9f2afb5"},{"author":{"_account_id":28614,"name":"jacky06","email":"zhang.min@99cloud.net","username":"jacky06"},"change_message_id":"db2cd8a3288a96ee1e3d6d8c96f436cd52b22f90","unresolved":false,"context_lines":[{"line_number":115,"context_line":"----------"},{"line_number":116,"context_line":"1. Containerize buffering layer"},{"line_number":117,"context_line":"2. Implement buffer deployment and control mechanism in Ansible"},{"line_number":118,"context_line":"3. Implement buffer deployment and control mechanism in Kubernetes"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Documentation Impact"},{"line_number":121,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_bc56a529","line":118,"in_reply_to":"3f79a3b5_5103ef0d","updated":"2018-08-12 23:30:19.000000000","message":"kolla-kubenetes has beed retired, so do we really need this work itmes?","commit_id":"844932816094f990af2ae78b3f375fe2e9f2afb5"},{"author":{"_account_id":28614,"name":"jacky06","email":"zhang.min@99cloud.net","username":"jacky06"},"change_message_id":"1fad1919d1deaa2782435e42e79ac785638155ab","unresolved":false,"context_lines":[{"line_number":115,"context_line":"----------"},{"line_number":116,"context_line":"1. Containerize buffering layer"},{"line_number":117,"context_line":"2. Implement buffer deployment and control mechanism in Ansible"},{"line_number":118,"context_line":"3. Implement buffer deployment and control mechanism in Kubernetes"},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Documentation Impact"},{"line_number":121,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f79a3b5_7c324d12","line":118,"in_reply_to":"3f79a3b5_bc56a529","updated":"2018-08-12 23:31:54.000000000","message":"sorry I missing the comment, this ps LGTM now","commit_id":"844932816094f990af2ae78b3f375fe2e9f2afb5"}]}