[Django] #24475: Add a new testconnections management command
Django
-------------------------------+--------------------
Reporter: gannetson | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.7
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
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()
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24475>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: gannetson | Owner: nobody
Type: Uncategorized | Status: new
checks) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by gannetson):
* needs_better_patch: => 0
* component: Uncategorized => Core (System checks)
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:1>
Django
Reporter: gannetson | Owner: nobody
Type: New feature | Status: new
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* component: Core (System checks) => Core (Management commands)
* version: 1.7 => master
* type: Uncategorized => New feature
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:2>
Django
Reporter: gannetson | Owner: johngian
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by johngian):
* status: new => assigned
* owner: nobody => johngian
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:3>
Django
Reporter: gannetson | Owner: johngian
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by jonaldomo):
Is this still needed with the sendtestemail command?
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:4>
Django
Reporter: gannetson | Owner:
Type: New feature | Status: new
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by johngian):
* owner: johngian =>
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:5>
Django
Reporter: gannetson | Owner:
Type: New feature | Status: new
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by gannetson):
The idea is that this commands will test all kind of connections. 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:6>
Django
Reporter: gannetson | Owner:
Type: New feature | Status: new
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by alexmorozov):
Does it make sense to extend the
[https://docs.djangoproject.com/en/1.8/topics/checks/ system check]
framework with this kind of functionality? If that's ok, I'd try to draft
some code.
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:7>
Django
Reporter: gannetson | Owner:
Type: New feature | Status: new
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:8>
Django
Reporter: gannetson | Owner:
| alexmorozov
Type: New feature | Status: assigned
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by alexmorozov):
* owner: => alexmorozov
* status: new => assigned
Comment:
@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?
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:9>
Django
Reporter: gannetson | Owner:
| alexmorozov
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:10>
Django
Reporter: gannetson | Owner:
| alexmorozov
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by shaib):
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:11>
Django
Reporter: gannetson | Owner:
| alexmorozov
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:12>
Django
Reporter: gannetson | Owner:
| alexmorozov
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by alexmorozov):
@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?
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:13>
Django
Reporter: gannetson | Owner:
| alexmorozov
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:14>
Django
Reporter: gannetson | Owner:
| alexmorozov
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by alexmorozov):
@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
[https://github.com/KristianOellegaard/django-health-check an interesting
package]. Do you know any of similar libraries, maybe, even more generic?
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:15>
Django
Reporter: Loek van Gent | Owner: Alex
| Morozov
Type: New feature | Status: closed
Component: Core (Management | Version: dev
commands) |
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: assigned => closed
* resolution: => wontfix
* stage: Accepted => Unreviewed
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24475#comment:16>