Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PULP-210] Update deprecated django storage config #6058

Merged

Conversation

pedro-psb
Copy link
Member

@pedro-psb pedro-psb commented Nov 20, 2024

Summary

The setting DEFAULT_FILE_STORAGE / STATCIFILES_STORAGE was deprecated in django 4.2. They've implemented a compatibility layer to enable this legacy setting to be mapped to the new STORAGES, so users could gradually move and Pulp codebase to update to using only STORAGES.

The problem is that Pulp overrides the default (using the legacy setting name), so users can't really use STORAGE, as it raises a django exceptions on mutual exclusion.

This PR does:

  1. Updates the codebase to rely on settings.STORAGES instead of DEFAULT_FILE_STORAGE
  2. Enable users to start using STORAGES on their settings
  3. Use both legacy and new setting in CI (s3 / azure) for sanity testing

Open questions:

  • Removal deadline: I'm suggesting that we remove it on 3.85 or 4.0, but we could choose something else. Deciding this is important so we can give a proper heads up for our users and stakeholders.

Plugins TODO

  • Check whether the signal handling (on app/apps.py) uses a module-level settings. That could cause errors, so it needs to be moved inside the AppConfig class
  • Use STORAGES internally instead of DEFAULT_FILE_STORAGE and STATICFILES_STORAGE

Closes #5404

@pedro-psb pedro-psb force-pushed the update-deprecated-django-storage-config branch 4 times, most recently from ba1fb1a to fb6f05d Compare November 21, 2024 21:19
@pedro-psb pedro-psb changed the title Update deprecated django storage config [PULP-210] Update deprecated django storage config Nov 28, 2024
@pedro-psb pedro-psb force-pushed the update-deprecated-django-storage-config branch 13 times, most recently from 3890c05 to e9be44c Compare December 13, 2024 20:59
@pedro-psb pedro-psb force-pushed the update-deprecated-django-storage-config branch 5 times, most recently from 6aa2681 to 94f262b Compare December 17, 2024 19:47
@pedro-psb pedro-psb marked this pull request as ready for review December 17, 2024 19:47
Comment on lines +518 to +519
storages._backends = settings.STORAGES.copy()
storages.backends
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the "magic" to prevent django storages to see both items we set before?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, Django in fact has both set in their default global_settings.
But the previous hack caused a sife-effect on a specific point of django startup where it tries to get those values with a method that can't see the patch we made. The storages is a cached property, so it would hold the wrong value forever.

Line 518 does exactly what they do here.
Line 519 triggers the value to be cached.

All this magic is to give users a larger time span to upgrade.

Comment on lines +79 to +80
setattr(global_settings, "DEFAULT_FILE_STORAGE", _DEFAULT_FILE_STORAGE)
setattr(global_settings, "STORAGES", _STORAGES)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting them both here seems to contradict that they are, as you say, "mutually exclusive".

Copy link
Member Author

@pedro-psb pedro-psb Dec 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "global setting" settings is the only place where django won't complain about exclusivity. It will perform this check on a different context.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds weird, but I'll take your word that it works.

@@ -0,0 +1 @@
Removed `DEFAULT_FILE_STORAGE` setting in favour of the new `STORAGES` options introduced in Django 4.2.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand, this is a hard breaking change for plugins with storage specific code, right?
Or can plugins still "see" the old setting alongside the new one?

Also we want users to migrate to the new setting (sooner than later). You should add a second changelog for that.

Copy link
Member Author

@pedro-psb pedro-psb Dec 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This message is not very accurate, forget to update it.
What I'm really doing is (1) updating codebase to use STORAGES + (2) allowing users to use either of both. I guess it can be two entries, with the second one stressing that now users should start migrating.

Django copies the value of DEFAULT_FILE_STORAGE to STORAGES, but not the other way around.
So yes, plugins should use STORAGES internally (I overlooked that fact).

@pedro-psb pedro-psb force-pushed the update-deprecated-django-storage-config branch from 94f262b to 6be238c Compare December 18, 2024 14:58
Copy link
Member

@mdellweg mdellweg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just nitpicking on the changelogs...

Started using `STORAGES` internally instead of `DEFAULT_FILE_STORAGE` and `STATICFILES_STORAGE`,
which was deprecated in Django 4.2.

For compatibility, plugins should replace access to:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
For compatibility, plugins should replace access to:
For compatibility, plugins must replace access to:

Use strong words where appropriate...

Comment on lines 2 to 3
These legacy settings were deprecated in Django 4.2 and will be removed in Pulp 3.85 or Pulp 4,
whichever comes first.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
These legacy settings were deprecated in Django 4.2 and will be removed in Pulp 3.85 or Pulp 4,
whichever comes first.
These legacy settings were deprecated in Django 4.2 and will be removed in Pulp 3.85.

I appreciate the effort to get the pulp 4 idea out, but i think that part is implicit and my drag the attention away from what is important here.
Or put another way. I think we can at any time in the future claim that pulp 3.(70+n*15) will actually be pulp 4 and it will inherit the deprecations naturally.

@pedro-psb pedro-psb force-pushed the update-deprecated-django-storage-config branch from 6be238c to 5a4dcc0 Compare December 18, 2024 15:46
CHANGES/plugin_api/5404.removal Outdated Show resolved Hide resolved
@@ -11,7 +11,6 @@

from pulpcore.tests.functional.utils import get_files_in_manifest, download_file

from pulpcore.app import settings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh dear, this test was mixing both "imports"...?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it was

Comment on lines 70 to 77
# Workaround for getting the up-to-date settings instance.
# A module-level settings import is a cached version from before dynaconf do its work.
from django.conf import settings

self.settings = settings
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this part of the deprecation compatibility layer?
If so, please mark it accordingly so we know when to remove again.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, will do

@pedro-psb pedro-psb force-pushed the update-deprecated-django-storage-config branch from 347da3b to 1dc0342 Compare January 2, 2025 17:00
Django deprecated the use of DEFAULT_FILE_STORAGES and STATICFILES_STORAGE
in v4.2 and removed it in v5.0.

It provides a compat layer in 4.2, so even if the user set this value
using the legacy key, the value will be available in django.conf.settings
as:

*  settings.STORAGES['default']['BACKEND']  # default storage
*  settings.STORAGES['staticfiles']['BACKEND']  # staticfiles storage

This commit updates the codebase to use the new value.
@pedro-psb pedro-psb force-pushed the update-deprecated-django-storage-config branch 2 times, most recently from 1b6b66a to c34c168 Compare January 8, 2025 19:46
mdellweg
mdellweg previously approved these changes Jan 9, 2025
Copy link
Member

@mdellweg mdellweg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to merge.
I was just wondering if the user facing changelog should be moved to the decprecations section (It includes a deprecation for 3.85).

@pedro-psb
Copy link
Member Author

I'll do that. I didnt want to use .removal because its not removed yet, but this better conveys the intent.

@mdellweg
Copy link
Member

mdellweg commented Jan 9, 2025

If you look, the title for ".removal" will be "Deprecations and Removals".

@pedro-psb pedro-psb force-pushed the update-deprecated-django-storage-config branch from c34c168 to d771a25 Compare January 9, 2025 14:57
@pedro-psb pedro-psb enabled auto-merge (rebase) January 9, 2025 15:58
@pedro-psb pedro-psb merged commit 2256ff4 into pulp:main Jan 9, 2025
12 checks passed
@pedro-psb pedro-psb deleted the update-deprecated-django-storage-config branch January 9, 2025 17:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Django DEFAULT_FILE_STORAGE deprecated
2 participants