From dev-return-27066-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu May 2 15:24:46 2013
Return-Path:
X-Original-To: apmail-couchdb-dev-archive@www.apache.org
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id AA53B10869
for ; Thu, 2 May 2013 15:24:46 +0000 (UTC)
Received: (qmail 81886 invoked by uid 500); 2 May 2013 15:24:46 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 81732 invoked by uid 500); 2 May 2013 15:24:46 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 81724 invoked by uid 99); 2 May 2013 15:24:46 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 May 2013 15:24:46 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of ianshward@gmail.com designates 209.85.214.44 as permitted sender)
Received: from [209.85.214.44] (HELO mail-bk0-f44.google.com) (209.85.214.44)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 May 2013 15:24:39 +0000
Received: by mail-bk0-f44.google.com with SMTP id jk13so320960bkc.31
for ; Thu, 02 May 2013 08:24:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:x-received:date:message-id:subject:from:to
:content-type;
bh=Btfm6N8ejw448S16wUQRwSHwdlXDd04N2HCSNfcdCCo=;
b=m4iU4dI56oCcFuodO1iwnnYu1wzdnfOEQogOPKW05tI3EcB5LFCADe4MD8D5wMDSVw
oP+deepI3+q1ClLIeYDeRQizO4XCKaBkGKMN8lGIGL9fTGXJPOd7JDliWOHNUNGrxJMP
62Eh/M8ymPt6SM3E5Ywm0e4+gNppPtAOH8TQIly1G/P8JEduYkiliO4dWFrhCP6mt9OL
FiQHj1hIEQrAb73Pa0PlSf8K8+imp5CiaJHtudV9kX2hAiypS3s+Ck6NbvEUpyvDCuwC
Z3PilW1YhvXBVIBnysak4pTejhI7hk9BtVNwGj7b1UlmS0/bqqDY3fIktZn0RNe/2E5U
TmtQ==
MIME-Version: 1.0
X-Received: by 10.205.46.193 with SMTP id up1mr2290568bkb.65.1367508259440;
Thu, 02 May 2013 08:24:19 -0700 (PDT)
Received: by 10.205.66.4 with HTTP; Thu, 2 May 2013 08:24:19 -0700 (PDT)
Date: Thu, 2 May 2013 11:24:19 -0400
Message-ID:
Subject: accidentally used same uuid on multiple servers
From: Ian Ward
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Checked: Checked by ClamAV on apache.org
As discussed w/ rnewson in #couchdb I accidentally used the same
[couchdb] uuid on multiple servers. This never made it to my
production system because I noticed errors like "Error updating the
target checkpoint document: conflict" in the log, and then noticed
that replication_id was not unique per instance when looking at http
request logs. I ended up specifying private-ip:port in my script that
triggers replication which leads to the replication_id being unique
for each instance on its peers.
The explanation for how I ended up using the same [couchdb] uuid on
multiple servers is that I use puppet to deploy couchdb servers, and I
manage a copy of local.ini in puppet. I built couchdb once withouth
puppet to generate the local.ini / default.ini, and then I took copies
of these and put them in puppet. I overlooked that [couchdb] uuid was
defined in the copy of local.ini. This copy of local.ini with uuid
defined in it was then getting pushed out to my testing machines,
causing them to all use the same replication_id on their peers.
rnewson asked me to write to the list about the above, in order to
discuss storing uuid in a place where it may be less likely to be
copied in deployment management systems / scripts like Puppet.