network implementation simplification for Kata
Hey cloudy-virt-buds – We have a long standing PR from Manohar Castelino in the runtime repo, [1], which removes the bridge networking model. In the bridge networking model, a bridge is created in the network namespace, and the veth is connected to the VM’s tap. This is the least performant and a bit more complex than necessary. We recommend end-users utilize tc-filter (default) or macvtap. Zhang Wei brought up the concern of whether end-users could be using bridge today. I hope they aren’t, but am now considering whether this should be a 2.0 candidate, and whether this should be considered a breaking change. Feedback? I’d like input from other AC members here so we can make forward progress on this PR, and/or on 2.0 planning. Thanks, Eric [1] - https://github.com/kata-containers/runtime/pull/1214
I am fine to remove the bridge and I don't think there are cases could only work with the bridge. My colleague Wei has some thoughts on the tc-filter as default, I am asking him to post his concern here. On Wed, Jun 12, 2019 at 3:57 AM Ernst, Eric <eric.ernst@intel.com> wrote:
Hey cloudy-virt-buds –
We have a long standing PR from Manohar Castelino in the runtime repo, [1], which removes the bridge networking model.
In the bridge networking model, a bridge is created in the network namespace, and the veth is connected to the VM’s tap. This is the least performant and a bit more complex than necessary. We recommend end-users utilize tc-filter (default) or macvtap.
Zhang Wei brought up the concern of whether end-users could be using bridge today. I hope they aren’t, but am now considering whether this should be a 2.0 candidate, and whether this should be considered a breaking change.
Feedback? I’d like input from other AC members here so we can make forward progress on this PR, and/or on 2.0 planning.
Thanks,
Eric
[1] - https://github.com/kata-containers/runtime/pull/1214
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- Xu Wang Senior Staff Engineer at AntFin A member of Kata Containers project github/twitter/wechat: @gnawux
Xu Wang <xu@hyper.sh> 于2019年6月12日周三 上午11:00写道:
I am fine to remove the bridge and I don't think there are cases could only work with the bridge.
My colleague Wei has some thoughts on the tc-filter as default, I am asking him to post his concern here.
hmm... I'm thinking that bridge is more generally available than tcfilter for the default networking model[1], but as we have change that default to tcfilter, I'm fine with removing the bridge. [1]: https://github.com/kata-containers/runtime/issues/1742
On Wed, Jun 12, 2019 at 3:57 AM Ernst, Eric <eric.ernst@intel.com> wrote:
Hey cloudy-virt-buds –
We have a long standing PR from Manohar Castelino in the runtime repo, [1], which removes the bridge networking model.
In the bridge networking model, a bridge is created in the network namespace, and the veth is connected to the VM’s tap. This is the least performant and a bit more complex than necessary. We recommend end-users utilize tc-filter (default) or macvtap.
Zhang Wei brought up the concern of whether end-users could be using bridge today. I hope they aren’t, but am now considering whether this should be a 2.0 candidate, and whether this should be considered a breaking change.
Feedback? I’d like input from other AC members here so we can make forward progress on this PR, and/or on 2.0 planning.
Thanks,
Eric
[1] - https://github.com/kata-containers/runtime/pull/1214
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- Xu Wang Senior Staff Engineer at AntFin A member of Kata Containers project github/twitter/wechat: @gnawux
Hi Eric, On Tue, Jun 11, 2019 at 07:57:14PM +0000, Ernst, Eric wrote:
Hey cloudy-virt-buds –
We have a long standing PR from Manohar Castelino in the runtime repo, [1], which removes the bridge networking model.
In the bridge networking model, a bridge is created in the network namespace, and the veth is connected to the VM’s tap. This is the least performant and a bit more complex than necessary. We recommend end-users utilize tc-filter (default) or macvtap.
Zhang Wei brought up the concern of whether end-users could be using bridge today. I hope they aren’t, but am now considering whether this should be a 2.0 candidate, and whether this should be considered a breaking change.
I don't consider this being a breaking change, but we need to define a deprecation period for this kind of features. For example we declare it a deprecated feature now, which means we'd officially (to be documented) support it for 2 more release cycles. Obviously this is something that could apply to any other feature we'd like to deprecate. Cheers, Samuel.
Agree. I vote for 2 releases for deprecated features before it is removed On Wed, Jun 12, 2019 at 3:07 PM Samuel Ortiz <sameo@linux.intel.com> wrote:
Hi Eric,
Hey cloudy-virt-buds –
We have a long standing PR from Manohar Castelino in the runtime repo, [1], which removes the bridge networking model.
In the bridge networking model, a bridge is created in the network namespace, and the veth is connected to the VM’s tap. This is the least
On Tue, Jun 11, 2019 at 07:57:14PM +0000, Ernst, Eric wrote: performant and a bit more complex than necessary. We recommend end-users utilize tc-filter (default) or macvtap.
Zhang Wei brought up the concern of whether end-users could be using
bridge today. I hope they aren’t, but am now considering whether this should be a 2.0 candidate, and whether this should be considered a breaking change.
I don't consider this being a breaking change, but we need to define a deprecation period for this kind of features. For example we declare it a deprecated feature now, which means we'd officially (to be documented) support it for 2 more release cycles. Obviously this is something that could apply to any other feature we'd like to deprecate.
Cheers, Samuel.
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
-- Xu Wang Senior Staff Engineer at AntFin A member of Kata Containers project github/twitter/wechat: @gnawux
participants (5)
-
Ernst, Eric
-
Samuel Ortiz
-
Wei Li
-
weizhang555.zw
-
Xu Wang