Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Inconsistent DB update behavior on environment create #140

Closed
iamEAP opened this issue May 22, 2014 · 4 comments · Fixed by #141
Closed

Inconsistent DB update behavior on environment create #140

iamEAP opened this issue May 22, 2014 · 4 comments · Fixed by #141

Comments

@iamEAP
Copy link
Contributor

iamEAP commented May 22, 2014

In our automated build process, we run, essentially...

drush psite-ecreate $PUUID $PSITE --source=$PSOURCE
drush @pantheon.$PNAME.$PSITE updb -y --strict=0

We run into problems when we have long-running update hooks; they appear to be running twice (simultaneously) and, in those cases, failing... Main theory being that the psite-ecreate command begins running one (or so it seems)... Then the explicit updb call starts running the same one (because there's no mechanism to say "update x is running" other than "x already ran").

I guess this is either...

  • A support request for more clarity on what actually happens behind the scenes on site create...
  • Or a feature request to add more options to psite-ecreate to more finely define behavior (run update hooks or not).
@joshkoenig
Copy link
Contributor

It's not intended to:

https://github.com/pantheon-systems/terminus/blob/master/terminus.drush.inc#L2540

But I believe it's possible that that FALSE parameter is a bad match for the 0 (zero) default in the actual backend:

https://github.com/pantheon-systems/terminus/blob/master/terminus.workflow.api.inc#L10

Can you try changing the $result_clone_db line to pass nothing instead of FALSE there and see if that changes things?

@iamEAP
Copy link
Contributor Author

iamEAP commented May 22, 2014

Tested the change and it succeeded... But it's hard to say, because the error isn't very deterministic. I can't guarantee it succeeded because of the change, or it succeeded because the race condition didn't happen to crop up.

I do see "Run update.php in my-env" as a successfully completed job in the Pantheon UI... But I'm not sure whether or not that would show for a manual drush updb call.

@joshkoenig
Copy link
Contributor

That should not come through from a drush call. That would be our task system at work.

I'll see if I can replicate this locally.

@joshkoenig
Copy link
Contributor

Ok got it. Looks like sending ANY value for the updatedb flag will trigger it.

@joshkoenig joshkoenig mentioned this issue May 22, 2014
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fixing arguments for runnign updatedb after a clone pantheon-deprecated/terminus-deprecated
2 participants
@joshkoenig @iamEAP