FreeIPMI [LSARC/2009/245 Self Review]

Wed May 6 10:07:47 PDT 2009

Guys,

I just found out (while waiting on the phone till conference will 
begin), that ARC meeting for Open businesses was yesterday and not today 
- hard to find excuses .. I am slightly overworked, so I thought that 
today is 5th and not 6th (and I got email yesterday, that ARC meeting is 
tomorrow so I was perfectly sure that I am not gonna miss it) ..

Does my mind-absence doomed freeipmi or can I still save it somehow?

Sorry once again,

Michal

Garrett D'Amore wrote:
> Thank you for this clarification.
>
> So I perceive two things here.
>
> * freeipmi as a "familiarity" case.  I'm happy to see it integrated as 
> such, if there is any real desire for this from the community.
>
> * Use by Tortuga/HPC.  I believe that their use here is 
> architecturally unsound, since it seems to me that they are using 
> *both* ipmitool and freeipmi components as part of their toolset.  I'd 
> far rather that this project just rely on ipmitool, without any 
> freeipmi dependency whatsoever.
>
> Therefore, I'm inclined to derail this project, and vote to approve it 
> *with* a TCR to reduce the stability to of its interfaces to 
> Uncommitted or Volatile, as well as a TCR to point users (and most 
> especially developers) towards ipmitool.
>
> I've not decided for sure on this yet, but we'll talk about it at 
> tomorrow's meeting.
>
>    - Garrett
>
> Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote:
>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>
>