I definitely would push for prioritization on this.
Our main use case is less about multiple racks and failure, and more about functionality during the install process. Our clusters are installed in logical regions, and we install 1/3 of a region at a time. That means 1/3 of the cluster can be down for the SW install, reboot, or something else. Allowing rack locality to be logically defined will allow the data to still be available during normal maintenance operations. -- Rick Weber From: Todd Lipcon <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Friday, February 10, 2017 at 12:45 PM To: "[email protected]" <[email protected]> Subject: Re: Feature request for Kudu 1.3.0 Hi Jeff, Thanks for the input on prioritization. I'm curious: do you have more than two racks in your cluster? With Kudu's replication strategy, we need at least three racks to be able to survive a full rack outage. (with just two racks it's impossible to distinguish a loss of a rack with a partition between the two racks). -Todd On Fri, Feb 10, 2017 at 7:27 AM, Jeff Dasch <[email protected]> wrote: Any chance we can get a fix for KUDU-1535 "Add rack awareness" added to the 1.3.0 release? While I appreciate the need for Kerberos and TLS for some production systems, for my use-case data availability really takes priority. I looked at your scoping document, and for what it's worth, I'm fine with a shell script that is similar to what Hadoop uses. thanks, -jeff -- Todd Lipcon Software Engineer, Cloudera
smime.p7s
Description: S/MIME cryptographic signature
