Skip to content

Added start latch to BasicStartable and StartableApplication#37

Merged
asfgit merged 5 commits intoapache:masterfrom
grkvlt:start-latch
Mar 7, 2016
Merged

Added start latch to BasicStartable and StartableApplication#37
asfgit merged 5 commits intoapache:masterfrom
grkvlt:start-latch

Conversation

@grkvlt
Copy link
Member

@grkvlt grkvlt commented Feb 24, 2016

Allows groups of components and applications to have their startup sequence controlled more easily. This includes only setting service.isUp to true on an AbstractApplication once it, and its children, have started. This is the same semantics as other entities, and allows a more consistent blueprint style.

Also reverts d7c3759 which prevents Clocker from re-using images.


// Opportunity to block startup until other dependent components are available
Object val = config().get(START_LATCH);
if (val != null) log.debug("{} finished waiting for start-latch; continuing...", this, val);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no matching {} for val in the message.

@sjcorbett
Copy link
Contributor

Two trivial comments, otherwise good to merge.

// default app logic; easily overridable by adding a different enricher with the same tag
ServiceStateLogic.newEnricherFromChildren().checkChildrenAndMembers().addTo(this);
ServiceStateLogic.ServiceNotUpLogic.updateNotUpIndicator(this, Attributes.SERVICE_STATE_ACTUAL, "Application created but not yet started, at "+Time.makeDateString());
ServiceStateLogic.ServiceNotUpLogic.updateNotUpIndicator(this, Attributes.SERVICE_STATE_ACTUAL, Lifecycle.CREATED);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change these, out of interest? They are now inconsistent with the calls in stop() (which pass "Application stopping" etc).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the not-up indicator is checking a sensor against its value, and the Attributes.SERVICE_STATE_ACTUAL is of type Lifecycle. I'll also change stop() ten...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The attribute is passed just for the name, its type is not used in the not-up map. Human readable values are preferred as that's its primary target - troubleshooting by users.

@grkvlt grkvlt force-pushed the start-latch branch 2 times, most recently from 50e5424 to 2017bac Compare February 29, 2016 14:09
@grkvlt
Copy link
Member Author

grkvlt commented Feb 29, 2016

Updated and squashed commits

@grkvlt
Copy link
Member Author

grkvlt commented Mar 1, 2016

Added another commit to fix issue with Clocker where preInstall() was being skipped which reverts a previous change by @bostko

}});

boolean skipInstall = locationInstalled.or(entityInstalled).or(false);
if (!skipInstall) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to state the cases we need to test or to have automated test:

  1. Install multiple apps on a BYON location
  2. Perform a restart on a BYON location
  3. Perform a restart with machineStop: NEVER/(or false)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I really want is a stage that is always executed on entity startup, maybe not preInstall() but prepare() that doesn't do anything on the VM, but sets up the entity instance. This is where the setting of expandedInstallDir and so on would happen. I'll see if it's easy to make that change.

@grkvlt
Copy link
Member Author

grkvlt commented Mar 3, 2016

@bostko I think this (and apache/brooklyn-library#14) will do what you want. The preInstall() methods will be skipped if the SKIP_INSTALL key is set, and the new prepare() method will set up the entity internals every time.

@grkvlt grkvlt force-pushed the start-latch branch 2 times, most recently from 37d72d4 to f0d0c68 Compare March 4, 2016 14:30
@sjcorbett
Copy link
Contributor

@grkvlt Can you rebase this please?

@grkvlt
Copy link
Member Author

grkvlt commented Mar 4, 2016

@sjcorbett done

@sjcorbett
Copy link
Contributor

Tests pass locally.

@asfgit asfgit merged commit b688347 into apache:master Mar 7, 2016
asfgit pushed a commit that referenced this pull request Mar 7, 2016
Added start latch to BasicStartable and StartableApplication
@ahgittin
Copy link
Contributor

ahgittin commented Mar 7, 2016

@sjcorbett have to confirmed that downstream entities work with this PR and with no changes?

NB there are a lot of related changes in

but (hopefully) these are cleaning it up, not requirements. (if this PR breaks backwards compatibility then we have to document that very clearly!)

doStart(locationsToUse);
postStart(locationsToUse);

ServiceStateLogic.ServiceNotUpLogic.clearNotUpIndicator(this, Attributes.SERVICE_STATE_ACTUAL);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feels odd to do this after start, we might be clearing important not-up indications which happened during doStart etc. (ideally we probably shouldn't have to do it at all.)

not a big deal as logic has not been perfect but maybe worth a comment in the code

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess this is how we do it elsewhere, we basically assume if start failed without errors then it should normally be up, and we'll get told subsequently + periodically if that isn't the case.

in which case it makes sense to me to put this after, else we might catch a rogue not-up indicator from before the start which isn't reset in time.

(but still worth a comment in the code!)

@ahgittin
Copy link
Contributor

ahgittin commented Mar 7, 2016

don't like seeing expansion of root lifeycle methods (provision prepare install ...) but +1 feels like the best thing for now

nice @grkvlt

@sjcorbett
Copy link
Contributor

@ahgittin I ran the library/nosql+webapp integration tests. All nosql tests passed. The webapp tests that failed did not do so because of this change. As I understood it library-#14 shifts entity's previous behaviour from preInstall to prepare, so while one is merged and the other isn't Brooklyn will behave as before (and thus brooklyncentral/clocker#245 still holds). @grkvlt Can you confirm?

@ahgittin
Copy link
Contributor

ahgittin commented Mar 7, 2016

Thanks @sjcorbett . I haven't noticed any problems either.

@grkvlt
Copy link
Member Author

grkvlt commented Mar 8, 2016

@sjcorbett correct apache/brooklyn-library#14 needs merged to fix Clocker

grkvlt added a commit to grkvlt/brooklyn-server that referenced this pull request Jun 12, 2017
Update default docker image id to latest build
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants