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
tomorr
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 yest
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 probl
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
Hi all,
just to let you know - I am (with colleague) in process to test freeipmi
services with ipmitool services (ipmievd). I should have results next week.
Regards,
Michal
On 04/28/09 02:16, Dale Ghent wrote:
> On Apr 27, 2009, at 7:30 PM, Garrett D'Amore wrote:
>
>> Seth Goldberg wrote:
>>>
On Apr 27, 2009, at 7:30 PM, 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
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 wro
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
standar
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.
--S
Quoting Dale Ghent, who wrote the following on Mon, 27 Apr 2009:
>
> Sorry for the late reply
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.
>
> I think that probably means (since we do
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 depen
>>>
>>> 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 t
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 confi
Hi all,
again - sorry for delay but i am kinda busy :(. See answers below:
> Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote:
>>
>>>
Regarding the "ipmitool" - I was in contact with guys working
on/with "ipmitool" (Kevin.Song at Sun.COM, Hesam.Kohanteb at Sun.COM,
>>
Hi all,
sorry for delay. See answers below.
Also is there any impact to having these freeimpi daemons running
given Solaris already has FMA ?
>>> FMA is about a local machine auto-recovery while freeipmi is able to
>>> watch IPMI events from remote machines and perform fo
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* i
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.
I think that probably means (since we don't have any other consumers for
freeipmi) architectural advice to try to change the HPC s
Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote:
>
> 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 a
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
Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote:
> Hi all,
>
> sorry for delay. See answers below.
> Also is there any impact to having these freeimpi daemons running
> given Solaris already has FMA ?
>
FMA is about a local machine auto-recovery while fre
Hi all,
Please find answers to questions below:
On 04/20/09 16:12, Darren J Moffat wrote:
>>> It is also not self review in my opinion since I don't see how
>>> interaction with the existing ipmitool is covered. Nor do I see any
>>> way that the two daemons are started - I'd expect SMF service
Hi Daren,
On 04/20/09 11:40, Darren J Moffat wrote:
> This is clearly a platform level tool and as such is probably more
> appropriate for review in PSARC.
This is covered by my ARC sponsors (explained in separate email).
>
> It is also not self review in my opinion since I don't see how
> inter
Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote:
> Hi Daren,
>
> On 04/20/09 11:40, Darren J Moffat wrote:
>> This is clearly a platform level tool and as such is probably more
>> appropriate for review in PSARC.
> This is covered by my ARC sponsors (explained in separate email).
On Mon, Apr 20, 2009 at 12:42:43PM -0700, Garrett D'Amore wrote:
> Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote:
> >>
> >>Also is there any impact to having these freeimpi daemons running
> >>given Solaris already has FMA ?
> >FMA is about a local machine auto-recovery while fr
Michael Kearney wrote:
> I've updated the IAM file to reflect fast track rather than self
> review. Sorry, my bad.
Please also change it to a PSARC rather than LSARC case, I believe the
expertise in this area lies in PSARC and previous cases for IPMI have
been reviewed there.
>Best R
Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote:
>
>>
>>> Regarding the "ipmitool" - I was in contact with guys working
>>> on/with "ipmitool" (Kevin.Song at Sun.COM, Hesam.Kohanteb at Sun.COM,
>>> turgo-ipmi at Sun.COM ..) to clarify some technical details regarding
>>> the B
This is clearly a platform level tool and as such is probably more
appropriate for review in PSARC.
It is also not self review in my opinion since I don't see how
interaction with the existing ipmitool is covered. Nor do I see any way
that the two daemons are started - I'd expect SMF services.
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
FreeIPMI
1.2. Name of Document Author/Supplier:
Author: Michal Bachorik
1.3 Date of This Document:
1
28 matches
Mail list logo
