Hi Garret, all, some answers below: >>> >>> Most importantly: is there any negative impact on FMA? >>> >> I do not understand the question - if you configure the freeipmi in a >> way, that it watches remote machine and performs shutdown when CPU >> temperature reaches 60oC while FMA is configured in a way (I do not >> know if it is possible, just guessing) that it has to switch off the >> machine when CPU temperature reaches 60oC and freeipmi is faster then >> FMA (so it reboots the machine sooner, then FMA is able to perform >> shutdown), then YES, it can have negative impact. >> >> But in such sense, anything can have negative impact on FMA - for me, >> it is the administrator's responsibility to configure the machine in >> a way that it works reliable. It is important, that by default (after >> installation) freeimpi does NOTHING. it has to be configured to DO >> something. > > OK. But in the situation you describe, FMA's fault handling might > allow for a different handling -- e.g. turning fans up to full speed, > or throttling back a CPU or even disabling one or more cores (or the > whole CPU if multiple CPUs are present) -- which is better IMO than a > blind shut down.
Shutting down a machine was just an example - I think IPMI could be capable of doing similar things (increase FAN speed, disabling core - i am not 100% sure if in current version, but IPMI is evolving as it is pretty much standard for platform operations management in HW) or even just for sending a SNMP alert or to send the email. I believe that FMA is important feature and useful, but there is one differentiator - ipmi can be used for watching the machine remotely and perform the platform operation without having access to operating system. this is important for HPCin situations, where large cluster (zounds of nodes) are needed to be restarted, or just shutdown without touching the OS (for example, OS re-provisioning is going to be performed and we do not wait until current OS would go down). > >>> But also, FMA and SMF both seem to allow for the possibility of a >>> networked future in that FMRIs are practically URIs. So maybe it's >>> time >>> to fund a project to make that happen? (That could be advice by the >>> ARC >>> to the PAC.) >>> >> >> I do not understand this - does it touch freeipmi ARC somehow? > > The comments don't apply directly to you, except that perhaps we need > to figure out in the future how to enable FMA to interact with IPMI or > other service processor architectures. The advice would be something > ARC would supply -- and not require any action on your part (at this > time). > > On another front, I still don't think I've seen an answer to my > questions about FreeIPMI & ipmitool interactions. > > Can they coexist? What are the interactions, if any? What is the > justification for having a different tool than ipmitool? (You > indicated that you'd done some analysis and chosen FreeIPMI, but no > explanation was given about *why* this choice was made.) Is this just > about Linux familiarity? > > Also, I'll repeat this question (although its really a C-Team issue > and not an ARC one): IPMI specs seem to require signing an "Adopters > agreement for IPMI" from Intel. Has anyone checked to see if freeipmi > has followed the necessary steps so our legal bases are covered for > integrating it? I just answered all 3 above questions in separate email, sorry for scattering the info. Regards, Michal > > - Garrett > >> >> Regards, >> >> Michal >>> Nico >>> >> >
