Hi all, sorry for late answer, but I am doing just the porting stuff and the reasons and practical use of freeipmi is not of my concern (I have only a limited knowledge of ipmi) - so it takes some time while I get input from all parties involved.
The simple answer is we have not find any problems so far. There arose a discussion within parties involved in freeipmi porting (I got various input for my managers and the people from group that is the target user of freeipmi) and here are our findings: 1. our testing did not show any problems (so far) running freeipmi services and ipmievd on one box 2. freeipmi services are not necessary for the group that is relying on freeipmi (the group that is going to deliver OpenSolaris HPC Distro), so we think a possible solution could be (to solve the problem of two ipmi consumer services running on the same box) NOT to deliver SMF services for freeipmi services. 3. Group delivering OpenSolaris HP Distro basically relies on both "ipmitool" and "freeipmi" functionality - actually, freeipmi is used only because of bmc-config tool (it extracts all the config from the bmc into a local file and pushes it back). They also don't use any of the freeipmi drivers, they use openipmi (ipmitool) drivers instead. 4. Arguments from my managing director - a) freeipmi was not put on the OpenSolaris package porting list by us. It was on the Cabinet's master porting list and we just have picked it as being one we might be able to do at first. b) freeipmi received emphasis by its usage within Tortuga (OpenSolaris HPC distro) which we are porting on behalf of a very strategy project for Sun. Since we knew the freeipmi port was coming, we have entered into a dependency on it. There is no fall-back plan right now if freeipmi was rejected. Regards, Michal Garrett D'Amore wrote: > Seth Goldberg wrote: >> Hi, >> >> It would be good if only one were running (if they each have the >> same functionality). The bandwidth across the bmc interface is >> rather low, so the fewer duplicate consumers, the better. > > Good to know. This supports my belief that we really should be > standardizing (for our own architecture) on just one of these tools. > If customers want to deploy freeipmi for reasons of their own, fine -- > but if at all possible we should be developing our *architecture* > around the tool we already have, unless there are compelling reasons > against this. So far I've not heard any such compelling reasons. > > -- Garrett > >> >> --S >> >> Quoting Dale Ghent, who wrote the following on Mon, 27 Apr 2009: >> >>> >>> Sorry for the late reply to this thread, but one concern/test case >>> I'd like to raise is if there would be any collision between >>> openipmi's ipmievd daemon (svc:/network/ipmievd:default) and the >>> freeimpi daemons running at the same time. >>> >>> /dale >>> >>> On Apr 24, 2009, at 3:31 PM, Garrett D'Amore wrote: >>> >>>> Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote: >>>>> Gareth, >>>>> >>>>> thx for your answer. >>>>> >>>>> Michal >>>>> >>>>> On 04/24/09 20:50, Garrett D'Amore wrote: >>>>>> I'm OK with the answer. >>>>>> >>>>>> I'd request/recommend that as a matter of good architecture, we >>>>>> (Sun) change our code so that *either* ipmitool *or* freeipmi is >>>>>> sufficient. >>>> >>>> Rereading the above sentence, I realize it can be misinterpreted. >>>> I think we need to pick one of these tools and standardize on it. >>>> I did not mean to imply that any tools should be modified to >>>> support both ipmitool and freeipmi. Sun need to choose one of the >>>> tools and use it for our base line. >>>> >>>> Hopefully the above statement is clearer. >>>> >>>> -- Garrett >>>>>> >>>>>> I think that probably means (since we don't have any other >>>>>> consumers for freeipmi) architectural advice to try to change the >>>>>> HPC software that you're planning on using freeipmi tools to be >>>>>> able to use ipmitool. Possibly that will require an RFE to >>>>>> upgrade ipmitool. >>>>>> >>>>>> Put another way, I perceive that it is fine to deliver freeipmi >>>>>> if it is useful for end-users or other free software. But I >>>>>> believe we (Sun/OpenSolaris) should standardize on just one of >>>>>> the two tools as a building block for our own internal software. >>>>>> >>>>>> -- Garrett >>>>>> >>>>>> Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote: >>>>>>> Garret, >>>>>>> >>>>>>> I asked couple of Sun guys that are using ipmitool whether they >>>>>>> see some possible interactions: >>>>>>> >>>>>>> Kevin Song: ".. the two are independent ipmi client software." >>>>>>> Hesam Kohanteb: "..These are 2 different clients of IPMI Stack. " >>>>>>> Mehrdad Mojgani: "..what do they mean by two applications >>>>>>> dependency other than using the same common driver path and >>>>>>> destination. >>>>>>> Wouldn't there is always a chance that applications can change >>>>>>> what the other one has set if they don't get exclusive access? " >>>>>>> >>>>>>> Well, is the answer "ipmitool and freeipmi are two independent >>>>>>> tools" satisfying? If not, I will use Mehrdad's words: "what >>>>>>> exactly do you mean by application dependency"? >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Michal >>>>>>> >>>>>>> On 04/24/09 18:14, Garrett D'Amore wrote: >>>>>>>> Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Can freeimpi and ipmitool coexist on the same platform? What >>>>>>>>>> int4tr >>>>>>>>> sorry, I do not not know what is "int4tr" - can you explain >>>>>>>>> (or provide me some link to docs, where I can study it - uncle >>>>>>>>> google was not helpful, sorry)? anyway, freeipmi and ipmitool >>>>>>>>> can happily coexist on the same platform. you can think of >>>>>>>>> them like "vncviewer" and "tvncviewier" (both are VNC clients >>>>>>>>> and both can coexist on the same platform) >>>>>>>> >>>>>>>> I meant to say "What interactions are there?" -- but it looks >>>>>>>> like the cat walked on my keyboard or something. Sorry about >>>>>>>> that. >>>>>>>> >>>>>>>> -- Garrett >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> opensolaris-arc mailing list >>>> opensolaris-arc at opensolaris.org >>> >>> >> >
