From user-return-11836-archive-asf-public=cust-asf.ponee.io@zookeeper.apache.org Tue Feb 12 11:44:19 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 7BC6A180675 for ; Tue, 12 Feb 2019 12:44:18 +0100 (CET) Received: (qmail 57969 invoked by uid 500); 12 Feb 2019 11:44:12 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 57952 invoked by uid 99); 12 Feb 2019 11:44:11 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Feb 2019 11:44:11 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 4E78ACB236 for ; Tue, 12 Feb 2019 11:44:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=cloudera.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id f1LfzegjGxKe for ; Tue, 12 Feb 2019 11:44:08 +0000 (UTC) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id DCD596110A for ; Tue, 12 Feb 2019 11:37:07 +0000 (UTC) Received: by mail-wm1-f49.google.com with SMTP id f16so2640795wmh.4 for ; Tue, 12 Feb 2019 03:37:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hxgVZhncS6bbGUrCVLruPnw7BCi7P4HfIdu+V/aMlIY=; b=nMSqbY/erbW5OlwzxLiyIswMCvsrHrvWf1voycof1x/lhGBlBcnDfWJJkHhAJjm6fR 3ZCTWXDqPV3Fsvqd7j2plturKHYpZVXDERafMqfQJc9QAc1QM19a+eZi0udfybjYHAdp FlLKNHux1lw9zYHXV6l2pPn2u+hnubTTe629i2kkzIJkiGiBFCIJA9PDBO1t9RqMdQLY 0HfRS6UAf2CYHgyRlWVFijjPiZVqGM6l/5YgENmRl4+Ic6sgbLnXqNmbicQZzdCNTZOn yVxt1lGvOt4a1vEcfd+NCWRgUXPCgB6ARkSMo5dfAmei0j6LCmtfKtqHTCzoMz/8V6qg l8Ew== X-Gm-Message-State: AHQUAua8U07E8AFvbsWPswZKxtr5CFaKMuZXJphON58qTcHilde9O+QY RCZoaVCPrRKZCY6YYtXqafkMLw4s0iz8gBQ7Twionexr X-Google-Smtp-Source: AHgI3Ia285c32bQGndFCllaSpiWYNb1bM4uhlZJRwok2ZhGTzsoE/8Zqk1/BlUzljVeBkJ+yTDZPV/TbX6dYaU+QCNY= X-Received: by 2002:a1c:1dd2:: with SMTP id d201mr2450302wmd.49.1549971427013; Tue, 12 Feb 2019 03:37:07 -0800 (PST) MIME-Version: 1.0 References: <9d214ee6-3ce4-edca-68d3-9f144f320b10@devoteam.com> In-Reply-To: From: Andor Molnar Date: Tue, 12 Feb 2019 12:36:56 +0100 Message-ID: Subject: Re: RR DNS name instead of list of server To: user@zookeeper.apache.org Content-Type: multipart/alternative; boundary="00000000000051eae30581b0d898" --00000000000051eae30581b0d898 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ram / Alan, I quite like the idea of implementing some kind of autoconfiguration for ZooKeeper, because currently it's entirely based on static config files which is not 100% cloud-friendly. Starting the project with an initial support for EC2 instances based on Alan's approach would be awesome. There's no concept of "seed nodes" in ZK, like Cassandra, e.g. neither clients nor servers are able to learn cluster topology from each other (that could be another improvement). In order to start a participant we have to provide "myid" (from instance tag), server IP addresses (autoscaling group), election and quorum port numbers and participant type. Basically replacing the "server.X" section of the config. RR DNS might not be a good option, because as Alan mentioned the order of returning IPs is not guaranteed, so myid config would be cumbersome. Need to think about it more, but I believe it's definitely worth to raise a Jira. Cool stuff. Regards, Andor On Mon, Feb 11, 2019 at 5:48 PM rammohan ganapavarapu < rammohanganap@gmail.com> wrote: > J=C3=BCrgen, > > I have zk clusters in dynamic environment like Autoscalling groups and as > you know in ASG it is quite common for a instance to get terminate and ne= w > one comes up right, so in that case if i rely on static config it will be > little bit hard to manage the cluster, i was thinking if we have RR DNS > name atleast i can update the DNS entry when new nodes comes up or old on= e > terminate. I have not played with dynamic config option yet but if that > solves the problem we see in dynamic environments i am good. And i am not > comparing with consul but just pointing out the existing example. > > > > Alan, > > Yes i am looking for the similar solution. > > Thanks, > Ram > > On Mon, Feb 11, 2019 at 6:52 AM Alan Scherger > wrote: > > > Hey J=C3=BCrgen, > > > > My intent was to simply suggest a more programmatic means for dynamic > > configuration. In particular, the detecting of seed nodes and their > > appropriate id numbers. One might imagine provisioning 3 nodes with tag= s > > like: > > > > zk_cluster=3Dthebestcluster > > zk_myid=3D{1,2,3} > > > > and then in the zk configuration we might have: > > > > discovery=3Dec2Tags > > discovery.ec2Tags.tagCluster=3Dzk_cluster > > discovery.ec2Tags.tagMyid=3Dzk_myid > > > > This would allow a little code to parse the tags out of ec2 and build t= he > > seed node configurations. > > > > Similarly we could build and maintain a custom auth provider that could > use > > the AWS Certificate Manager Private CA APIs or Hashicorp Vault PKI APIs > to > > automatically create and fetch the appropriate certificates and > > configurations. > > > > To your point, the security of introducing autoconfiguration of setting= s > > like these might not be appropriate for all folks or installations, but > > environments where things like instance level IAM exist help mitigate > some > > risk assuming the proper access controls have been put in place. > > rant :) > > > > > I believe it's the lack of autoconfiguration in Zookeeper that has led = to > > the creation of tools like Exhibitor or other tools that have never bee= n > > open sourced for one reason or another. The introduction of Dynamic > > Reconfiguration is quite great, but the 'Re' part might imply we still > have > > some initial work left to be done. > > > > I'm also not sure how a RR DNS record mechanism would satisfy the id > > assignment requirement since typically the value of such a record is th= at > > the results never return in a guaranteed order. Historically, I've seen > > tools, Netflix's Eureka, over come such a challenge by use of TXT recor= ds > > instead. One might argue an SRV record with appropriate priority values > > could also ensure the ordering. However, personally none of this is > > particularly my cup of tea, but I do enjoy coming across and existence = of > > such systems. > > > > Hopefully this helps? I'm certainly not trying to advocate for busy wor= k, > > extensive feature design, or russle any jimmies. > > > > Alan Scherger > > > > > > > > On Mon, Feb 11, 2019, 12:43 AM J=C3=BCrgen Wagner (DVT) > > > > > > ...and come to think of it, there is another question. Cloud instance > > > tags are simply labels. There is no real semantics associated or > > > mandated by tags. > > > > > > In particular, there is no guarantee that a Zk instance is running on= , > > > e.g., an EC2 instance labelled as "Zookeeper". Tags don't make > services. > > > > > > If you want to use auto-scaling to create more Zk nodes and reconfigu= re > > > an existing cluster, the cluster will take care of discovering its > > > members, so only clients would be affected by the changes. They, > however > > > could start with a well-known set of Zk nodes (e.g., the initial > three), > > > inquire about the actual configuration, and subscribe to configuratio= n > > > changes. There is no need for a tag- or DNS-based grouping this way. > > > > > > If you wanted to say, "hey, all of you Zk instances in my VPC, form a > > > cluster right now", you could do this indeed with tagging to seed the > > > server list initially. However, keep in mind that Zk is often a > > > security-relevant component and you don't really want ANY new Zk serv= er > > > out there to be able to join your precious cluster - only the ones yo= u > > > know about already. > > > > > > The fact that Consul may support something like it, doesn't mean it > also > > > makes sense for Zookeeper. Consul and Zookeeper protocols and > > > architectures are quite different. > > > > > > I still don't understand what the precise requirement is that lead to > > > this question. > > > > > > I hope you'll enlighten me :-) > > > > > > Cheers, > > > > > > --J=C3=BCrgen > > > > > > > > > On 11.02.2019 01:20, rammohan ganapavarapu wrote: > > > > > > > Should I open a feature request? For both cloud auto discovery and > use > > > DNS > > > > end point to form a quorum. > > > > > > > > On Sun, Feb 10, 2019, 3:56 PM Alan Scherger > > > > wrote: > > > > > > > >> We might look at something like this: > > > https://github.com/hekate-io/hekate > > > >> for inspiration (or adoption). In the Golang community Hashicorp h= as > > > built > > > >> something similar: https://github.com/hashicorp/go-discover -- thi= s > > > >> problem > > > >> set itself probably warrants a multilingual Apache project to help > > drive > > > >> some standards and interoperability. > > > >> > > > >> Alan > > > >> > > > >> On Sun, Feb 10, 2019, 5:42 PM rammohan ganapavarapu < > > > >> rammohanganap@gmail.com > > > >> wrote: > > > >> > > > >>> Clod providers have api to query instance IP based in tags, > actually > > > >> consul > > > >>> is doing that to form a cluster. > > > >>> > > > >>> On Sun, Feb 10, 2019, 11:40 AM Andor Molnar > > > > > > > > >>> wrote: > > > >>> > > > >>>> Hi Ram! > > > >>>> > > > >>>> What exactly do you mean by "auto-discovery on cloud instance > tags"? > > > >>>> Is there a standard way of doing that? > > > >>>> > > > >>>> Regards, > > > >>>> Andor > > > >>>> > > > >>>> > > > >>>> > > > >>>> On Sat, Feb 9, 2019 at 4:07 PM Norbert Kalmar > > > >>> > > >>>> wrote: > > > >>>> > > > >>>>> Hi Ram, > > > >>>>> > > > >>>>> Unfortunately ZK does not support RR DNS name. > > > >>>>> As for plans on discovery based on cloud tags, I am not aware o= f > > any > > > >>>> plans. > > > >>>>> You can create a jira for it if you'd like, but I can't tell yo= u > > when > > > >>>> that > > > >>>>> would make it into a release. > > > >>>>> > > > >>>>> Regards, > > > >>>>> Norbert > > > >>>>> > > > >>>>> On Fri, Feb 8, 2019 at 11:53 PM rammohan ganapavarapu < > > > >>>>> rammohanganap@gmail.com> wrote: > > > >>>>> > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> Does zookeper support RR DNS name in the config instead of > giving > > > >>> each > > > >>>>>> server name/ip like what consul does to join the cluster? > > > >>>>>> > > > >>>>>> > > > >>>>>> server.1=3Dserver1 > > > >>>>>> server.2=3Dserver2 > > > >>>>>> server.3=3Dserver3 > > > >>>>>> > > > >>>>>> vs > > > >>>>>> server=3Dexample.com > > > >>>>>> where example.com is RR of server1, server2 and server3 > > > >>>>>> > > > >>>>>> And does any one know if zk team has any plans to add cloud > > > >>>> autodiscovery > > > >>>>>> based on cloud instance tags? > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Ram > > > >>>>>> > > > > > > --00000000000051eae30581b0d898--