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 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMCEDC13FawAwRJS=ENTWNjbnQvLO1ZBR0qEzLaa+kYCm5c2Ow@mail.gmail.com>
References: <F199C2AF-873A-46F2-8FD8-CB21C668D906@GMAIL.com>
	<CAMCEDC13FawAwRJS=ENTWNjbnQvLO1ZBR0qEzLaa+kYCm5c2Ow@mail.gmail.com>
Date: Thu, 31 Oct 2013 09:07:57 -0700
Message-ID: 
 <CAMCEDC32knXpOn-YF36-SET+fnUOkWudTaCeKtEO0wAtKpfQAw@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

Ugh, I see what I did now.  When I tested that code I changed the code
I didn't do a "mvn install" before running "mvn ... deploydb."  That's
annoying, now I want to figure out why maven doesn't pickup changes
unless I do an install.  So I effectively tested with the old code.

Darren

On Thu, Oct 31, 2013 at 8:52 AM, Darren Shepherd
<darren.s.shepherd@gmail.com> wrote:
> 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 Database=
Creator used by the deploydb procedure to refresh the database. Effectively=
 the db.properies.override is ignored at the moment and the db.proeprties f=
ile in utils/conf/ will be used instead. We need to come up with a nice sol=
ution for this in the near future, but in the meantime make any custom sett=
ing there. Just don=92t commit them ;-)
>>
>> Cheers,
>>
>> Hugo