Allow verdi status to skip checks

[chrisjsewell]

This PR adds flags to verdi status --no-rmq --no-daemon.
My specific use case for this is, when initiating a Docker container, I want to wait for the environment to finished initialising before starting a daemon by polling the exit code of verdi status.

[chrisjsewell]

Well thats annoying, this all run fine locally
(re-building local environment at least fixed the pre-commit)

[codecov]

Codecov Report

Merging #4181 into develop will increase coverage by 0.01%.
The diff coverage is 75.00%.

@@             Coverage Diff             @@
##           develop    #4181      +/-   ##
===========================================
+ Coverage    78.89%   78.89%   +0.01%     
===========================================
  Files          467      467              
  Lines        34500    34503       +3     
===========================================
+ Hits         27215    27218       +3     
  Misses        7285     7285              

Flag	Coverage Δ
#django	70.82% <75.00%> (+0.01%)	⬆️
#sqlalchemy	71.70% <75.00%> (+0.01%)	⬆️

Impacted Files	Coverage Δ
aiida/cmdline/commands/cmd_status.py	77.34% <75.00%> (+0.95%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 94a40ae...5a7660f. Read the comment docs.

[sphuber]

@chrisjsewell why don't you need the status of RabbitMQ but you do need it for Postgres? I can see the point of the daemon. It not running is not really a "failure". So would it maybe make more sense to turn the daemon notification in a warning by default, i.e. swapping out the red cross for a yellow circle or something, and just returning 0. Anyway, verdi daemon status can be used to determine whether the daemon is running. If it doesn't return non-negative exit status if daemon is not running, we can of course add this, which would make sense

[chrisjsewell]

why don't you need the status of RabbitMQ

Well rabbitmq is only required for running computations. If for example you just want to spin up a container to inspect an existing database, you only want to check that it is ready for access.

[chrisjsewell]

So would it maybe make more sense to turn the daemon notification in a warning by default

Yep something like that could work; I just would like a consistent/simple way to check if the "AiiDA environment" is either:

1. ready to access as a database (profile + postgres)
2. ready to start daemons (profile + postgres + rabbitmq)
3. ready to start calculations (profile + postgres + rabbitmq + daemons)

[chrisjsewell]

swapping out the red cross for a yellow circle or something

At least for my use case, I don't really care what is printed lol; I'm just using it as an "API"

For example in https://github.com/chrisjsewell/aiida-vcode-ext/runs/781411414?check_suite_focus=true, I'm currently using:

docker exec --user aiida aiida-core timeout 60s bash -c 'until verdi profile list 2> /dev/null; do echo -n .; sleep 1; done'

[sphuber]

I opened a PR against your branch to get rid of the --no-daemon and just return 0 when it is not running. Also turned the text into a "warning" with a yellow circle instead of a cross, because a daemon that is not running is nowhere near as bad as a failing database connection

[chrisjsewell]

Yep thats great cheers, and I like the new pytest fixture 👌

[sphuber]

Yep thats great cheers, and I like the new pytest fixture ok_hand

Cheers. I added it recently as it simplifies a great deal of test code. Maybe should send a quick email soon to the team to notify everyone of its existence

[sphuber]

Good to go, thanks @chrisjsewell