Skip to content
This repository has been archived by the owner on Jul 24, 2019. It is now read-only.

docs: ovs-vswitchd container configured to use interfaces 'enp11s0f0' and 'enp12s0f0' #295

Open
Ananth-vr opened this issue Mar 20, 2017 · 8 comments

Comments

@Ananth-vr
Copy link

Ananth-vr commented Mar 20, 2017

Is this a bug report or feature request? (choose one):
Documentation feature request

Explanation
Compute nodes are with interfaces eth0,eth1,eth2,eth3 ie with biosdevname=0 .Hence ovs-vswitchd container bridges are not configured correctly.
Its expecting interface name to be
enp11s0f0 and enp12s0f0
kubectl exec ovs-vswitchd-xzqsc -n openstack -- ovs-vsctl list-ports br-physnet1
enp11s0f0
phy-br-physnet1

kubectl exec ovs-vswitchd-xzqsc -n openstack -- ovs-vsctl list-ports br-ex
enp12s0f0

Error
kubectl exec ovs-vswitchd-xzqsc -n openstack -- ovs-vsctl show |grep No
error: "could not open network device enp11s0f0 (No such device)"
error: "could not open network device enp12s0f0 (No such device)"

Kubernetes Version
kubectl version
Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"08e099554f3c31f6e6f07b448ab3ed78d0520507", GitTreeState:"clean", BuildDate:"2017-01-12T04:57:25Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.4", GitCommit:"7243c69eb523aa4377bce883e7c0dd76b84709a1", GitTreeState:"clean", BuildDate:"2017-03-07T23:34:32Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

Helm Client and Tiller Versions
Client: &version.Version{SemVer:"v2.2.2", GitCommit:"1b330722aafcb8123114ae51f69d1e884a326f3e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.2.2", GitCommit:"1b330722aafcb8123114ae51f69d1e884a326f3e", GitTreeState:"clean"}

Development or Deployment Environment?:
Deployment

Expected Behavior:
ovs-vsctl should not return no such device
What Actually Happened:
Error in ovs-vsctl list-ports
How to Reproduce the Issue (as minimally as possible):
Add a compute node with interface named eth* ie biosdevname=0
Any Additional Comments:
Add documentation for br-ex and br-physnet1 physical interfaces and expected name for that.

@v1k0d3n
Copy link
Collaborator

v1k0d3n commented Mar 20, 2017

i'm hesitant to call this a "bug". to be clear for any members that pick this up, this is mainly a documentation request as values.yaml are can be overridden. we do want to pick some potentially more interfaces that are more "sane" than enp11s0f0 and enp12s0f0, and document where physnet is coming from.

@v1k0d3n v1k0d3n changed the title ovs-vswitchd container configured to use interfaces 'enp11s0f0' and 'enp12s0f0' docs: ovs-vswitchd container configured to use interfaces 'enp11s0f0' and 'enp12s0f0' Mar 20, 2017
@intlabs
Copy link
Contributor

intlabs commented Mar 22, 2017

We should perhaps consider changing these to old style device names e.g. eth0 etc in the defaults when updating the documentation.

@v1k0d3n
Copy link
Collaborator

v1k0d3n commented Mar 22, 2017

@intlabs already planning on it.

@v1k0d3n
Copy link
Collaborator

v1k0d3n commented Mar 23, 2017

i think it goes a bit beyond just documentation though. i really think that the interfaces used currently (enp11s0f0 and enp11s0f0) are terrible examples (they were PoC for our use-case). i think we can edit values.yaml for more sane defaults (eth0 and eth1 or perhaps even eth2). i'm working on the issue, and testing in a lab that actually has these interfaces set up.

@v1k0d3n
Copy link
Collaborator

v1k0d3n commented Mar 29, 2017

a community member @RichWellum has offered to look into and pick this one up. leaving it assigned to myself so he can work this item.

@wilkers-steve
Copy link
Contributor

I haven't seen much activity on this from @RichWellum. We can work on tidying this up once we move into OpenStack and decide on some more sane defaults if necessary. We can also make sure the ability to override these to any interface desired is clear (if not clear already). I think we can safely close this issue out. @intlabs @larryrensing thoughts?

@v1k0d3n
Copy link
Collaborator

v1k0d3n commented Apr 7, 2017

@wilkers-steve can we leave issues open, and close PR's that aren't applicable? we'll have an exercise of collecting all the open issues, and creating bugs/blueprints when we get into openstack. if they're all closed, we'll miss them. and we definitely want to capture this work.

@RichWellum
Copy link

I got a bit derailed by the k8's to 1.6 and then the AIO was broken the end of last week. I'll have a few cycles early this week. I'm also fine picking it up post-move to OS, or anything else.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants