-
Notifications
You must be signed in to change notification settings - Fork 534
Windows Containers productization design #5
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
Windows Containers productization design #5
Conversation
sdodson
left a comment
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.
lgtm for 4.3, provides flexibility to adapt in the future
aa75653 to
ae78830
Compare
ae78830 to
2173dda
Compare
windows-containers/productization.md
Outdated
| ## Summary | ||
|
|
||
| The intent of this enhancement is to allow a cluster administrator to add a | ||
| Windows worker node with a prescribed configuration to an OpenShift cluster as a |
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.
nit: s/worker/compute/, e.g. see the old openshift/installer#1330. Overhauling existing wording it hard, but no reason new stuff can't use the new wording :).
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 will make that change in all places. So is it compute Ignition or worker Ignition?
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.
Unless the machineconfigpool is changing to compute I think we should leave this as is.
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.
@sdodson is your comment against s/worker/compute/ or just the Ignition case?
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.
just in relation to Ignition
windows-containers/productization.md
Outdated
| ### Goals | ||
|
|
||
| As part of this enhancement we plan to do the following: | ||
| * Prepare an already provisioned Windows worker node to join the cluster |
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.
Clarify the boundary between things the end-user does (just create a machine running Windows) and things Red Hat (tooling) does (install a kubelet, etc. etc.)? Currently that's all swept into "provision" and "Prepare". Maybe something like:
As part of this enhancement we plan to provide workflows for installing and upgrading OpenShift compute components (kubelet, OVN, and the Windows Machine Config Bootstrapper) on user-provided Windows machines. It will be up to the cluster administrator to initiate both installs and upgrades.
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 will go with your suggestion.
windows-containers/productization.md
Outdated
|
|
||
| The inputs that the WMCB requires are: | ||
| * kubelet location on the local disk | ||
| * Worker ignition location on the local disk |
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.
nit: s/ignition/Ignition/
| We plan to have all the repositories associated with this effort fully | ||
| integrated with Prow CI and run e2e tests for every PR that is opened. These | ||
| e2e tests will involve bringing up a cluster on all supported cloud providers, | ||
| instantiating a Windows node and running workloads on it. We also plan to add |
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.
This doesn't cover upgrade/downgrade testing. Probably call that out specifically and say whether or not you plan on covering it in CI.
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.
We are not planning on covering upgrade/downgrade testing using CI in the 4.3 timeframe. I will mention that.
windows-containers/productization.md
Outdated
|
|
||
| ### Version Skew Strategy | ||
|
|
||
| We plan to maintain kubelet major version parity with the Linux counterpart. |
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.
You'll have to have skew during upgrades across the boundary though. Maybe say something about having CI coverage when we get to that point so you can ensure that at least some Windows kubelets will successfully handle lagging by one major version behind the rest of the cluster. Or say that before a major bump folks might have to drain/wipe their Windows compute and re-attach them as fresh compute after the major bump?
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.
We are planning on advising the customer to exactly what is done in the BYO RHEL scenario i.e. drain the Windows compute nodes using the Ansible playbook. I will add a line about that.
Initial enhancement proposal for productization of Windows Containers that will enable running of Windows workloads on an OpenShift cluster.
2173dda to
ebb0e03
Compare
|
@wking I have addressed your comments. Please take a look. |
|
@crawford - Can you LGTM the PR? |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aravindhp, crawford, sdodson The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
|
||
| The actions that the WMCB will perform are: | ||
| * Install / upgrade and configure the kubelet | ||
| * Parse the worker Ignition and extract the bootstrap kubeconfig and the |
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.
kubelet configuration varies for linux versus windows hosts, this has to be a separate pool.
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.
It's only used for the cluster coordinates and bootstrapping credentials.
English mistake: sums up => adds up
Updates for master -> main branch renamings
OCPEDGE-1458: Addressing post-architecture review feedback
Initial enhancement proposal for productization of Windows Containers that will enable running of Windows workloads on an OpenShift cluster.