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
>>>>
>>>>
>>>
>>
>
