Postpone stabilization of new RPCAPI methods and config properties#1162
Conversation
* Re-stabilize the old RPCAPI methods. * Mark the new RPCAPI methods as experimental. * Reinstate references to enable_add_api_user and enable_add_batch_job.
* Re-stabilize the old config properties. * Characterize the new config properties as experimental aliases.
ghost
left a comment
There was a problem hiding this comment.
This looks fine. Just a non blocking remark.
|
|
||
| If defined, the [enable_batch_create][RPCAPI.enable_batch_create] | ||
| property takes precedence over this. | ||
| An experimental alias for [enable_add_batch_job][RPCAPI.enable_add_batch_job]. |
There was a problem hiding this comment.
Good idea to make it an alias. I'm not sure I've implemented it that way in zonemaster/zonemaster-backend#1111. I totally can update zonemaster/zonemaster-backend#1111 to make it an alias. Should I wait for this PR to be merged or approved to do that?
There was a problem hiding this comment.
I thought it was your good idea to make it an alias :) That's how I read zonemaster/zonemaster-backend#1111. But now that I looked at it again I found a couple of flaws in this interpretation.
- They have different default values.
- When you specify RPCAPI.enable_add_batch_job twice you get an error, but if you specify both RPCAPI.enable_add_batch_job and RPCAPI.enable_user_create the maximum value takes precedence.
Merging either the interface or the implementation before the other exposes us to the risk of having to go back. Ideally I think the interface and the implementation should be merged in the same PR, but now they're in separate repositories, so I guess the next best thing is to leave both open until both are sufficiently approved.
tgreenx
left a comment
There was a problem hiding this comment.
Two comments otherwise LGTM.
|
|
||
| If defined, the [enable_batch_create][RPCAPI.enable_batch_create] | ||
| property takes precedence over this. | ||
| An experimental alias for [enable_add_batch_job][RPCAPI.enable_add_batch_job]. |
27f4fbd to
e68ba0c
Compare
|
AFAICT this PR is done. I've gotten a few reviews, addressed all comments up to this point and everybody seems to like the "alias" line. I'm leaving it open until the implementation is done too so they can be merged at the same time. But don't be afraid to add more reviews or discussion on the design. I'll address those as well. |
713663b to
f649f13
Compare
|
I found a couple more broken links related to the ones @tgreenx pointed out, so I pushed another commit for those. Please review the last commit. Sorry for the inconvenience. I also found a whole bunch of other broken links, but I'm deferring those to a separate PR. |
f649f13 to
e73b998
Compare
Purpose
This PR re-stabilizes the old RPCAPI methods and config properties and marks the new ones as experimental.
Context
Fixes #1159.
Changes
How to test this PR
It would make sense to check the following things:
RPCAPI.enable_add_api_userRPCAPI.enable_add_batch_jobRPCAPI.enable_user_createRPCAPI.enable_batch_create