You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Hugo Trippaers <hu...@trippaers.nl> on 2013/10/31 15:18:47 UTC
note to devcloud users on db.properties.override
Heya,
With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the loading of the db.properties 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
Re: note to devcloud users on db.properties.override
Posted by Darren Shepherd <da...@gmail.com>.
Yeah, I see there was a commit a3cec3802c4c56173c33ccc1e08af059547fe90e
that broke it again. I'll reverted that commit and ran the following to
sanity test and its seems to be working now
mvn -T 1.5C -DskipTests clean install
chmod +x
plugins/network-elements/juniper-contrail/test/resources/mysql_db_start.sh
plugins/network-elements/juniper-contrail/test/resources/mysql_db_start.sh
5000
sed s/3306/5000/g utils/conf/db.properties >
utils/conf/db.properties.override
mvn -P developer -pl developer -Ddeploydb
Make sure you run "mvn clean install" once after you update.
Darren
On Fri, Nov 1, 2013 at 6:34 PM, Pedro Roque Marques <
pedro.r.marques@gmail.com> wrote:
> Darren,
>
> On Oct 31, 2013, at 9:27 AM, Darren Shepherd <da...@gmail.com>
> wrote:
>
> > This is fixed now.
>
> Maybe i'm doing something really dumb... but i still see the problem.
> I do see the commit afaf637 in the branch history.
>
> Steps to reproduce:
> 1.
> plugins/network-elements/juniper-contrail/test/resources/mysql_db_start.sh
> 50000
> 2 copy utils/conf/db.properties to db.properties.override
> 3 modify
>
> # CloudStack database settings
> db.cloud.username=${USER}
> db.cloud.password=
> db.root.password=
> db.cloud.host=localhost
> db.cloud.port=50000
> db.cloud.name=cloud
>
> 4. mvn -P developer -pl developer -Ddeploydb
> ========> Initializing database=cloud with host=localhost port=3306
> username=cloud password=cloud
>
> It should display port=50000 and username=${USER)
>
>
> I'll dig into this further... most likely it is being caused by something
> really stupid i'm doing. But anyway i thought i would suggest a way to
> start a local mysql as a way to test. The contrail plugin test harness is
> allocating a random port and then trying to create a DB that is used for
> the test.
>
> Pedro.
Re: note to devcloud users on db.properties.override
Posted by Pedro Roque Marques <pe...@gmail.com>.
Darren,
On Oct 31, 2013, at 9:27 AM, Darren Shepherd <da...@gmail.com> wrote:
> This is fixed now.
Maybe i'm doing something really dumb... but i still see the problem.
I do see the commit afaf637 in the branch history.
Steps to reproduce:
1. plugins/network-elements/juniper-contrail/test/resources/mysql_db_start.sh 50000
2 copy utils/conf/db.properties to db.properties.override
3 modify
# CloudStack database settings
db.cloud.username=${USER}
db.cloud.password=
db.root.password=
db.cloud.host=localhost
db.cloud.port=50000
db.cloud.name=cloud
4. mvn -P developer -pl developer -Ddeploydb
========> Initializing database=cloud with host=localhost port=3306 username=cloud password=cloud
It should display port=50000 and username=${USER)
I'll dig into this further... most likely it is being caused by something really stupid i'm doing. But anyway i thought i would suggest a way to start a local mysql as a way to test. The contrail plugin test harness is allocating a random port and then trying to create a DB that is used for the test.
Pedro.
Re: note to devcloud users on db.properties.override
Posted by Hugo Trippaers <hu...@trippaers.nl>.
On 31 okt. 2013, at 17:27, Darren Shepherd <da...@gmail.com> wrote:
> 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
> db.properties change to begin with. I wanted to change MacAddress to
> read from db.properties, 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.
Nice! I like the consolidation :-)
Cheers,
Hugo
>
> Darren
>
>
> On Thu, Oct 31, 2013 at 9:07 AM, Darren Shepherd
> <da...@gmail.com> 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
>> <da...@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 <hu...@trippaers.nl> wrote:
>>>> Heya,
>>>>
>>>> With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the loading of the db.properties 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
Re: note to devcloud users on db.properties.override
Posted by Darren Shepherd <da...@gmail.com>.
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
db.properties change to begin with. I wanted to change MacAddress to
read from db.properties, 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.
Darren
On Thu, Oct 31, 2013 at 9:07 AM, Darren Shepherd
<da...@gmail.com> 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
> <da...@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 <hu...@trippaers.nl> wrote:
>>> Heya,
>>>
>>> With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the loading of the db.properties 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
Re: note to devcloud users on db.properties.override
Posted by Darren Shepherd <da...@gmail.com>.
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
<da...@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 <hu...@trippaers.nl> wrote:
>> Heya,
>>
>> With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the loading of the db.properties 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
Re: note to devcloud users on db.properties.override
Posted by Darren Shepherd <da...@gmail.com>.
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 <hu...@trippaers.nl> wrote:
> Heya,
>
> With commit 1460196496d73e0db25c7beb2392cfaf9d591ed7 Darren improved the loading of the db.properties 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