🌱 add api upgrade flow #265
Conversation
Signed-off-by: haoqing0110 <qhao@redhat.com>
|
cc @zhujian7 we might work together to refine the API migration flow. |
docs/development.md
Outdated
|
|
||
| ### Relase N (add new version and depracated old version) | ||
| - Add new version v1beta2 API and mark v1beta1 as deprecated. For example: |
There was a problem hiding this comment.
My understanding is we mark it deprecated when we change the stored version?
There was a problem hiding this comment.
Sounds makes sense.
In our previous releases, we tended to add new API and mark the old version deprecated first, letting the user know it's deprecated for at least 1 release and then start migration in the next release.
Now we have some experience in migration, it's okay to mark it deprecated when changing the stored version in release N+1.
There was a problem hiding this comment.
have updated the doc, also with some tips on how to set the served and storage version.
haoqing0110
force-pushed
the
br_api-upgrade
branch
from
d09cd9d
to
3fd76d2
Compare
|
also need to check here https://github.com/open-cluster-management-io/community/blob/main/sig-architecture/api_changes.md on what is updated. |
haoqing0110
force-pushed
the
br_api-upgrade
branch
from
3fd76d2
to
9b61174
Compare
|
https://github.com/open-cluster-management-io/community/blob/main/sig-architecture/api_changes.md is a useful addition to this flow, append some URLs to the related part. |
Signed-off-by: haoqing0110 <qhao@redhat.com>
haoqing0110
force-pushed
the
br_api-upgrade
branch
from
9b61174
to
765c3de
Compare
| ### Relase N+1 (deprecated old version and start migration) | ||
| - Mark v1beta1 as deprecated, served versions are v1beta1 and v1beta2, set storage: true on v1beta2. | ||
|
|
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
There was a problem hiding this comment.
@qiujian16 Please take another review, should we put this flow into best-practice?
There was a problem hiding this comment.
The risk we concerns here is this flow hasn't been verified by history. We never process in this way before, it's just a design.
|
@qiujian16 @elgnay @xuezhaojun plz help do a final review. |
haoqing0110
force-pushed
the
br_api-upgrade
branch
from
8e61c67
to
e5dbb3e
Compare
|
|
||
| In registration-operator it has a migration controller and crd status controller to handle the progress, code example: | ||
| - https://github.com/open-cluster-management-io/registration-operator/pull/315 |
There was a problem hiding this comment.
@xuezhaojun thanks, have updated this example in the doc.
docs/development.md
Outdated
| ### Relase N+x (remove old version) | ||
|
|
||
| when the new version API becomes mature, and ready to remove old version (for example, the consumers have adopted the new version API), remove the old version related code: |
There was a problem hiding this comment.
we need to clarify what READY means. What needs to be checked to ensure it is ready to remove the old version.
Signed-off-by: haoqing0110 <qhao@redhat.com>
haoqing0110
force-pushed
the
br_api-upgrade
branch
from
e5dbb3e
to
ee518db
Compare
|
/approve @xuezhaojun leave to you for final review |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: haoqing0110, qiujian16 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
openshift-merge-bot
bot
merged commit 04e951f
into
open-cluster-management-io:main
Summary
Related issue(s)
Fixes #