Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of darren.s.shepherd@gmail.com
 designates 74.125.82.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F199C2AF-873A-46F2-8FD8-CB21C668D906@GMAIL.com>
References: <F199C2AF-873A-46F2-8FD8-CB21C668D906@GMAIL.com>
Date: Thu, 31 Oct 2013 08:52:17 -0700
Message-ID: 
 <CAMCEDC13FawAwRJS=ENTWNjbnQvLO1ZBR0qEzLaa+kYCm5c2Ow@mail.gmail.com>
Subject: Re: note to devcloud users on db.properties.override
From: Darren Shepherd <darren.s.shepherd@gmail.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I'll fix that.  Gimme ten mintues.  I specifically looked at that code
and thought I didn't change the behavior, but I guess I screwed it up.

Just a general comment.  There's too many ways to do the same thing in
CloudStack.  Especially the database.  The way databases are setup for
developers shouldn't be so different from production.  The way we
manage the DB at the moment is so problematic in my mind.

Darren


On Thu, Oct 31, 2013 at 7:18 AM, Hugo Trippaers <hugo@trippaers.nl> wrote:
> Heya,
>
> With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the =
loading of the db.properties file, however this also affected the DatabaseC=
reator used by the deploydb procedure to refresh the database. Effectively =
the db.properies.override is ignored at the moment and the db.proeprties fi=
le in utils/conf/ will be used instead. We need to come up with a nice solu=
tion for this in the near future, but in the meantime make any custom setti=
ng there. Just don=92t commit them ;-)
>
> Cheers,
>
> Hugo