BPM doesn't wait with `start` action until all `pre-start` actions completed about bpm-release

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/154913644

The labels on this github issue will be updated when the story is started.

[xoebus]

This would be unexpected and surprises me. BPM still relies on Monit to be started so it should be started at the same point in the lifecycle as any other job.

The problem might be that you're using BPM's pre-start. BPM's pre-start is different from the job's pre-start (in an unfortunate naming collision). If you want to run something before any job on the system has started then you should keep using the BOSH job pre-start script.

[voelzmo]

I'm still using the job's pre-start, not bpm-pre-start. The addon isn't bpm-ified – would that make a difference?

[xoebus]

Nope. Does BOSH guarantee that a monit start command will only run after all of the job pre-starts on a machine have run?

[xoebus]

Seems like it: https://bosh.io/docs/job-lifecycle.html

[voelzmo]

Yes, that's part of the contract. Alright, let me try to come up with an example deployment, maybe I'm just seeing effects related to the type of processes in my releases. Thanks for the response!

[cppforlife]

After bpm-ifying the release, it seems that this doesn't work reliably anymore. Some jobs of the release seem to be started before the addon's pre-start is finished. I didn't thoroughly test this, though.

dont think this is something that bpm could have caused, since agent determines when to consider pre-start finished. are you sure your pre-start script waits for service to start properly, before exiting 0?

[jfmyers9]

Hey @voelzmo,

Were you able to recreate this behavior in an example deployment?

Best,

@jfmyers9

[voelzmo]

Hey Jim, I’m trying to take some today to reproduce this. Given the previous discussion I guess it’s likely that the addon is not behaving correctly here. Let's see. Marco

[voelzmo]

Closing this, as I couldn't reproduce with a simple example. Here's the outputs from my example with a demo lifecycle release that sleeps for 2 minutes in bosh's pre-start:

# cat ../demo/pre-start.stdout.log
[2018-02-23 21:36:05+0000] pre-start running for ping-app/b4b255fd-8b91-4249-8d23-e9552dcc37b0

ping-app/b4b255fd-8b91-4249-8d23-e9552dcc37b0:/var/vcap/sys/log/ping-app# head -1 bpm.log
{"timestamp":"1519421886.588736534","source":"bpm","message":"bpm.start.acquiring-lifecycle-lock.starting","log_level":1,"data":{"job":"ping-app","process":"ping-app","session":"1.1"}}

ping-app/b4b255fd-8b91-4249-8d23-e9552dcc37b0:/var/vcap/sys/log/ping-app# date -d @1519421886.588736534
Fri Feb 23 21:38:06 UTC 2018

So: bpm start kicks in right after bosh's pre-start being done, just like it should. Thanks for clarifying, everyone.