Open Stack

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 at linux.intel.com> wrote:

> 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.
>
>
> _______________________________________________
> kata-dev mailing list
> kata-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20190612/c74bcfa7/attachment.html>