)]}'
{"specs/ocata/improve-ha-guide.rst":[{"author":{"_account_id":14870,"name":"Ben Silverman","email":"ben.silverman@onx.com","username":"tersian"},"change_message_id":"1da69297b67787fa4e7b0616210c038489be9772","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Firstly, reach consensus on the intended audience and high-level use cases"},{"line_number":20,"context_line":"for the guide:"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"* As a cloud deployer, I need an OpenStack HA guide so that I can understand"},{"line_number":23,"context_line":"  both the architectural principles behind building an HA OpenStack cloud,"},{"line_number":24,"context_line":"  and the concrete steps involved in an implementation."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* As a cloud operator, I need an OpenStack HA guide so that I can understand"},{"line_number":27,"context_line":"  how an existing HA OpenStack cloud works and what is required for its"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_07714b76","line":24,"range":{"start_line":22,"start_character":0,"end_line":24,"end_character":55},"updated":"2016-12-11 23:12:20.000000000","message":"Unless there is a compelling reason to split this architecture up as a separate guide, I believe users should be using the Arch-guide as a reference for architecture, therefore I believe this user story should be under the architecture guide. Since I would like to believe that most deployments outside of PoC and the devstack/packstack realm are HA anyway, I would think HA of the stateful services should be the default recommendation with non-HA only mentioned as a test environment or other special use cases where complete failure is non-impacting","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":17517,"name":"Andrew Beekhof","email":"abeekhof@redhat.com","username":"beekhof"},"change_message_id":"393cd0728fefcaa1bd88ea7951205d9848647137","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Firstly, reach consensus on the intended audience and high-level use cases"},{"line_number":20,"context_line":"for the guide:"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"* As a cloud deployer, I need an OpenStack HA guide so that I can understand"},{"line_number":23,"context_line":"  both the architectural principles behind building an HA OpenStack cloud,"},{"line_number":24,"context_line":"  and the concrete steps involved in an implementation."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* As a cloud operator, I need an OpenStack HA guide so that I can understand"},{"line_number":27,"context_line":"  how an existing HA OpenStack cloud works and what is required for its"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_94b99031","line":24,"range":{"start_line":22,"start_character":0,"end_line":24,"end_character":55},"in_reply_to":"1a6eadb0_25ca50a2","updated":"2016-12-12 23:29:33.000000000","message":"I agree that, at least in short-term, the HA Guide is the best location for this.\n\nI would expect that a lot of the content will mostly concern:\n- topics considered too esoteric or pedantic to be worth confusing readers of the main guide with\n- components that OpenStack sits on top of rather than OpenStack itself (and therefor \"someone else\u0027s problem\")\n- components for which many people have different ideas on the OneTrueWay to deploy.  Putting any one way into the main guide would likely be contentious, precisely because it is the main guide.  Whereas I think the HA guide can afford to be a bit more opinionated.\n\nPerhaps I am mistaken though.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"617d2c5c47447f2fe6ff86b724b2457e5622ff86","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Firstly, reach consensus on the intended audience and high-level use cases"},{"line_number":20,"context_line":"for the guide:"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"* As a cloud deployer, I need an OpenStack HA guide so that I can understand"},{"line_number":23,"context_line":"  both the architectural principles behind building an HA OpenStack cloud,"},{"line_number":24,"context_line":"  and the concrete steps involved in an implementation."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* As a cloud operator, I need an OpenStack HA guide so that I can understand"},{"line_number":27,"context_line":"  how an existing HA OpenStack cloud works and what is required for its"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_c2590137","line":24,"range":{"start_line":22,"start_character":0,"end_line":24,"end_character":55},"in_reply_to":"3a71b18c_07714b76","updated":"2016-12-12 00:45:51.000000000","message":"That\u0027s a good point - so you are suggesting that this aspect of the HA guide\u0027s content should be moved to the arch-guide?  That\u0027s quite a big change but to me I think it sounds like it might be the right thing to do, since the HA aspects of designing the cloud architecture cannot be considered independently of the other architectural decisions.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":9162,"name":"Lana Brindley","email":"openstack@lanabrindley.com","username":"loquacity"},"change_message_id":"8689495e92b2f5891a1af566c783a6175bcb8f18","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Firstly, reach consensus on the intended audience and high-level use cases"},{"line_number":20,"context_line":"for the guide:"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"* As a cloud deployer, I need an OpenStack HA guide so that I can understand"},{"line_number":23,"context_line":"  both the architectural principles behind building an HA OpenStack cloud,"},{"line_number":24,"context_line":"  and the concrete steps involved in an implementation."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* As a cloud operator, I need an OpenStack HA guide so that I can understand"},{"line_number":27,"context_line":"  how an existing HA OpenStack cloud works and what is required for its"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_25ca50a2","line":24,"range":{"start_line":22,"start_character":0,"end_line":24,"end_character":55},"in_reply_to":"3a71b18c_c2590137","updated":"2016-12-12 21:05:06.000000000","message":"I\u0027m not sure the Arch Guide is in a state where we can confidently say that it covers this. For that reason, I think the content needs to be created in the HA Guide for now, even if we end up moving it to the Arch Guide later on.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"cc63f7a8a29e03286e617d6fa07866c53b1d0194","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Firstly, reach consensus on the intended audience and high-level use cases"},{"line_number":20,"context_line":"for the guide:"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"* As a cloud deployer, I need an OpenStack HA guide so that I can understand"},{"line_number":23,"context_line":"  both the architectural principles behind building an HA OpenStack cloud,"},{"line_number":24,"context_line":"  and the concrete steps involved in an implementation."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* As a cloud operator, I need an OpenStack HA guide so that I can understand"},{"line_number":27,"context_line":"  how an existing HA OpenStack cloud works and what is required for its"},{"line_number":28,"context_line":"  maintenance."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Based on that consensus, this spec proposes that the HA guide aims to define,"},{"line_number":31,"context_line":"justify, and explain a high level architecture for a highly available setup"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_7d7a96f2","line":28,"range":{"start_line":22,"start_character":0,"end_line":28,"end_character":14},"updated":"2016-12-11 11:24:00.000000000","message":"Sorry - even though I wrote this text myself, I just discovered that it should probably refer to the new official personas:\n\nhttp://docs.openstack.org/contributor-guide/ux-ui-guidelines/ux-personas.html\n\nIn this case, both the \"cloud deployer\" and \"cloud operator\" should actually be replaced with references to Adrian the infrastructure architect and probably also Rey the cloud operator.  Thoughts?","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":14870,"name":"Ben Silverman","email":"ben.silverman@onx.com","username":"tersian"},"change_message_id":"1da69297b67787fa4e7b0616210c038489be9772","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  both the architectural principles behind building an HA OpenStack cloud,"},{"line_number":24,"context_line":"  and the concrete steps involved in an implementation."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* As a cloud operator, I need an OpenStack HA guide so that I can understand"},{"line_number":27,"context_line":"  how an existing HA OpenStack cloud works and what is required for its"},{"line_number":28,"context_line":"  maintenance."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Based on that consensus, this spec proposes that the HA guide aims to define,"},{"line_number":31,"context_line":"justify, and explain a high level architecture for a highly available setup"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_27e56737","line":28,"range":{"start_line":26,"start_character":0,"end_line":28,"end_character":14},"updated":"2016-12-11 23:12:20.000000000","message":"The same argument applies here. Why wouldn\u0027t there simply be a section, or highlights to a section that reference \"if you are running OpenStack in an HA architecture, you should....\" Of course, this argument also runs counter to itself if the content is large and complex enough that it would need its own HA Ops guide.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"617d2c5c47447f2fe6ff86b724b2457e5622ff86","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  both the architectural principles behind building an HA OpenStack cloud,"},{"line_number":24,"context_line":"  and the concrete steps involved in an implementation."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* As a cloud operator, I need an OpenStack HA guide so that I can understand"},{"line_number":27,"context_line":"  how an existing HA OpenStack cloud works and what is required for its"},{"line_number":28,"context_line":"  maintenance."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Based on that consensus, this spec proposes that the HA guide aims to define,"},{"line_number":31,"context_line":"justify, and explain a high level architecture for a highly available setup"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_6283cd56","line":28,"range":{"start_line":26,"start_character":0,"end_line":28,"end_character":14},"in_reply_to":"3a71b18c_27e56737","updated":"2016-12-12 00:45:51.000000000","message":"Where does \"a section, or highlights to a section\" refer to - the ops guide, or the HA guide?\n\nI\u0027d say that HA operations are much more decoupled from normal operations than HA architecture / design is from the rest of architecture / design, but nevertheless still related.  So I don\u0027t know where is the best home for that topic.\n\nThe other consideration is that HA operations are quite highly dependent on the nature of the implementation (e.g. crmsh vs. pcs, number/size/shape of clusters, and so on).","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":14870,"name":"Ben Silverman","email":"ben.silverman@onx.com","username":"tersian"},"change_message_id":"25001fbcf635e9381386b52385947e28784ed924","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  both the architectural principles behind building an HA OpenStack cloud,"},{"line_number":24,"context_line":"  and the concrete steps involved in an implementation."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* As a cloud operator, I need an OpenStack HA guide so that I can understand"},{"line_number":27,"context_line":"  how an existing HA OpenStack cloud works and what is required for its"},{"line_number":28,"context_line":"  maintenance."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Based on that consensus, this spec proposes that the HA guide aims to define,"},{"line_number":31,"context_line":"justify, and explain a high level architecture for a highly available setup"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_f1a7a6b9","line":28,"range":{"start_line":26,"start_character":0,"end_line":28,"end_character":14},"in_reply_to":"3a71b18c_6283cd56","updated":"2016-12-12 04:51:00.000000000","message":"The \"section\" would be in the Ops guide. Both RHOSP and Mirantis (to date) both are using pacemaker and use a default of 3 servers in the production control \"cluster.\" Mirantis is making changes as well as Red Hat, so we\u0027ll see what the future brings for the commercial distributions.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"269303fba319da4c3cf3999495f6b6a6909d5d69","unresolved":false,"context_lines":[{"line_number":23,"context_line":"  both the architectural principles behind building an HA OpenStack cloud,"},{"line_number":24,"context_line":"  and the concrete steps involved in an implementation."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* As a cloud operator, I need an OpenStack HA guide so that I can understand"},{"line_number":27,"context_line":"  how an existing HA OpenStack cloud works and what is required for its"},{"line_number":28,"context_line":"  maintenance."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Based on that consensus, this spec proposes that the HA guide aims to define,"},{"line_number":31,"context_line":"justify, and explain a high level architecture for a highly available setup"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_4055d8bf","line":28,"range":{"start_line":26,"start_character":0,"end_line":28,"end_character":14},"in_reply_to":"3a71b18c_f1a7a6b9","updated":"2016-12-12 12:12:59.000000000","message":"Andrew and I are largely deciding the future HA architectures for Red Hat and SUSE respectively, which should help limit the amount of speculation needed here :-)  Can we also pull folks from Canonical, Mirantis, and others into this discussion?","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":14870,"name":"Ben Silverman","email":"ben.silverman@onx.com","username":"tersian"},"change_message_id":"1da69297b67787fa4e7b0616210c038489be9772","unresolved":false,"context_lines":[{"line_number":31,"context_line":"justify, and explain a high level architecture for a highly available setup"},{"line_number":32,"context_line":"which uses the Pacemaker cluster manager to provide:"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"    * Detection and recovery of machine and application-level failures"},{"line_number":35,"context_line":"    * Startup/shutdown ordering between applications"},{"line_number":36,"context_line":"    * Preferences for other applications that must/must-not run on the same"},{"line_number":37,"context_line":"      machine"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_a73ed788","line":34,"range":{"start_line":34,"start_character":44,"end_line":34,"end_character":61},"updated":"2016-12-11 23:12:20.000000000","message":"I\u0027m assuming you\u0027re referring to the stateful applications in the infrastructure. Workload HA is a whole different animal. I would be more clear here.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":14870,"name":"Ben Silverman","email":"ben.silverman@onx.com","username":"tersian"},"change_message_id":"25001fbcf635e9381386b52385947e28784ed924","unresolved":false,"context_lines":[{"line_number":31,"context_line":"justify, and explain a high level architecture for a highly available setup"},{"line_number":32,"context_line":"which uses the Pacemaker cluster manager to provide:"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"    * Detection and recovery of machine and application-level failures"},{"line_number":35,"context_line":"    * Startup/shutdown ordering between applications"},{"line_number":36,"context_line":"    * Preferences for other applications that must/must-not run on the same"},{"line_number":37,"context_line":"      machine"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_b188ce23","line":34,"range":{"start_line":34,"start_character":44,"end_line":34,"end_character":61},"in_reply_to":"3a71b18c_82ef091d","updated":"2016-12-12 04:51:00.000000000","message":"It\u0027s good that there\u0027s a separate section, bad that I couldn\u0027t tell the difference here. Maybe we can work on cleaning up the wording so it\u0027s less ambiguous in the blueprint.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"617d2c5c47447f2fe6ff86b724b2457e5622ff86","unresolved":false,"context_lines":[{"line_number":31,"context_line":"justify, and explain a high level architecture for a highly available setup"},{"line_number":32,"context_line":"which uses the Pacemaker cluster manager to provide:"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"    * Detection and recovery of machine and application-level failures"},{"line_number":35,"context_line":"    * Startup/shutdown ordering between applications"},{"line_number":36,"context_line":"    * Preferences for other applications that must/must-not run on the same"},{"line_number":37,"context_line":"      machine"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_82ef091d","line":34,"range":{"start_line":34,"start_character":44,"end_line":34,"end_character":61},"in_reply_to":"3a71b18c_a73ed788","updated":"2016-12-12 00:45:51.000000000","message":"Well, I didn\u0027t write that, but I would assume it refers at least to all control plane services, whether stateful (DB/MQ) or stateless (keystone etc.)  Granted, they would be better described as \"service-level failures\".\n\nHaving said that, the guide could eventually cover workload HA in detail too.  It can\u0027t currently because there\u0027s not enough upstream convergence, but this is already documented:\n\nhttp://docs.openstack.org/ha-guide/instance-ha.html","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":14870,"name":"Ben Silverman","email":"ben.silverman@onx.com","username":"tersian"},"change_message_id":"1da69297b67787fa4e7b0616210c038489be9772","unresolved":false,"context_lines":[{"line_number":33,"context_line":""},{"line_number":34,"context_line":"    * Detection and recovery of machine and application-level failures"},{"line_number":35,"context_line":"    * Startup/shutdown ordering between applications"},{"line_number":36,"context_line":"    * Preferences for other applications that must/must-not run on the same"},{"line_number":37,"context_line":"      machine"},{"line_number":38,"context_line":"    * Provably correct response to any failure or cluster state"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"The guide will aim to stay relevant across all distributions whilst not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_074a2b26","line":37,"range":{"start_line":36,"start_character":6,"end_line":37,"end_character":13},"updated":"2016-12-11 23:12:20.000000000","message":"Now I\u0027m confused, are you talking about anti-affinity of workloads or are you talking about splitting up the monolithic architecture and setting guidelines for non-affinity of those?","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"617d2c5c47447f2fe6ff86b724b2457e5622ff86","unresolved":false,"context_lines":[{"line_number":33,"context_line":""},{"line_number":34,"context_line":"    * Detection and recovery of machine and application-level failures"},{"line_number":35,"context_line":"    * Startup/shutdown ordering between applications"},{"line_number":36,"context_line":"    * Preferences for other applications that must/must-not run on the same"},{"line_number":37,"context_line":"      machine"},{"line_number":38,"context_line":"    * Provably correct response to any failure or cluster state"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"The guide will aim to stay relevant across all distributions whilst not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_a2f085fe","line":37,"range":{"start_line":36,"start_character":6,"end_line":37,"end_character":13},"in_reply_to":"3a71b18c_074a2b26","updated":"2016-12-12 00:45:51.000000000","message":"Again I didn\u0027t write this but I would assume it refers to affinity and anti-affinity between OpenStack infrastructure services in the control and compute plane.  I\u0027m not sure what you mean by monolithic architecture?  At least in the SUSE world there is a lot of flexibility around which services get deployed where, and I believe that (without claiming any expertise) that is also true for RHEL OSP, Fuel, and Juju to varying degrees.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":17517,"name":"Andrew Beekhof","email":"abeekhof@redhat.com","username":"beekhof"},"change_message_id":"393cd0728fefcaa1bd88ea7951205d9848647137","unresolved":false,"context_lines":[{"line_number":33,"context_line":""},{"line_number":34,"context_line":"    * Detection and recovery of machine and application-level failures"},{"line_number":35,"context_line":"    * Startup/shutdown ordering between applications"},{"line_number":36,"context_line":"    * Preferences for other applications that must/must-not run on the same"},{"line_number":37,"context_line":"      machine"},{"line_number":38,"context_line":"    * Provably correct response to any failure or cluster state"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"The guide will aim to stay relevant across all distributions whilst not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a6eadb0_59a3b19e","line":37,"range":{"start_line":36,"start_character":6,"end_line":37,"end_character":13},"in_reply_to":"3a71b18c_406b18b9","updated":"2016-12-12 23:29:33.000000000","message":"The monolithic nature of RH deployments is an (undesired) function of director, not something imposed by the underlying Pacemaker cluster.\n\nExpect to see this increasingly become an operator choice rather than a requirement or best practice in the near future.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":14870,"name":"Ben Silverman","email":"ben.silverman@onx.com","username":"tersian"},"change_message_id":"25001fbcf635e9381386b52385947e28784ed924","unresolved":false,"context_lines":[{"line_number":33,"context_line":""},{"line_number":34,"context_line":"    * Detection and recovery of machine and application-level failures"},{"line_number":35,"context_line":"    * Startup/shutdown ordering between applications"},{"line_number":36,"context_line":"    * Preferences for other applications that must/must-not run on the same"},{"line_number":37,"context_line":"      machine"},{"line_number":38,"context_line":"    * Provably correct response to any failure or cluster state"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"The guide will aim to stay relevant across all distributions whilst not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_d109ca96","line":37,"range":{"start_line":36,"start_character":6,"end_line":37,"end_character":13},"in_reply_to":"3a71b18c_a2f085fe","updated":"2016-12-12 04:51:00.000000000","message":"The monolithic HA control plane refers to the commonly used PCS cluster that has all control elements(or most) deployed in a configuration that includes the same control plane services spread across no less than 3 servers. These are then either balanced by HA elements in the stateful services and HAproxy or keepalived in the stateless ones. There are distributions that have now made moving some of the services off to additional bare metal part of their installers and there are other distributions looking to containerize and make the services fully distributed and scalable (kolla-ish). This will change HA methodologies to now focus more on the service and less on the server as well as strategies for auto scaling services that tend to become overwhelmed at scale. This will change the HA guide a little when this becomes a mainstream reality.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"269303fba319da4c3cf3999495f6b6a6909d5d69","unresolved":false,"context_lines":[{"line_number":33,"context_line":""},{"line_number":34,"context_line":"    * Detection and recovery of machine and application-level failures"},{"line_number":35,"context_line":"    * Startup/shutdown ordering between applications"},{"line_number":36,"context_line":"    * Preferences for other applications that must/must-not run on the same"},{"line_number":37,"context_line":"      machine"},{"line_number":38,"context_line":"    * Provably correct response to any failure or cluster state"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"The guide will aim to stay relevant across all distributions whilst not"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_406b18b9","line":37,"range":{"start_line":36,"start_character":6,"end_line":37,"end_character":13},"in_reply_to":"3a71b18c_d109ca96","updated":"2016-12-12 12:12:59.000000000","message":"By PCS cluster I assume you mean Pacemaker cluster?  FWIW pcs is CLI tool specific to RH and maybe a few other distros, which duplicates most of the functionality of the older crmsh CLI tool and (I think) adds some extra stuff although I don\u0027t know the details.\n\nWhilst monolithic Pacemaker clusters are common, in the SUSE world it is equally common for customers to deploy the control plane across multiple clusters, none of which are subject to the 3 server minimum you mention (we have mechanisms for defending against split brain).  And yes you are of course right that new architectures, some of which are container-based, are emerging.  These points both highlight the challenge here that HA architectures vary widely by vendor and by deployer - so how can we capture all this in the documentation accurately whilst avoiding an unreasonable increase in complexity and maintenance burden?  As a relative newbie to OpenStack documentation efforts I don\u0027t really know the answer :-/","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":14870,"name":"Ben Silverman","email":"ben.silverman@onx.com","username":"tersian"},"change_message_id":"1da69297b67787fa4e7b0616210c038489be9772","unresolved":false,"context_lines":[{"line_number":64,"context_line":"* Leave the guide as is, and have the community slowly work at it over"},{"line_number":65,"context_line":"  time."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Retire the guide, move relevant information to other guides and archive"},{"line_number":68,"context_line":"  it appropriately."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Implementation"},{"line_number":71,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_87647bb9","line":68,"range":{"start_line":67,"start_character":2,"end_line":68,"end_character":19},"updated":"2016-12-11 23:12:20.000000000","message":"I\u0027m on the fence about this one since the HA guide could be made as something special, especially if it is a technical deep dive or delves into the topic of workload HA, however, that has little to do with the infrastructure of an OpenStack cloud and is more of a topic for Nova/Cinder scheduler docs. If this guide is to simply summarize the architectural and operational HA knowledge of the monolithic control plane that exists today in most distributions, I think that it\u0027s made redundant by other guides and the relevant knowledge here should be parsed out the associated guides for the topics.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"},{"author":{"_account_id":2394,"name":"Adam Spiers","email":"aspiers@suse.com","username":"adam.spiers"},"change_message_id":"269303fba319da4c3cf3999495f6b6a6909d5d69","unresolved":false,"context_lines":[{"line_number":64,"context_line":"* Leave the guide as is, and have the community slowly work at it over"},{"line_number":65,"context_line":"  time."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"* Retire the guide, move relevant information to other guides and archive"},{"line_number":68,"context_line":"  it appropriately."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Implementation"},{"line_number":71,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a71b18c_20e37cda","line":68,"range":{"start_line":67,"start_character":2,"end_line":68,"end_character":19},"in_reply_to":"3a71b18c_87647bb9","updated":"2016-12-12 12:12:59.000000000","message":"Yeah, I think we really need to decide the goal of the guide before we can decide on this.\n\nAnd for reasons we\u0027ve both given above, I\u0027m a bit wary of assuming that \"monolithic control plane\" correctly characterizes a comfortably large percentage of all OpenStack clouds out there.  I suspect there\u0027s a lot of diversity.","commit_id":"9aeca7fe9e06d28f4eb990579f3339bca089f7a6"}]}