Github user aledsage commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/435#discussion_r88242774
--- Diff:
core/src/main/java/org/apache/brooklyn/core/mgmt/rebind/BasicEntityRebindSupport.java
---
@@ -245,14 +249,52 @@ protected void instanceRebind(AbstractBrooklynObject
instance) {
Preconditions.checkState(instance == entity, "Expected %s and %s
to match, but different objects", instance, entity);
Lifecycle expectedState =
ServiceStateLogic.getExpectedState(entity);
if (expectedState == Lifecycle.STARTING || expectedState ==
Lifecycle.STOPPING) {
- LOG.warn("Entity {} goes on-fire because it was in state {} on
rebind", entity, expectedState);
- LOG.warn("not-up-indicators={}",
entity.getAttribute(Attributes.SERVICE_NOT_UP_INDICATORS));
- ServiceStateLogic.setExpectedState(entity, Lifecycle.ON_FIRE);
+ // If we were previously "starting" or "stopping", then those
tasks will have been
+ // aborted. We don't want to continue showing that state (e.g.
the web-console would
+ // then show the it as in-progress with the "spinning" icon).
+ // Therefore we set the entity as on-fire, and add the
indicator that says why.
+ markTransitioningEntityOnFireOnRebind((EntityInternal) entity,
expectedState);
+ }
+
+ // Clear the provisioning/termination task-state; the task will
have been aborted, so wrong to keep this state.
+
((EntityInternal)entity).sensors().remove(AttributesInternal.INTERNAL_PROVISIONING_TASK_STATE);
+
((EntityInternal)entity).sensors().remove(AttributesInternal.INTERNAL_TERMINATION_TASK_STATE);
+
+ super.instanceRebind(instance);
+ }
+
+ protected void markTransitioningEntityOnFireOnRebind(EntityInternal
entity, Lifecycle expectedState) {
+ LOG.warn("Entity {} being marked as on-fire because it was in
state {} on rebind; indicators={}", new Object[] {entity, expectedState,
entity.getAttribute(Attributes.SERVICE_NOT_UP_INDICATORS)});
+ ServiceStateLogic.setExpectedState(entity, Lifecycle.ON_FIRE);
+ ServiceStateLogic.ServiceNotUpLogic.updateNotUpIndicator(
--- End diff --
Good question. No, start/restart won't clear that not-up-indicator.
In `brooklyn-jsgui` (i.e. the web-console) there is a "reset problems"
button in the advanced tab. This makes a couple of API calls for the entity. It
sets `service.notUp.indicators` and `service.problems` to be empty maps.
I think that is probably the only way to do this currently!
We need to at least update the docs about this. What would be a better way?
Should start() and restart() effectors clear all not-up-indicators? That feels
fiddly - it might cause the entity to immediately report `serviceUp=true`
(which is why `SoftwareProcessImpl.initEnrichers()` calls
`ServiceNotUpLogic.updateNotUpIndicator(this, SERVICE_PROCESS_IS_RUNNING, "No
information yet on whether this service is running")`).
Thoughts?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
