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 <[email protected]> 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> -- Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. Cloudsoft Corporation Limited does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by Cloudsoft Corporation Limited in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
