)]}'
{"specs/generic-config.rst":[{"author":{"_account_id":21530,"name":"Mark Casey","email":"mark.casey@moddulo.us","username":"mark-casey"},"change_message_id":"b009439b940f5b567e95744d73c55f78a30b347a","unresolved":false,"context_lines":[{"line_number":27,"context_line":"proper distributed functionality as the project progresses."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"Even after Kolla-kubernetes is able to use RabbitMQ and MariaDB clustering,"},{"line_number":30,"context_line":"many operators may choose to disable clustering in production because the"},{"line_number":31,"context_line":"30-60 second blip as Kubernetes reschedules the containers is acceptible"},{"line_number":32,"context_line":"compared to the known hazards of clustered RabbitMQ and MariaDB experienced in"},{"line_number":33,"context_line":"production."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Furthermore, after Kolla-kubernetes is set up to use RabbitMQ and MariaDB"},{"line_number":36,"context_line":"clustering, it is unlikely that the configuration mechanism or clustering"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aa78d24_49592d5b","line":33,"range":{"start_line":30,"start_character":29,"end_line":33,"end_character":11},"updated":"2016-07-13 01:13:58.000000000","message":"I always feel obliged to say the single-node model gives me worries on scalability. (I\u0027m not at this scale personally but) I\u0027ve heard repeatedly that messaging and DB are already the two components that will break down first under increased load. So I worry what it will do to both remove clustering and add the overhead of distributed storage.","commit_id":"bce6ca95e39ffaefe705bec0e7d9abe95e13d0ca"},{"author":{"_account_id":19384,"name":"Serguei Bezverkhi","email":"sbezverk@cisco.com","username":"sbezverk"},"change_message_id":"f3f4cd1c623a3b0ca8b69994629129289b9d6e08","unresolved":false,"context_lines":[{"line_number":44,"context_line":"---------"},{"line_number":45,"context_line":"1. Configuring Kolla-ansible containers as always"},{"line_number":46,"context_line":"2. Configuring Kolla-kubernetes containers without clustering"},{"line_number":47,"context_line":"3. Configuring Kolla-kubernetes containers with clustering"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed change"},{"line_number":50,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aa78d24_25383d3d","line":47,"range":{"start_line":47,"start_character":3,"end_line":47,"end_character":58},"updated":"2016-07-09 13:21:22.000000000","message":"Is it really required or even possible in Kubernetes? For one: kube is already a cluster and offers high availability, and two: kube uses such dynamic networking model that discovering peers, replicating data or using shared storage backend between clustered pods/applications might be complex and prone to issues. Maybe we should keep just two cases, first and second.","commit_id":"bce6ca95e39ffaefe705bec0e7d9abe95e13d0ca"},{"author":{"_account_id":21530,"name":"Mark Casey","email":"mark.casey@moddulo.us","username":"mark-casey"},"change_message_id":"b009439b940f5b567e95744d73c55f78a30b347a","unresolved":false,"context_lines":[{"line_number":44,"context_line":"---------"},{"line_number":45,"context_line":"1. Configuring Kolla-ansible containers as always"},{"line_number":46,"context_line":"2. Configuring Kolla-kubernetes containers without clustering"},{"line_number":47,"context_line":"3. Configuring Kolla-kubernetes containers with clustering"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed change"},{"line_number":50,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aa78d24_bbd257fe","line":47,"range":{"start_line":47,"start_character":3,"end_line":47,"end_character":58},"in_reply_to":"1aa78d24_25383d3d","updated":"2016-07-13 01:13:58.000000000","message":"I think the third option will be highly desirable later and is definitely possible. There are already two Galera examples in repos in the K8s GitHub Org/account and they don\u0027t even take advantage of the last few K8s releases yet.\n\nRemember MariaDB+Galera itself does not handle HA in kolla-ansible anyway, haproxy does. Even though the db nodes(/containers) replicate our MySQL statements between themselves via Galera, if it weren\u0027t for keepalived and haproxy we\u0027d still use non-HA addresses. If the db node we were sending statements to went down then the whole database would be effectively down until we manually switch to using another healthy node. That\u0027s not very HA. So in this sense, K8s\u0027 service discovery and health checking replace haproxy (not Galera), and provide a great overlay for finding the next healthy db node. The service discovery also makes it easier and more dynamic for the nodes to find one another with DNS than in kolla-ansible where we hardcode IPs.\n\nFor storage, consider in kolla-ansible what would happen if you add one physical host to the \u0027control\u0027 group and take another out. You just run reconfigure and it doesn\u0027t care about the previous hardware node\u0027s db container. IMHO k8s would be no different if we set the db pods to emtpyDir persistence. In both cases if all nodes/pods are removed, you have to restore from backup. If kolla-k8s truly requires shared storage to cluster the db, it makes me wonder if the ability to replace hardware in kolla-ansible is broken (without backing up and restoring storage from the old/failed hardware).","commit_id":"bce6ca95e39ffaefe705bec0e7d9abe95e13d0ca"},{"author":{"_account_id":21530,"name":"Mark Casey","email":"mark.casey@moddulo.us","username":"mark-casey"},"change_message_id":"b009439b940f5b567e95744d73c55f78a30b347a","unresolved":false,"context_lines":[{"line_number":50,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"1. Variables that were previously lookups to the Ansible inventory will be"},{"line_number":53,"context_line":"   replaced by set_fact tasks in the least-generic role possible for that"},{"line_number":54,"context_line":"   variable (e.g. interface address needs to be in common, RabbitMQ specific"},{"line_number":55,"context_line":"   variablees in rabbimq)."},{"line_number":56,"context_line":"2. Clustering will be disabled on a per-service level with boolean variables,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aa78d24_e88cc5d8","line":53,"range":{"start_line":53,"start_character":15,"end_line":53,"end_character":64},"updated":"2016-07-13 01:13:58.000000000","message":"This may restrict ordering a bit by not being able to use a var until you\u0027ve reached its role in the deploy, but it isn\u0027t necessarily unworkable. Probably depends on how Ansible currently is handling access to inventory-sourced hostvars of hosts that have not yet been targeted in a play.\n\nCompletely hypothetically... if today the common role was what told physical hosts where to find centralized logging using a var from inventory, and the role that configures centralize logging was right after common, you would have to switch these roles so that the set_fact tasks added to centralized logging role will have already run and be available to hosts applying the common role.\n\nIf there is a situation like this and you move the role before common and it also needs something that\u0027s done in common then it becomes a kind of chicken and egg thing to solve.\n\nWith some caution Ansible\u0027s fact caching may allow you to set some things up in a pre-run.","commit_id":"bce6ca95e39ffaefe705bec0e7d9abe95e13d0ca"},{"author":{"_account_id":21530,"name":"Mark Casey","email":"mark.casey@moddulo.us","username":"mark-casey"},"change_message_id":"b009439b940f5b567e95744d73c55f78a30b347a","unresolved":false,"context_lines":[{"line_number":53,"context_line":"   replaced by set_fact tasks in the least-generic role possible for that"},{"line_number":54,"context_line":"   variable (e.g. interface address needs to be in common, RabbitMQ specific"},{"line_number":55,"context_line":"   variablees in rabbimq)."},{"line_number":56,"context_line":"2. Clustering will be disabled on a per-service level with boolean variables,"},{"line_number":57,"context_line":"   set by default to on, able to be set to off in globals.yml"},{"line_number":58,"context_line":"3. Clustering-related components will be wrappered as blocks [1] in the"},{"line_number":59,"context_line":"   configuration files so that Kolla-kubernetes can be used to generate"},{"line_number":60,"context_line":"   templates from the Kolla-ansible template files without adding extensive"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1aa78d24_49e2cd02","line":57,"range":{"start_line":56,"start_character":0,"end_line":57,"end_character":61},"updated":"2016-07-13 01:13:58.000000000","message":"For the DB could we do a dynamic default based on the length of the Ansible group for the database (still able to be overridden)? Something like:\n\n\u003e set_fact: db_cluster\u003dtrue\n\u003e when: dbgroup|length \u003e 1 and db_cluster not defined\n\u003e  \n\u003e set_fact: db_cluster\u003dfalse\n\u003e when: dbgroup|length \u003d\u003d 1 and db_cluster not defined\n\nAlso, note this from MariaDB 10.1.1 release notes here[1]:\n\n\u003e Unlike older MariaDB versions, the wsrep patch is now part of regular (vanilla) MariaDB 10.1 server, that is, with 10.1.1 there would be no separate vanilla and Galera server versions. As a result, same 10.1 packages (binary tarballs, deb, rpm, etc.) can now be used to run MariaDB server as standalone server or a node in MariaDB Galera cluster.\n\nThe thing is we don\u0027t really have a non-clustered (db) mode right now to enable based on this option. Kolla\u0027s mariadb containers use packages for version 10.0 with the Galera patch always on, and kolla-ansible passes the --wsrep-new-cluster flag (even in AIO) at container bootstrap, when starting the first node during a deploy, and also during lights-out recovery. AFAIK kolla-k8s only passes the flag at bootstrap (or sort of inherits it), but if K8s has to restart the db pod it will run auto-recovery of the cluster every time.\n\nSo solutions... Truly disabling the clustering is a combination of adding code-paths in bootstrap and deploy to not pass the --wsrep-new-cluster flag (with minor other tweaks like making lights-out refuse to work on AIO), and then either change to installing different 10.0 packages for clustered and non-clustered container images, or upgrading to 10.1 to get the universal galera/vanilla packages.\n\nIf we do chose to upgrade to 10.1 to get the universal packages, we need to either get the upgrade to work in a rolling fashion or handle that \u0027kolla-ansible upgrade\u0027 currently (apparently) cannot handle full cluster stop during upgrade (see commit message here [2]).\n\n[1] - https://mariadb.org/mariadb-10-1-1-galera-support/\n[2] - https://review.openstack.org/#/c/293162/","commit_id":"bce6ca95e39ffaefe705bec0e7d9abe95e13d0ca"},{"author":{"_account_id":19384,"name":"Serguei Bezverkhi","email":"sbezverk@cisco.com","username":"sbezverk"},"change_message_id":"c72990d3d5c166882b7825113ecdc3dd75cd684b","unresolved":false,"context_lines":[{"line_number":55,"context_line":"1. Variables that were previously lookups to the Ansible inventory will be"},{"line_number":56,"context_line":"   replaced by set_fact tasks in the least-generic role possible for that"},{"line_number":57,"context_line":"   variable (e.g. interface address needs to be in common, RabbitMQ specific"},{"line_number":58,"context_line":"   variables can be within the RabbitMQ role as long as they wouldn\u0027t be "},{"line_number":59,"context_line":"   used by other roles)."},{"line_number":60,"context_line":"2. Clustering will be disabled on a per-service level with boolean variables,"},{"line_number":61,"context_line":"   set by default to on, able to be set to off in globals.yml"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dada55a8_4aef1d87","line":58,"range":{"start_line":58,"start_character":67,"end_line":58,"end_character":73},"updated":"2016-07-19 21:21:57.000000000","message":"whitespace","commit_id":"00fd136bd86ec14c003a02627b16b3c47fd15969"}]}