brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrián Nieto <>
Subject Re: Issues during migration process
Date Wed, 23 Sep 2015 16:26:20 GMT
Hello Svet:

Regarding to 1, this is fine for me then maybe a new status should be
created to flag the Entity as under Migration.

About 2:

	* Figure 1 shows the status before the migration process start, it's
just a deployment over amazon with a fresh Brooklyn. Brooklyn shows it
as RUNNING without problems (IP:

	* Figure 2 shows the Entity state after the migration (ON_FIRE because
checkRunning reached the timeout). It has a new IP ( but
MAIN_URI and JMX_SERVICE_URL still points to the old IP.

The most interesting lines on the log are the last ones, which shows an
warning because the driver change it's not tested and the failure of the
JMX sensor to connect to the target machine (because it's still pointing
to the old one)

Thank you.

El 23/09/2015 a las 17:42, Svetoslav Neykov escribió:
> Hi Adrian,
> 1) This is the expected behaviour at the moment for generic apps. Children don't affect
parent state (with the exception of ON_FIRE). The reason is that it's use case specific whether
the parent should go in a special state when the child starts/stops/restarts. For the general
case the parent will go on fire if it decides there's something wrong with its children (for
example not enough members are running - quorum checks) or seems children on fire.
> 2) Can't tell from the screenshots what sensors remain pointing to the old IP, could
you point them out. Also the entity is on fire while running on the first machine, depending
on the cause it's entirely possible the problem is still there when running on the second
machine. Do you know what's the reason for the initial failure?
> Svet.
>> On 23.09.2015 г., at 18:33, Adrián Nieto <> wrote:
>> Hello all:
>> As you already know I'm working on adding the capability of migration to
>> Brooklyn entities.
>> I have a WIP version which allows to call the Migrate Effector on every
>> class which extends JavaWebAppSoftwareProcess (ie. Tomcat, JBoss...) on
>> GitHub [1] just in case you want to test by your own.
>> This version only allows to migrate non nested entities so in this
>> moment, calling the Effector Migrate withing a SameServerEntity or
>> similar it will throw an exception.
>> Among with this, I found some issues that I would like to share with you
>> as maybe they could be part of an underlying bug in Brooklyn:
>> 	1. When an inner Entity State changes from RUNNING to STARTING or
>> STOPPING the parent is unaffected. I think that if you start a
>> migration, the parent (Application in this moment) should become at
>> least STARTING with isUp sensor equal to false until the migration
>> process finishes.
>> 	2. Some sensors values are not updated when you call stop() to 	free
>> the old Location and start() after you're added the new one. This
>> triggers ON_FIRE signal because some sensors will try to read from a non
>> existing location. As you can see in attached Figures 1 and 2. Some
>> values like main.uri are not updated properly.  However, the migration
>> process finishes, and you can access to the web server in the new
>> location. In this particular case, Brooklyn never sees the Entity as
>> running because the isRunning sensor seems to be reading from a non
>> existing Location. In order to have some feedback about the root of the
>> problem I attached the Brooklyn log output among with example YAML.
>> For me, 1 and 2 could be related each other but my main priority is to
>> find what's happening with 2 because migration finishes properly no
>> matter what Brooklyn says as you can see in the Figure 2
>> What's the best way to proceed? It looks like it should have a simple
>> solution but I'm not able yet to find where is the cause of this problem.
>> <FIGURE2.PNG><FIGURE1.PNG><brooklyn.log><deployment.yaml>

View raw message