[BD-21] Move waffle_utils from edx-platform to edx-toggles - #25286
Conversation
|
Thanks for the pull request, @regisb! I've created BLENDED-618 to keep track of it in Jira. More details are on the BD-21 project page. When this pull request is ready, tag your edX technical lead. |
e429964 to
8e05827
Compare
|
@robrap This is ready to review. |
robrap
left a comment
There was a problem hiding this comment.
First pass review. Thanks.
robrap
left a comment
There was a problem hiding this comment.
My comments aren't adding much value at this point. I need to have time to review more deeply. I also need to review the edx-toggles code along with this, which I haven't done. :)
There was a problem hiding this comment.
I still need time to review, but if the old callback was not a required solution, then it was not a great solution. :) I will review more deeply to check that all seems well. Thanks.
2f2a2a5 to
48e3e29
Compare
There was a problem hiding this comment.
I'll admit that I am scared of this approach. Merging this is going to change all flags at once in a way that we hope is backward compatible. We will then have another large refactor when removing namespacing that will again affect all flags at once.
My original proposed approach would have introduced the new classes as we wanted them into edx-toggles, without namespacing. We could have just updated each flag once, and started with just one flag, or a few at a time, to ensure everything went ok before doing a larger batch or all the rest. My approach seems much safer. I need help understanding the downside to what I am proposing.
For CourseWaffleFlag (and ExperimentWaffleFlag), we would need a new CourseWaffleFlag2 (or some such name) that subclasses the new classes, and we could switch and test a few. When we are happy that all is well, we could replace CourseWaffleFlag with CourseWaffleFlag2 code and the rest would be on the new code.
UPDATE: I have low confidence in my hesitation. It may be I should just do some extra manual testing in a sandbox once we think this is ready.
There was a problem hiding this comment.
FYI: The whole point of this temporary class is because we used to have the capability to set a default for WaffleFlag and WaffleSwitch, but we removed it because it was too confusing having the value for a flag or switch possibly coming from the database and possibly coming from code. With the new toggle state endpoint, we can now see the values combining what is in the db and what is in code, so it may make sense to simply restore this functionality. If we decide to restore this, it would be in follow-up PRs.
d9cd96e to
865f992
Compare
|
Thanks again @regisb.
|
865f992 to
2fca046
Compare
|
@robrap I have rebased and added a |
cccacf3 to
6be58c1
Compare
|
Thanks @regisb. I will merge in the morning. Feel free to remind me if I forget. |
There was a problem hiding this comment.
Oops. I left a nit comment in a later PR: https://github.com/edx/edx-platform/pull/25417#discussion_r513890482
robrap
left a comment
There was a problem hiding this comment.
@regisb: I found a 2 layered bug in the toggle state endpoint. Would you be able to address these?
- edx-django-utils method
get_code_owner_from_moduleshould probably not error if sent None, but should just return None. - The toggle state endpoint probably shouldn't be calling the above method with module of None. This may not be an issue if the first one is addressed?
Traceback (most recent call last):
File "/edx/app/edxapp/venvs/edxapp/lib/python3.8/site-packages/django/core/handlers/exception.py", line 34, in inner
...
File "/edx/app/edxapp/edx-platform/openedx/core/djangoapps/waffle_utils/views.py", line 28, in get
File "/edx/app/edxapp/edx-platform/openedx/core/djangoapps/waffle_utils/views.py", line 86, in _get_all_waffle_flags
File "/edx/app/edxapp/edx-platform/openedx/core/djangoapps/waffle_utils/views.py", line 102, in _add_waffle_flag_instances
File "/edx/app/edxapp/edx-platform/openedx/core/djangoapps/waffle_utils/views.py", line 111, in _add_toggle_instance_details
File "/edx/app/edxapp/venvs/edxapp/lib/python3.8/site-packages/edx_django_utils/monitoring/code_owner/utils.py", line 29, in get_code_owner_from_module
@robrap The fix looks easy enough. Should I do it in this PR, or in another one? |
|
@regisb: I think you can fix that in this PR. I think it was caused by this PR. Forget about the edx-django-utils side of the fix for now. I (or you) can do that later. Let's just not call |
robrap
left a comment
There was a problem hiding this comment.
Also, I though I saw a test patching get_code_owner_from_module, but I don't see it now. Could it also use the public API, rather than utils, since it is going to move to an /internal directory.
ede1f5b to
36db9ef
Compare
I grew tired of modifying the Makefile to compile requirements without upgrading them. Also, installing pip-tools should not be part of the compile-requirements target, so a separate target was created.
This makes this class reusable by other IDAs.
This simplifies the internals of the waffle flag classes in order to better move them to edx-toggles later.
The same API is preserved, internally, to avoid many changes across the edx-platform codebase (for now).
Note that those features are destined to be deprecated, eventually.
edx-toggles==2.0.0 is likely to suppress namespace objects for the management of toggle objefcts. We explicitely prevent this by adding a requirement constraint.
When module_name is None, the call to edx-django-utils' get_code_owner_from_module crashes. So we avoid making that call when the module_name is None, which sometimes happens (for good reasons or not, but it's valid behaviour).
36db9ef to
312f0cd
Compare
|
Ok I rebased my commits, this should be ready to merge! 🚀 |
|
Your PR has finished running tests. There were no failures. |
|
@regisb: I retested this and will merge in the morning. Thank you! For a follow-up PR at some point, the difference I saw in the toggle state endpoint on a sandbox was: After: As I noted earlier, my preference would be that we drop |
|
EdX Release Notice: This PR has been deployed to the staging environment in preparation for a release to production. |
|
EdX Release Notice: This PR has been deployed to the production environment. |
This PR depends on openedx/edx-toggles#70
cc @robrap
TODO: