Enable API-versioning and allow for both v3 and v4 versions.#7802
Enable API-versioning and allow for both v3 and v4 versions.#7802ggainey wants to merge 1 commit into
Conversation
75e4f88 to
fcdcf5b
Compare
d38417a to
1d45f72
Compare
|
|
||
| result = models.JSONField(default=None, null=True, encoder=DjangoJSONEncoder) | ||
|
|
||
| version = models.TextField(default=REST_FRAMEWORK.get("DEFAULT_VERSION", "v3")) |
There was a problem hiding this comment.
"version" as an attribute is "magic" at the DRF level - it's what gets filled in by the content of the <str:version> slug in the urlpattern. I debated on exactly this - but making it "version" means it's filled directly by the incoming **kwargs to the view, naming it anything else means calling it out specifically. I could be convinced of either.
There was a problem hiding this comment.
I was just abit afraid that we could be confusing here. And changing a database column name later is a pain.
(Pulp is in the domain for versioning on all levels. Pulp-version, pulp-api-version, repository-version, deb-version, rpm-version, ansible-collection-version, ...)
|
|
||
| version = serializers.CharField( | ||
| help_text=_("The API-version that was invoked when creating the task."), | ||
| default=REST_FRAMEWORK.get("DEFAULT_VERSION", "v3"), |
There was a problem hiding this comment.
| default=REST_FRAMEWORK.get("DEFAULT_VERSION", "v3"), |
I don't think we need this, tasks will never be created via this serializer.
There was a problem hiding this comment.
Possibly so, will dig a bit.
There was a problem hiding this comment.
I don't think we need this, tasks will never be created via this serializer.
You would think, but I remember there being some surprising ways and places in which the serializers were getting initialized.
| _current_user_func = ContextVar("current_user", default=lambda: None) | ||
| _current_domain = ContextVar("current_domain", default=None) | ||
| x_task_diagnostics_var = ContextVar("x_profile_task") | ||
| _current_pulp_version = ContextVar( |
There was a problem hiding this comment.
Comment: Is this really how we want to "know" what pulp-version we are operating under? Author, please review!
(also - even if we keep this, name needs to be _current_pulp_api_version)
There was a problem hiding this comment.
That I kind ow liked. It's non-invasive, yet omnipresent inside the task code.
|
RE ENABLE_V4_API : I am going to turn it on in this PR, in order to make sure CI runs clean with it enabled. BEFORE WE MERGE, we will turn it OFF, and let ppl who want to experiment "opt-in" to it, for several releases. |
a06b01e to
949527d
Compare
This is a tech-preview PR, and will only "turn on" if the ENABLE_V4_API is set to True in settings. It will allow urls for /v3/ and /v4/, and reject other versions. For urlpatterns registered with a `/<str:version>/` slug, views will be called with a `version=` kwarg. NOTE: To play this game, plugins will need to insure that all views accept `**kwargs` first, and then update the patterns in their `urls.py` to include the version-slug. See the `/status/` view and serializer(s) for an example of how to respond based on the incoming request. NOTE to implementers: **existing tests must pass without changes** whether the ENABLE flag is True or False. If that isn't the case - you're doing something wrong. closes pulp#6462
This is a tech-preview PR, and will only "turn on" if the ENABLE_V4_API is set to True in settings.
It will allow urls for /v3/ and /v4/, and reject other versions.
For urlpatterns registered with a
/<str:version>/slug, views will be called with aversion=kwarg.NOTE: To play this game, plugins will need to insure that all views accept
**kwargsfirst, and then update the patterns in theirurls.pyto include the version-slug.See the
/status/view and serializer(s) for an example of how to respond based on the incoming request.NOTE to implementers: existing tests must pass without changes whether the ENABLE flag is True or False. If that isn't the case - you're doing something wrong.
closes #6462