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