Skip to content
This repository has been archived by the owner on Aug 1, 2024. It is now read-only.

feat: Unify wait-ready with check.sh; implement mongo wait #1199

Merged
merged 5 commits into from
Oct 5, 2023

Conversation

timmc-edx
Copy link
Contributor

  • Move MySQL readiness checks from wait-ready.sh to existing check.sh, and call check.sh for any service we want to wait for
  • Add Mongo readiness check to check.sh, and use it from provisioning
  • Give cms a separate check from lms
  • Limit docker log output to 30 lines when check fails

I've completed each of the following or determined they are not applicable:

  • Made a plan to communicate any major developer interface changes (or N/A)

- Move MySQL readiness checks from wait-ready.sh to existing check.sh,
  and call check.sh for any service we want to wait for
- Add Mongo readiness check to check.sh, and use it from provisioning
- Give cms a separate check from lms
- Limit docker log output to 30 lines when check fails
Copy link
Contributor

@robrap robrap left a comment

Choose a reason for hiding this comment

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

I think it looks good. I'm not certain about how some of the old code works, but since you are just using that code, it seems fine. :)

check.sh Outdated Show resolved Hide resolved
provision.sh Outdated Show resolved Hide resolved
@timmc-edx
Copy link
Contributor Author

Hmm, provisioning tests are failing at the wait-ready step... :-/

Apparently if you just use `$cmd`, it gets tokenized by spaces rather than
having quotes and backslashes and such interpreted as you might expect in
the shell. Since the mysql check commands are the first ones that have
spaces in the command, I need to change this to `bash -c "$cmd"`.
Apparently I had only tested the script with lms and such.

(The correct way to build up a command and run it is instead with arrays,
such as `"${cmd[@]}"`.)
@timmc-edx
Copy link
Contributor Author

Figured out what was wrong. See commit message for details.

Copy link
Contributor

@robrap robrap left a comment

Choose a reason for hiding this comment

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

I'm not sure what is meant by this part of the commit comment?:

(The correct way to build up a command and run it is instead with arrays,
such as "${cmd[@]}".)

Is this something that should go into a code comment instead, and would it become more clear?

@timmc-edx
Copy link
Contributor Author

Executing an array would be the "clean" way of doing it, and it's what I would normally do. It has the advantage that it can only represent an executable (the first array element) and its arguments (the rest of the array), and doesn't support redirection, pipelines, etc. -- the reduced functionality means it can be easier to reason about in some cases.

But... passing an array to a function, which is what we would need to do here, is more complicated and annoying, so just passing a precomposed string to a bash subprocess is the more expedient option.

I think it will be clear to a reader what's going on (possibly more clear than before, even) so I don't think it needs a comment about alternative options.

@timmc-edx
Copy link
Contributor Author

Credentials dev.check failed with ModuleNotFoundError: No module named 'edx_credentials_themes' which is very weird because you can see that getting installed earlier on in the logs. Rerunning and hoping that's just a weird glitch... :-/

@robrap
Copy link
Contributor

robrap commented Oct 5, 2023

I think it will be clear to a reader what's going on (possibly more clear than before, even) so I don't think it needs a comment about alternative options.

Ok. I'm not sure if you also plan to drop it from the squashed commit message, and if it was just for the review, but it feels disconnected as-written. So, if you don't think it makes sense in a code comment, it probably doesn't make sense in the commit comment either.

@timmc-edx
Copy link
Contributor Author

Yeah, I'm not planning on including it in the squash commit.

Still need to figure out what's going with credentials. Seems like it should be unrelated, but it's failing in the check phase.

@timmc-edx
Copy link
Contributor Author

OK, it passed that time? So I suspect that this is just an existing race condition with dev.check that... happened to come up just as I was working with check.sh? A little suspicious, but I think it has come up before.

I'll fix that race condition in a separate PR.

@timmc-edx timmc-edx merged commit 591c664 into master Oct 5, 2023
@timmc-edx timmc-edx deleted the timmc/wait-all branch October 5, 2023 19:57
nsprenkle pushed a commit that referenced this pull request Nov 21, 2023
- Move MySQL readiness checks from wait-ready.sh to existing check.sh,
  and call check.sh for any service we want to wait for
- Add Mongo readiness check to check.sh, and use it from provisioning
- Give cms a separate check from lms
- Change how check commands are executed; now that some of the
  commands have a space in them, we have to ensure that quoted or
  escaped spaces are interpreted properly. Using a bash -c invocation
  fixes this.
- Limit docker log output to 30 lines when check fails
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants