Opened 10 years ago
Closed 3 years ago
#24475 closed New feature (wontfix)
Add a new testconnections management command
Reported by: | Loek van Gent | Owned by: | Alex Morozov |
---|---|---|---|
Component: | Core (Management commands) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Add a management command to check connection to mail server (without actually sending emails). This command can be extended later with testing other connections like caching ad maybe other settings.
Here's a snippet that would test a smtp connection
from django.core import mail from django.core.mail.backends.smtp import EmailBackend def _check_mail_settings(self): connection = mail.get_connection() if isinstance(connection, EmailBackend): connection.open()
Change History (16)
comment:1 by , 10 years ago
Component: | Uncategorized → Core (System checks) |
---|
comment:2 by , 10 years ago
Component: | Core (System checks) → Core (Management commands) |
---|---|
Triage Stage: | Unreviewed → Accepted |
Type: | Uncategorized → New feature |
Version: | 1.7 → master |
comment:3 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 9 years ago
comment:5 by , 9 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:6 by , 9 years ago
The idea is that this command will test all kind of connections. For mail server settings this should only test if the mailserver is reachable and if you can log in with the given credentials, without actually sending emails.
We could later extend it with testing the settings/servers for chaching, celery etc.
comment:7 by , 9 years ago
Does it make sense to extend the system check framework with this kind of functionality? If that's ok, I'd try to draft some code.
comment:8 by , 9 years ago
Currently the system check framework is limited to static code analysis. Adding a new option like check --conections
could work. I think these checks shouldn't run if that option isn't specified though.
comment:9 by , 9 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
@timgraham, thank you. Will have a closer look on this. Should the check --connections
test only connections as its name implies, or maybe we should rename the option? My English is pretty poor, but wouldn't something like --with-connections
be more clear?
comment:10 by , 9 years ago
I think testing only connections is fine as it's a fundamentally different type of check from the static code checks but this is subject to the implementation, what checks we actually add, and what others think is best.
comment:11 by , 9 years ago
What do we gain by folding it into the system checks framework? How is that better than a separate command?
Also, is this intended mostly for "local" connections (mail, database, job-queue broker) or are "remote" connections (OAuth providers, other APIs) also on the plate?
comment:12 by , 9 years ago
One advantage of the the checks framework is that it makes it easy for users to register new checks if they want to check parts of their infrastructure that Django core doesn't know about.
I don't know the answer to your second question. I have thought that it might be better to start this as a third-party project to allow it to iterate more quickly, see if it gains any traction and if so, how exactly users end up using it.
comment:13 by , 9 years ago
@shaib, the whole "checks" framework seems to me to be a registry of various checks of "system health". Remote dependencies are (for me) the perfect fit for that. Introducing another command seems to be an real cognitive overhead.
As for the "remote" connections - I'm quite fine with that, it would help a lot on deploy. Though such kind of checks surely should be warnings, not errors.
@timgraham, speaking of starting this as a separate project - I'm not sure there's an easy way to register those tests as 'checks', while having the check framework skipping them for the 'common' run. And implementing a separate 'remote checks' registry (mostly copy-pasting the checks' code) looks like a total mess for me.
If we could mark some checks tags to be skipped at the plain run (more generic way of that "deploy" thing), would it be of help?
comment:14 by , 9 years ago
Making the checks framework more extensible does seem interesting but may be a bit tricky and will obviously delay being able to release this as a third-party app until the next Django feature release. It might involve a little copy/pasting from Django, but I think it should be straightforward to mimic a simple version of Django's check registry in a third-party app/command.
comment:15 by , 9 years ago
@timgraham, I've got your reservations, thank you. I'll try to draft a third-party package, or to make use of some existing one.
P.S. After a bit of googling, I have found an interesting package. Do you know any of similar libraries, maybe, even more generic?
comment:16 by , 3 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Triage Stage: | Accepted → Unreviewed |
There are already 3rd-party packages that check the status of various connections e.g. django-health-check
. We need to reach a strong consensus on the DevelopersMailingList before incorporating them into Django.
Is this still needed with the sendtestemail command?