#35400: SECRET_KEY_FALLBACKS documentation can be misleading when running 
multiple
instances of an application
-------------------------------------+-------------------------------------
     Reporter:  Ryan Siemens         |                    Owner:  nobody
         Type:                       |                   Status:  closed
  Cleanup/optimization               |
    Component:  Documentation        |                  Version:  5.0
     Severity:  Normal               |               Resolution:  invalid
     Keywords:                       |             Triage Stage:
  SECRET_KEY_FALLBACKS               |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  1                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Sarah Boyce):

 * resolution:   => invalid
 * status:  new => closed

Comment:

 Hi Ryan, thank you for this ticket I've been thinking about it quite a
 while.

 ​I think the docs specifically on
 [https://docs.djangoproject.com/en/dev/ref/settings/#secret-key-fallbacks
 SECRET_KEY_FALLBACKS] is clear enough in terms of what the setting is and
 what Django uses it for.

 > My request is to update the documentation to at least indicate that the
 advice doesn't hold in scenarios where you are running the application
 across a fleet of boxes.

 I was trying to find existing warnings giving extra considerations that
 depend on a user's infrastructure and deployments. In general, the docs
 seem to assume a single-node deployment and rather than considering
 distributed environments. For example, there isn't an explicit warning in
 the docs around how adding a NOT NULL column on a model can lock up a
 table and cause deadlocks with a running application.

 I could see a new topic for "Deployment considerations for distributed
 systems" (or something along those lines within the existing Deployment
 docs) being valuable. This is quite different from what you were
 suggesting originally, and quite a bit of work. I would also recommend
 anyone wanting to write this to first go to the
 [https://forum.djangoproject.com/c/internals/5 forum] to plan the outline
 and content.

 For these reasons I'm going to close this ticket as "invalid" but I
 welcome more discussion. I'm also very happy to read suggested
 documentation wording tweaks.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/35400#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f10bf23fe-97310bde-1393-486c-8f92-042e388297e3-000000%40eu-central-1.amazonses.com.

Reply via email to