Add deprecated message to cachegroup/:parameter_id/parameter resp#3908
Add deprecated message to cachegroup/:parameter_id/parameter resp#3908mhoppa wants to merge 1 commit into
Conversation
|
I believe deprecations normally have to go through the mailing list. You probably wanna ask about Cache Group Parameters in general. |
|
@ocket8888 I noticed it was already marked as such in the documentation https://traffic-control-cdn.readthedocs.io/en/latest/api/cachegroup_parameterID_parameter.html Does that mean it has already gone through mailing list? |
|
Refer to this link for build results (access rights to CI server needed): |
|
Cache Group Params in general probably can't be deprecated since I'm pretty sure we actually use and depend on them (despite the absurdity of associating parameters to cachegroups). About the mailing list, we might want to group up all the endpoints we think we should deprecate in 1.1 and discuss the entire set at once on the mailing list. It will probably get pretty messy to discuss the deprecation of API endpoints one at a time on the mailing list. We might get better feedback with a full list too, because users can just take the whole list and check their usage of all the deprecated endpoints at once. |
|
RE: the docs deprecation stuff: I did that and I shouldn't have. When I was writing that endpoint's docs I'm sure I asked in an internal Slack channel "what is this?" and was told "we don't use that anymore" or something, so I added the deprecation notice without going through the proper procedure. I like @rawlinp's idea about a bulk deprecation thread. Seems it'll save a lot of time. |
| } | ||
|
|
||
| $self->success( { cachegroups => \@data } ); | ||
| $self->success( { cachegroups => \@data }, "API path is deprecated use /cachegroupparameters instead"); |
There was a problem hiding this comment.
"Success" is a bit of a weird type of message for something that's more of a warning about a deprecation. This should use the "warning" level instead, imo.
There was a problem hiding this comment.
what are the alert "levels"? success, error, warning and info?
There was a problem hiding this comment.
i thought you could return an array of alerts. if so, what about 1 success message (for the successful assignment of a param to a cg) and 1 warning message with the deprecation message? or is that weird?
There was a problem hiding this comment.
No I think that is what we want to do! THat would match the work that was done #3954
|
Closing pull request as how we are approaching deprecation is being decided in the mailing list and even if we did decide to deprecate in perl this PR would need some work |
5 participants
What does this PR (Pull Request) do?
Which Traffic Control components are affected by this PR?
There is not a change to documentation as it is already mark deprecated in there.
What is the best way to verify this PR?
Start up Perl TO locally with change and make a request to it. On success you should receive back a response that has an alert section with deprecate messaging
If this is a bug fix, what versions of Traffic Control are affected?
The following criteria are ALL met by this PR