On Mon, Dec 10, 2012 at 08:22:49AM -0500, Alon Bar-Lev wrote:
> ----- Original Message -----
> > From: "Dan Kenigsberg" <dan...@redhat.com>
> > To: "Alon Bar-Lev" <alo...@redhat.com>
> > Cc: "Antoni Segura Puimedon" <asegu...@redhat.com>,
> > firstname.lastname@example.org
> > Sent: Monday, December 10, 2012 3:16:21 PM
> > Subject: Re: [vdsm] Fwd: Bonding, bridges and ifcfg
> > On Mon, Dec 10, 2012 at 08:07:38AM -0500, Alon Bar-Lev wrote:
> > > Hi,
> > >
> > > Just to make sure... working in non-persistent mode will eliminate
> > > these kind of issues, right?
> > No. It would eliminate the need to debug initscripts. But it would
> > require
> > vdsm developer of an intimate recognition of kernel quirks.
> > We'd have fewer building blocks, and less of chance for
> > incompatibility.
> > But we would need to reimplement (some of) the logic within ifup
> > script.
> Sure you need to reimplement ifup and ifdown functionality as you would not
> use these...
> You will not have fewer building blocks if you will break the fedora/redhat
> border, actually if you go non persistent you will have fewer of these and be
> more portable as you have one kernel (linux) to support.
> vdsm developer [should] already require intimate recognition of the kernel,
> see bellow one example. It is just that even if one has intimate recognition
> of the kernel, working via primitive tools like rhel/fedora network-script
> only make it harder to produce the desired outcome, while having full control
> over the process and the result.
No doubt there are plenty of benefits of having less moving parts. But
you seem to ignore the human price of dealing with ioctls directly and
reinventing the nth management wrappers thereof.
Regarding the problem at hand: I did not grasp it yet, but I bet that it
is either a bug in the sequence that we use ifup/ifdown, or a bug in
ifup itself. I'd like to understand how the bug is tickled, and how it
can be fixed.
vdsm-devel mailing list