On 04/04/2012 01:12 PM, Jason Gunthorpe wrote: > On Tue, Apr 03, 2012 at 07:14:42PM -0700, Ira Weiny wrote: >> On Mon, 2 Apr 2012 12:45:45 -0600 >> Jason Gunthorpe <[email protected]> wrote: >> >>> On Mon, Apr 02, 2012 at 03:27:35PM +0000, Heinz, Michael William wrote: >>> >>>> Any ideas on how we could solve the hostname problem while we're >>>> changing the description? >>> >>> The node description needs to be set from the DCHP notifier script >>> chain (eg /etc/network/if-up.d/ on Debian) and also from a udev rule >>> triggered on device insertion. >> >> Jason, I'm confused. Do you mean DHCP? > > Yes.. > >> It seems are you indicating you would like to see if[up/down] bring >> ports up/down like they do for IP? > > No.. > >> On my ubuntu box (the closest thing I have to Debian) it looks like >> ifupdown owns /etc/network/if-up.d and that is not specific to DHCP. >> I don't think DHCP should be required for IB. > > if-up.d/ is a '.d' directory, the idea is individual packages drop > their script files in the directory and the system runs them at > defined times. No package owns the directory. > > The purpose of placing a hook here is this call path is used when the > hostname changes via DHCP so you can have a chance to reset the node > description. > >> Using udev to set this __seems__ like a better idea although I have >> not prototyped it. > > The purpose of the udev hook path is to set the node description on > initial device insertion, which may be before, or after the DHCP > process completes, in such cases.
Well, a udev rule is guaranteed to be before dhcp completes *on that device*. It might be that dhcp has completed on another device and that the other device is actually where the hostname is pulled, but the udev rule will always be before this given device in the rule has completed dhcp. > It may also be before or after the openibd script.. Non hot-plug events are going to end up always being before the openibd script. This is merely a side effect of the fact that udev start is called before the normal init script processing is started (this all changes somewhat in the systemd world though). > Having init.d > scripts depend on the ordering of hardware discovery and module > loading is considered sketchy these days with all the parallel boot > fancyness and what not. I would agree with that. However... > IMHO we should have a udev rule that also loads the higher level IB > modules when any RDMA capable device is discovered, including the mlx4 > IB layer, uverbs, umad, etc. This way systems that have RDMA will load > the right modules and systems that don't, won't. Fully supporting hot > plug, of course. One of the niceties of the rdma/openibd init script is the ability to completely reload the stack. That goes away if we switch to a udev load of the stack (well, unless you now create a script in /sbin and have the udev rule call that script, but the script should no longer be in the initrddir if it's not an init script). > This would broadly eliminate the openibd script, integrate more > correctly with the modern distro world, be better prepared for systemd > and just be an overall better example for distros to follow :) This is mostly true, but you do have to sacrifice the one item I listed above. >>> It should probably not be set from the openibd script.. >> >> I agree there might be better ways but I am not sure I follow your >> proposal. Furthermore, I don't know that a start up script of some >> sort is all that evil. >> >> Finally, I think Michael brings up a good point about which package >> should own any such scripts. > > udev is like if-up.d/, there is a rules directory packages can drop > hook scripts into that run at the appropriate time. Correct. On Red Hat Enterprise Linux I could have the rdma package drop in an /sbin/rdma script that would bring the stack up (and possibly reload it, but I'm a bit sketchy on that idea given that this would no longer be an init script but something else), have it drop a small script in /etc/dhcp/dhclient.d/ to set the node description after dhcp completes (the script in /sbin would also have to set the node description from whatever information is available on load just in case the machine doesn't even use dhcp though), have it drop a rules file in /etc/udev.d/rules.d for bringing up the stack on device discovery (this one is a bit tricky though, you basically have to match against all possible RDMA devices and bring up the stack on the presence of any one of them, and your script that you call to bring the stack up needs to be safe against parallel invocations), and then also own the /etc/rdma directory and the whatever config files it places in there itself. So, I'd say it's doable to change this over, but I'm not sure I would recommend it in a minor point release. I'd probably save this sort of change for a major release update. -- Doug Ledford <[email protected]> GPG KeyID: 0E572FDD http://people.redhat.com/dledford
signature.asc
Description: OpenPGP digital signature
