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 Loek van Gent, 10 years ago

Component: UncategorizedCore (System checks)

comment:2 by Tim Graham, 10 years ago

Component: Core (System checks)Core (Management commands)
Triage Stage: UnreviewedAccepted
Type: UncategorizedNew feature
Version: 1.7master

comment:3 by John Giannelos, 10 years ago

Owner: changed from nobody to John Giannelos
Status: newassigned

comment:4 by John Moses, 9 years ago

Is this still needed with the sendtestemail command?

comment:5 by John Giannelos, 9 years ago

Owner: John Giannelos removed
Status: assignednew

comment:6 by Loek van Gent, 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.

Last edited 9 years ago by Loek van Gent (previous) (diff)

comment:7 by Alex Morozov, 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 Tim Graham, 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 Alex Morozov, 9 years ago

Owner: set to Alex Morozov
Status: newassigned

@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 Tim Graham, 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 Shai Berger, 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 Tim Graham, 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 Alex Morozov, 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 Tim Graham, 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 Alex Morozov, 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 Mariusz Felisiak, 3 years ago

Resolution: wontfix
Status: assignedclosed
Triage Stage: AcceptedUnreviewed

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.

Note: See TracTickets for help on using tickets.
Back to Top