-
Notifications
You must be signed in to change notification settings - Fork 617
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
Add internal-network-name networking option #444
Conversation
This will help in case of multi-nic k8s node deployments. Previously, cloud provider was assigning all addresses in random order and k8s was selecting only one of them. But usually, multi-nic scenario requires to specify which network is "control" and admins want to bind kubelet listening address only to that "control" net. This commit will not affect previous logic until internal-network-name is specified in cloud-config file. Related to: kubernetes#407 Change-Id: I1e4076b853b12020c47529b0590f21523b9d26a8
Hi @mogaika. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Build failed.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
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
/ok-to-test |
/retest |
I'd suggest we at least add some info (maybe a followup) patch on how this can be configured to avoid read code to find where to set internal network |
Build succeeded.
|
Build failed.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: zetaab 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 |
/retest |
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
Build succeeded.
|
/lgtm |
When there is more than one NIC attached to an instance, openstack cloud provider returns a random InternalIP back to the host resulting in instability with API server which only talks to a default interface. This patch incorporates the changes made in kubernetes/cloud-provider-openstack#444 which enables OpenStack Cloud Controller Manager to respect the `internal-network-name` in cloud-config file which ensures that InternalIP remains stable. Story: 2005333 Task: 30271 Change-Id: I9e3ad459dd05753b53cb4ce75ee3aed649fef196
* Update magnum from branch 'master' - Merge "Specify internal network to improve stability in a multi-NIC scenario." - Specify internal network to improve stability in a multi-NIC scenario. When there is more than one NIC attached to an instance, openstack cloud provider returns a random InternalIP back to the host resulting in instability with API server which only talks to a default interface. This patch incorporates the changes made in kubernetes/cloud-provider-openstack#444 which enables OpenStack Cloud Controller Manager to respect the `internal-network-name` in cloud-config file which ensures that InternalIP remains stable. Story: 2005333 Task: 30271 Change-Id: I9e3ad459dd05753b53cb4ce75ee3aed649fef196
When there is more than one NIC attached to an instance, openstack cloud provider returns a random InternalIP back to the host resulting in instability with API server which only talks to a default interface. This patch incorporates the changes made in kubernetes/cloud-provider-openstack#444 which enables OpenStack Cloud Controller Manager (OCCM) to respect the `internal-network-name` in cloud-config file which ensures that InternalIP remains stable. Uses a separate cloud-config file for OCCM to ensure in-tree Cinder volumes remain compatible. Change-Id: Idfa52ed2d512e7dc383a556371e896205dd542f9 Story: 2005333 Task: 30271
* Update magnum from branch 'master' - Merge "Add network config to stabilise multi-NIC scenario" - Add network config to stabilise multi-NIC scenario When there is more than one NIC attached to an instance, openstack cloud provider returns a random InternalIP back to the host resulting in instability with API server which only talks to a default interface. This patch incorporates the changes made in kubernetes/cloud-provider-openstack#444 which enables OpenStack Cloud Controller Manager (OCCM) to respect the `internal-network-name` in cloud-config file which ensures that InternalIP remains stable. Uses a separate cloud-config file for OCCM to ensure in-tree Cinder volumes remain compatible. Change-Id: Idfa52ed2d512e7dc383a556371e896205dd542f9 Story: 2005333 Task: 30271
When there is more than one NIC attached to an instance, openstack cloud provider returns a random InternalIP back to the host resulting in instability with API server which only talks to a default interface. This patch incorporates the changes made in kubernetes/cloud-provider-openstack#444 which enables OpenStack Cloud Controller Manager (OCCM) to respect the `internal-network-name` in cloud-config file which ensures that InternalIP remains stable. Uses a separate cloud-config file for OCCM to ensure in-tree Cinder volumes remain compatible. Conflicts: magnum/drivers/common/templates/kubernetes/fragments/write-kube-os-config.sh magnum/drivers/k8s_fedora_atomic_v1/templates/kubemaster.yaml Change-Id: Idfa52ed2d512e7dc383a556371e896205dd542f9 Story: 2005333 Task: 30271 (cherry picked from commit 425fb0f)
When there is more than one NIC attached to an instance, openstack cloud provider returns a random InternalIP back to the host resulting in instability with API server which only talks to a default interface. This patch incorporates the changes made in kubernetes/cloud-provider-openstack#444 which enables OpenStack Cloud Controller Manager (OCCM) to respect the `internal-network-name` in cloud-config file which ensures that InternalIP remains stable. Uses a separate cloud-config file for OCCM to ensure in-tree Cinder volumes remain compatible. Conflicts: magnum/drivers/common/templates/kubernetes/fragments/write-kube-os-config.sh magnum/drivers/k8s_fedora_atomic_v1/templates/kubemaster.yaml Change-Id: Idfa52ed2d512e7dc383a556371e896205dd542f9 Story: 2005333 Task: 30271 (cherry picked from commit 425fb0f)
Add internal-network-name networking option
What this PR does / why we need it:
This will help in case of multi-nic k8s node deployments.
Previously, cloud provider was assigning all addresses in random
order and k8s was selecting only one of them. But usually,
multi-nic scenario requires to specify which network is
"control" and admins want to bind kubelet listening address only
to that "control" net.
This commit will not affect previous logic until
internal-network-name is specified in cloud-config file.
Which issue this PR fixes: fixes #407
Special notes for your reviewer:
Release note: