Skip to content
Snippets Groups Projects
  • Ken Wronkiewicz's avatar
    cc415029
    Fix intf address for RabbitMQ and disable cluster for Kube · cc415029
    Ken Wronkiewicz authored
    
    enable_rabbitmq_cluster is now a "yes" by default but you can set it
    to "no" if you want to disable clustering under any circumstances.
    
    The agreement made at OpenStack in Austin was that Kolla-Kubernetes
    would concentrate on RabbitMQ and MariaDB without clustering but
    with persistent storage and workload migration, then examine how to
    do proper distributed functionality as the project progresses, so I
    am just following what we'd already agreed upon.
    
    First, it helps us deal with issues of version upgrades without
    dealing with clustered version upgrades and the synchronization
    thereof.
    
    Second, it provides an alternative model for durability when used in
    Kubernetes.  Understand that, if we disable RabbitMQ's clustering,
    Kubernetes is still able to re-schedule the queue off of a failed node
    in ways that Kolla-Ansible is not.  There are known issues with
    RabbitMQ clustering, especially with auto-heal turned on.  For many
    small-to-mid-sized clusters, it's going to provide for a better
    operator experience to have the known potential for a 30 second blip
    after RabbitMQ node failure than it is to have the known potential
    for partition and data loss and/or manual operations after you've
    turned off auto-heal.
    
    Kolla-kubernetes has already turned off host networking for the
    RabbitMQ pod; it's safe to set the interface address in the
    Kubernetes context.
    
    The question was asked why don't I just set the RabbitMQ cluster to be
    a single instance.  It's unlikely that Kubernetes RabbitMQ with a
    PetSet will be clustered in the same declaritive fashion as the
    rabbitmq-clusterer plugin. Easier to just disable it and worry about
    how to configure the kube-friendly clustered RabbitMQ at a later point
    in time.  Furthermore, it's an entirely valid case for many OpenStack
    control planes hosted atop Kolla-Kubernetes to accept the possibility
    of a 30-60 second blip in lieu of the long and questionable history
    of RabbitMQ clustering in production.
    
    Co-authored-by: default avatarRyan Hallisey <rhallise@redhat.com>
    Change-Id: I7f0cb22d29a418fce4af8d69f63739859173d746
    Partially-implements: blueprint api-interface-bind-address-override
    cc415029
    History
    Fix intf address for RabbitMQ and disable cluster for Kube
    Ken Wronkiewicz authored
    
    enable_rabbitmq_cluster is now a "yes" by default but you can set it
    to "no" if you want to disable clustering under any circumstances.
    
    The agreement made at OpenStack in Austin was that Kolla-Kubernetes
    would concentrate on RabbitMQ and MariaDB without clustering but
    with persistent storage and workload migration, then examine how to
    do proper distributed functionality as the project progresses, so I
    am just following what we'd already agreed upon.
    
    First, it helps us deal with issues of version upgrades without
    dealing with clustered version upgrades and the synchronization
    thereof.
    
    Second, it provides an alternative model for durability when used in
    Kubernetes.  Understand that, if we disable RabbitMQ's clustering,
    Kubernetes is still able to re-schedule the queue off of a failed node
    in ways that Kolla-Ansible is not.  There are known issues with
    RabbitMQ clustering, especially with auto-heal turned on.  For many
    small-to-mid-sized clusters, it's going to provide for a better
    operator experience to have the known potential for a 30 second blip
    after RabbitMQ node failure than it is to have the known potential
    for partition and data loss and/or manual operations after you've
    turned off auto-heal.
    
    Kolla-kubernetes has already turned off host networking for the
    RabbitMQ pod; it's safe to set the interface address in the
    Kubernetes context.
    
    The question was asked why don't I just set the RabbitMQ cluster to be
    a single instance.  It's unlikely that Kubernetes RabbitMQ with a
    PetSet will be clustered in the same declaritive fashion as the
    rabbitmq-clusterer plugin. Easier to just disable it and worry about
    how to configure the kube-friendly clustered RabbitMQ at a later point
    in time.  Furthermore, it's an entirely valid case for many OpenStack
    control planes hosted atop Kolla-Kubernetes to accept the possibility
    of a 30-60 second blip in lieu of the long and questionable history
    of RabbitMQ clustering in production.
    
    Co-authored-by: default avatarRyan Hallisey <rhallise@redhat.com>
    Change-Id: I7f0cb22d29a418fce4af8d69f63739859173d746
    Partially-implements: blueprint api-interface-bind-address-override