cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Shepherd <>
Subject Re: note to devcloud users on
Date Thu, 31 Oct 2013 16:27:34 GMT
This is fixed now.  Sorry about that.  I really do go through extra
length to test my changes.  I'm finding it difficult to ensure quality
because there is so much variation.  You have to test everything in so
many contexts.  It shouldn't be like that I hope to help reduced the
amount of variation in this platform.  This was part of why I made the change to begin with.  I wanted to change MacAddress to
read from, but then I found out that that properties
file is loaded in probably 10 different places in all slightly
different ways.  Some places would decrypt, some wouldn't, some
ignored if the file was not found, some would just throw a NPE.  So I
consolidated all that code.


On Thu, Oct 31, 2013 at 9:07 AM, Darren Shepherd
<> wrote:
> 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
> <> 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 <> wrote:
>>> Heya,
>>> With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the loading
of the file, however this also affected the DatabaseCreator used by the deploydb
procedure to refresh the database. Effectively the db.properies.override is ignored at the
moment and the db.proeprties file in utils/conf/ will be used instead. We need to come up
with a nice solution for this in the near future, but in the meantime make any custom setting
there. Just don’t commit them ;-)
>>> Cheers,
>>> Hugo

View raw message