Re: support of aoe devices and aoetools package
On Thursday 12 October 2006 17:50, David Martínez Moreno wrote:
> El miércoles, 11 de octubre de 2006 17:44, Warren Turkal escribió:
> > First of all, the implementation aoetools include to enable mounting the
> > aoe devices at boot time is severely lacking. This support was
> > implemented in response to bug #387552 [1], which is now closed. They
> > depend on a filesystem argument in fstab called _netdev, and they do not
> > work with lvm
>
> Argument that I extracted from S35mountall.sh and mount manpage...
>
> I do not really know much about LVM and its shortcomings or requisites,
> and how it deals with networked volumes, but I am sure it is not as easy as
> you draw it.
Consider that it is not only a networked volume. It is also a network block
device. You treat it something like an NFS mount in your implementation,
which it is not what it is.
BTW, my script is loosely based on an example on the coraid support website
(the only manufacturers of AOE devices that I am aware of) at [1].
> > (or any other dev mapper based system) at all as far as I can tell. I
> > contributed a new init script [2] that attempts to address these
> > shortcomings while removing the need for the special fstab option. I
> > submitted this info to bug #387552, but have received no response yet. I
> > was tempted to reopen the bug, but I didn't think that'd be proper. I
> > have also CCed the maintainer on all mailings to make sure that he got
> > it.
>
> As I replied in a former mail, your approach is simply broken.
I didn't have any replies mentioning my implementation from you until a few
hours ago. How was I supposed to know your reaction to it if you didn't even
respond until today?
> You
> decided to unconditionally initialize network before stage 40, in fact,
> even before stage 35 (mountall), and with the first lines of your script
> being:
>
> modprobe -r aoe
> modprobe aoe
>
> mount /usr
>
> sleep 1
This script implemented the version for when the aoe tools were located
in /usr. Also note that this script was a prototype. I was willing to put
more time once I got some feedback from you. Instead I got a package bomb
with an underfeatured implementation. If you don't like the unchecked
interface activation
Also note, enabling the ethernet device doesn't enable the TCP/IP unless you
assign an address. The reason for enabling the interfaces is to enable the
aoe as block devices that can be used for lvm physical volumes.
> You are *not* taking care of _anyone_ having a different setting from
> yours. As I told you before, this kind of scripts are nice for your
> homegrown machines, but not for general use.
Your script is not good for general use. You don't allow any more abstract
uses of the block devices. You only allow laying a filesystem directly on
them with no device manager stuff (lvm, evms, etc.) to manage it. My script
was the beginning of a prototype implementation. If you had replied to it
before now, maybe I would have known your objections in a reasonable time
frame instead of being surprised by an implementation that I felt was
lacking.
> > I am basically writing here to see what I can do to at least get someone
> > to look over the idea presented in the script to see if they think it
> > would be a good idea. It is also frustrating to not receive any response
> > when I clearly have a personal stake in this matter (that being that I
> > have to support aoe based hardware).
>
> I am sorry for not being much more responsive, really. Apart from that,
> given that your first try to compose a working 11-1 aoetools release was
> not very 'careful' (bashisms, missing variables, and so on), and your
> second try to solve another problem on this matter was simply to mess with
> the init stages in runlevel S, you might understand that I did not make a
> lot of effort to reply to you in time.
Thanks for finding the bashisms in the aoe-* scripts.
Maybe that lack of transparency led to this misunderstanding?
Your implementation is not any better. Releasing what you did without input of
actual users who have a stake in its use is somewhat disheartening.
> If you want, we can forward this issue to the Debian Technical Comitee,
> where they will study this issue and make an official *technical*
> (non-emotional) report. If they say so, I will accept to configure network
> interfaces before stage 40, but not before that.
I don't think we need to bureaucracy of the tech committee. I would rather
rationally present my functional requirements and see what kind of solution
we can come to. However, without any kind of response until today, I didn't
feel that was happening. Maybe now it can? Truce, please? I want to work with
Debian and you. I was just very disappointed with the implementation and the
response that I got when raising concerns about it. I didn't go immediately
here. I waited 9 days with no response before I posted my message to
debian-devel.
Stage 40 is too late to use other device manager tools.
Maybe an earlier init script that is disabled by default in addition to your
script would be a good compromise? That way one could choose to enable the
early network activation when they need it for aoe. Would that be possible?
[1]http://www.coraid.com/support/linux/EtherDrive-2.6-HOWTO-5.html#ss5.15
wt
--
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science
Reply to: