Michal Bachorik wrote:
> 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?
The case was derailed, but approved in a subsequent vote, with advice
that ipmitool is the Solaris architecture of record (hence freeimpi
should *not* be used for the HPC tools...)
-- Garrett
>
> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
