-
Notifications
You must be signed in to change notification settings - Fork 1.4k
📖 More documentation on v1.11 migration #12236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
📖 More documentation on v1.11 migration #12236
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left comments once. I'll see it in detail later.
A provider can continue to use deprecated v1beta1 conditions also after bumping to CAPI V1.11, but to do | ||
it is require to change following imports: | ||
|
||
```go |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it work correctly ?
It looks like that syntax highlight is broken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- `status.failureReason` and `status.failureMessage` will continue to exist temporarily under `status.deprecated.v1beta1`. | ||
- The const values for `Failed` phase has been deprecated in the enum type for `machinePool.status.phase` (controllers are not setting this value anymore) | ||
|
||
### Machine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it ok not to write about minReadySeconds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we didn't merge any changes related to minReadySeconds yet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, ideally each PR should document it's own bits, this reduces the chance of missing something
# Conflicts: # docs/book/src/developer/providers/migrations/v1.10-to-v1.11.md
3407812
to
24898cc
Compare
Thank you very much! /lgtm |
LGTM label has been added. Git tree hash: 0103a5ae54b557223dd9d1bc1334cfe81ec96f52
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbueringer 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 |
What this PR does / why we need it:
Another iteration on v1.11 migration doc
@sbueringer please check documentation for changes introduced by your recent PRs (I hope everything is captured)
@chrischdi @sivchari please check documentation about providers changes based on your experience in CAPV/CAPD
/area documentation