WINC-482: Bring Your Own Windows Host design #608
Conversation
|
/cc @sdodson |
|
/cc @openshift/openshift-team-windows-containers |
|
/retest |
|
Thanks for getting us started on BYOH @aravindhp |
| ## Motivation | ||
|
|
||
| The world of Windows sees customers treating their instances more as "pets" | ||
| rather than "cattle". There is a desire from customers to be able to reuse these |
There was a problem hiding this comment.
What do we mean by reuse? Are the hosts going to be used for other purposes in addition to being OpenShift nodes? Do we have to worry about having substantial system reserved resources for non Kube managed services?
There was a problem hiding this comment.
From what I understand from @Anandnatraj customers have existing Windows instances that they would like to reuse as Windows workers. But you have a good point about having existing resources reserved for non-k8s serves which could cause issues for the kubelet. However the following stories should allow us to assign priorities to the k8s services:
React to setting kubelet priority flag
React to setting hybrid-overlay priority flag
| * Installing the container runtime in the Windows instance | ||
| * Managing the Windows operating system(OS) including handling of OS updates | ||
| * OpenShift Builds | ||
| * OpenShift DeploymentConfigs |
There was a problem hiding this comment.
Should we call out that this doesn't enable cross provider support, ie: vSphere IPI + Baremetal Windows Nodes? This comes up because cloud provider support is expected for all nodes and if you have some nodes with cloud provider support and some without then your cluster needs to be of platform None. I don't know to what extent windows nodes make use of cloud provider attach/detach of volumes so maybe that's not relevant to Windows nodes?
What about remote Windows worker nodes?
There was a problem hiding this comment.
I will call out that we only support adding Windows instances are attached to the same network that other Linux workers are attached to in the goal section. That should cover the cases you are talking about. We are trying hard to not muddy the waters by saying IPI, UPI or Bare Metal by saying BYOWH (Bring Your Own Windows Hosts).
| * Delete the payload binaries | ||
| * If the list of nodes has IP addresses that do not map to any in the list of | ||
| instances, and WMCO is unable to access the instance, it will assume that | ||
| the node in question is not managed by it. |
There was a problem hiding this comment.
Perhaps we should annotate or label the BYO windows nodes as being WMCO managed during the installation process so that we're more sure we have the authority to uninstall.
Same considerations as above with regard to privileges to manage node objects.
There was a problem hiding this comment.
We already have a couple of annotations for version and sshKey. Do you suggest having a separate annotation to indicate it is managed by WMCO?
| ## Motivation | ||
|
|
||
| The world of Windows sees customers treating their instances more as "pets" | ||
| rather than "cattle". There is a desire from customers to be able to reuse these |
There was a problem hiding this comment.
From what I understand from @Anandnatraj customers have existing Windows instances that they would like to reuse as Windows workers. But you have a good point about having existing resources reserved for non-k8s serves which could cause issues for the kubelet. However the following stories should allow us to assign priorities to the k8s services:
React to setting kubelet priority flag
React to setting hybrid-overlay priority flag
| * Installing the container runtime in the Windows instance | ||
| * Managing the Windows operating system(OS) including handling of OS updates | ||
| * OpenShift Builds | ||
| * OpenShift DeploymentConfigs |
There was a problem hiding this comment.
I will call out that we only support adding Windows instances are attached to the same network that other Linux workers are attached to in the goal section. That should cover the cases you are talking about. We are trying hard to not muddy the waters by saying IPI, UPI or Bare Metal by saying BYOWH (Bring Your Own Windows Hosts).
| * Delete the payload binaries | ||
| * If the list of nodes has IP addresses that do not map to any in the list of | ||
| instances, and WMCO is unable to access the instance, it will assume that | ||
| the node in question is not managed by it. |
There was a problem hiding this comment.
We already have a couple of annotations for version and sshKey. Do you suggest having a separate annotation to indicate it is managed by WMCO?
aravindhp
force-pushed
the
windows-byoh
branch
2 times, most recently
from
a6b4ad8
to
2c70a00
Compare
|
/retest |
Enhancement proposal for adding BYOH support to WMCO.
aravindhp
force-pushed
the
windows-byoh
branch
from
2c70a00
to
e7e4286
Compare
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sdodson 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 |
openshift-ci-robot
added
the
approved
|
Thanks for working on this @aravindhp |
Enhancement proposal for adding BYOH support to WMCO.