On Wed, Nov 18, 2020 at 10:04 AM David Ahern <dsah...@gmail.com> wrote: > > On 11/18/20 10:39 AM, Mahesh Bandewar (महेश बंडेवार) wrote: > > On Wed, Nov 18, 2020 at 8:58 AM Nicolas Dichtel > > <nicolas.dich...@6wind.com> wrote: > >> > >> Le 18/11/2020 à 02:12, David Ahern a écrit : > >> [snip] > >>> If there is no harm in just creating lo in the up state, why not just do > >>> it vs relying on a sysctl? It only affects 'local' networking so no real > >>> impact to containers that do not do networking (ie., packets can't > >>> escape). Linux has a lot of sysctl options; is this one really needed? > >>> > > I started with that approach but then I was informed about these > > containers that disable networking all together including loopback. > > Also bringing up by default would break backward compatibility hence > > resorted to sysctl. > >> +1 > >> > >> And thus, it will benefit to everybody. > > > > Well, it benefits everyone who uses networking (most of us) inside > > netns but would create problems for workloads that create netns to > > disable networking. One can always disable it after creating the netns > > but that would mean change in the workflow and it could be viewed as > > regression. > > > > Then perhaps the relevant sysctl -- or maybe netns attribute -- is > whether to create a loopback device at all.
I'm open to ideas within the bounds of maintaining backward compatibility. However, not able to see how we can pull it off without creating a 'loopback' device.
