From mk200726@sac.sfbay.sun.com Fri Apr 17 13:49:57 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HKnuBI014099 for ; Fri, 17 Apr 2009 13:49:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3HKnnnl008693; Sat, 18 Apr 2009 04:49:55 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900D0TJ75BE00@nwk-avmta-2.sfbay.sun.com>; Fri, 17 Apr 2009 13:49:53 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI900CWIJ74EW00@nwk-avmta-2.sfbay.sun.com>; Fri, 17 Apr 2009 13:49:52 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HKnqC5060028; Fri, 17 Apr 2009 13:49:52 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HKnpDl014094; Fri, 17 Apr 2009 13:49:51 -0700 (PDT) Received: (from mk200726@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n3HKnpSC014090; Fri, 17 Apr 2009 13:49:51 -0700 (PDT) Date: Fri, 17 Apr 2009 13:49:51 -0700 (PDT) From: Michael Kearney Subject: FreeIPMI [LSARC/2009/245 Self Review] To: LSARC-ext@sun.com Message-id: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 11245 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: 17 April, 2009 4. Technical Description Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1.0 Project Information 1.1 Name of project/component FreeIPMI 0.7.7 1.2 Author of document Michal Bachorik 1.3. Date of This Document: 17 April 2009 2.0 Project Summary 2.1 Project Description FreeIPMI provides in-band and out-of-band IPMI software based on the IPMI v1.5/2.0 specification. The project goal is to port the functionality offered by FreeIPMI to OpenSolaris. 4. Technical Description: The IPMI specification defines a set of interfaces for platform management. It is utilized by a wide variety of vendors for system management on motherboards. The features of IPMI that most users will be interested in are sensor monitoring, remote power control, serial-over-LAN (SOL), and system debugging. The FreeIPMI tools and libraries should provide users with the ability to access and utilize these features. 5. Interfaces FreeIPMI provides in-band and out-of-band IPMI software based on the IPMI v1.5/2.0 specification. As such, it includes various tools to configure BMC and IPMI information, list information about BMC, manage/monitor a chassis, read FRU information, read/manage system event log records among other things. The project further includes the necessary libraries and header files for developing custom IPMI tools. Project introduces 2 daemons: - BMC watchdog, daemon that watches bmc events and offers an automatic action to be performed when certain event occurs - IPMIdetecd, daemon that is able to detect new impi nodes. Daemons are not started during installation and are not starter automatically (unless explicitly configured to do so). There will be a SMF manifest for each daemon taking care of daemon lifecycle. Exported Interfaces Interface Name Classification Comments --------------------------- ------------------- --------------------------- SUNWfreeipmr Uncommitted name of package var/log/ipmiconsole Uncommitted new directory created for SUNWfreeipmr package var/log/freeipmi Uncommitted new directory created for SUNWfreeipmr package var/lib/freeipmi Uncommitted new directory created for SUNWfreeipmr package var/cache/ipmimonitoringsdrcache Uncommitted new directory created for SUNWfreeipmr package etc/logrotate.d Committed new directory created for SUNWfreeipmr package, if does not exist SUNWfreeipmiu Uncommitted name of package usr/lib Committed new directory created for SUNWfreeipmu package, if does not exist usr/include Committed new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/spec Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/sdr-cache Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/locate Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/cmds Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/interface Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/fiid Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/api Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/util Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/record-format Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/debug Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/driver Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/share/man/man3 Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/man/man4 Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/man/man5 Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/man/man1m Committed new directory created for SUNWfreeipmu package, if does not exist usr/share Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/doc Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/doc/freeipmi Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/share/doc/freeipmi/info Uncommitted new directory created for SUNWfreeipmu package, if does not exist libipmidetect Uncommitted usr/lib/libipmidetect.so.0.0.0, A library for IPMI node detection. libipmiconsole Uncommitted usr/lib/libipmiconsole.so.2.0.3, A library for Serial-over-Lan (SOL) console access. SOL console access is abstracted into a file descriptor interface, so users may read and write console data through a file descriptor. libfreeipmi Uncommitted usr/lib/libfreeipmi.so.6.1.2, A C library that includes KCS, SSIF, and OpenIPMI drivers, IPMI 1.5 and IPMI 2.0 LAN communication interfaces, IPMI packet building utilities, IPMI command utilities, and utilities for reading/interpreting/managing IPMI. libipmimonitoring Uncommitted usr/lib/libipmimonitoring.so.1.1.2, A library for sensor monitoring and interpretation. Sensor monitoring and interpretation of those sensors is abstracted into an API with an iterator interface. bmc-info Uncommitted a tool to read information about a BMC such as device version numbers, device support, and global IDs (guids). bmc-config Uncommitted a tool to configure general BMC and IPMI information. Supports configuration of usernames, passwords, networking information, security, Serial-over-LAN (SOL), and other core fields. bmc-watchdog Uncommitted a tool/daemon to manage a BMC Watchdog. This tool is typically used for system timeout management and automatic system restarts in the event of a system crash. ipmi-chassis Uncommitted a tool to manage/monitor a chassis, such as chassis power, identification, and status. ipmi-fru Uncommitted a tool to read field replaceable unit (FRU) information from a motherboard/machine. ipmi-sel Uncommitted a tool to read and manage IPMI System Event Log (SEL) records. SEL records store system event information and may be useful for debugging problems. ipmi-sensors Uncommitted a tool to read IPMI sensor readings and sensor data repository (SDR) information. ipmipower Uncommitted a tool for remote power control. ipmiconsole Uncommitted a tool for Serial-over-Lan (SOL) console access. ipmimonitoring Uncommitted a tool for sensor monitoring and interpretation. The tool is similar to ipmi-sensors, but sensor readings are analyzed and mapped into Nominal, Warning, and Critical states. ipmi-raw Uncommitted a tool that provides hex input/output of IPMI commands. ipmi-locate Uncommitted a tool that can probe for information about the location of a BMC device, such as device addresses. pef-config Uncommitted a tool to configure Platform Event Filtering (PEF) information. ipmi-chassis-config Uncommitted a tool to configure IPMI chassis information. Supports configuration of boot device, power restore policy, and other chassis related fields. ipmi-sensors-config Uncommitted a tool to configure IPMI sensors. Supports configuration of sensor thresholds, sensor events, and other sensor related fields. bmc-device Uncommitted a tool to perform advanced BMC commands. ipmiping Uncommitted an IPMI ping tool for debugging. rmcpping Uncommitted a RMCP ping tool for debugging. ipmi-oem Uncommitted an IPMI tool for OEM specific commands. ipmidetect / ipmidetectd Uncommitted a tool and daemon for IPMI node detection Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- bmc_intf.h Contracted Private located in /onnv/onnv-gate/usr/src/uts/common/sys/bmc_intf.h - how to ask for contract? libgcrypt Committed located in /usr/lib/libgcrypt.so.11 6. Resources and Schedule: 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.5. ARC review type: Automatic 6.6. ARC Exposure: open 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From Michael.Kearney@sun.com Fri Apr 17 14:31:45 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3HLViEf014845 for ; Fri, 17 Apr 2009 14:31:45 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3HLVXvS029385 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 17 Apr 2009 22:31:44 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KI900701L4VA800@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 17 Apr 2009 14:31:43 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KI9009CSL4V24E0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 17 Apr 2009 14:31:43 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3HLVgT6024395 for ; Fri, 17 Apr 2009 21:31:42 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KI900I00KQJTH00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 17 Apr 2009 15:31:42 -0600 (MDT) Received: from [129.150.197.30] ([unknown] [129.150.197.30]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KI900C1NL4C0B50@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 17 Apr 2009 15:31:26 -0600 (MDT) Date: Fri, 17 Apr 2009 15:31:26 -0600 From: Michael Kearney Subject: FreeIPMI Ver 0.7.7 [LSARC/2009/245 FastTrack timeout 04/24/2009] Sender: Michael.Kearney@sun.com To: LSARC-ext@sun.com Cc: Michael Kearney Message-id: <49E8F52E.9080606@Sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_fYXto2u+4/n0lieiVW2OQA)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 11637 This is a multi-part message in MIME format. --Boundary_(ID_fYXto2u+4/n0lieiVW2OQA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I am sponsoring this familiarity case for Michal Bachorik, requesting minor binding and timing out 04/24/2009. -Michael Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1.0 Project Information 1.1 Name of project/component FreeIPMI 0.7.7 1.2 Author of document Michal Bachorik 1.3. Date of This Document: 17 April 2009 2.0 Project Summary 2.1 Project Description FreeIPMI provides in-band and out-of-band IPMI software based on the IPMI v1.5/2.0 specification. The project goal is to port the functionality offered by FreeIPMI to OpenSolaris. 4. Technical Description: The IPMI specification defines a set of interfaces for platform management. It is utilized by a wide variety of vendors for system management on motherboards. The features of IPMI that most users will be interested in are sensor monitoring, remote power control, serial-over-LAN (SOL), and system debugging. The FreeIPMI tools and libraries should provide users with the ability to access and utilize these features. 5. Interfaces FreeIPMI provides in-band and out-of-band IPMI software based on the IPMI v1.5/2.0 specification. As such, it includes various tools to configure BMC and IPMI information, list information about BMC, manage/monitor a chassis, read FRU information, read/manage system event log records among other things. The project further includes the necessary libraries and header files for developing custom IPMI tools. Project introduces 2 daemons: - BMC watchdog, daemon that watches bmc events and offers an automatic action to be performed when certain event occurs - IPMIdetecd, daemon that is able to detect new impi nodes. Daemons are not started during installation and are not starter automatically (unless explicitly configured to do so). There will be a SMF manifest for each daemon taking care of daemon lifecycle. Exported Interfaces Interface Name Classification Comments --------------------------- ------------------- --------------------------- SUNWfreeipmr Uncommitted name of package var/log/ipmiconsole Uncommitted new directory created for SUNWfreeipmr package var/log/freeipmi Uncommitted new directory created for SUNWfreeipmr package var/lib/freeipmi Uncommitted new directory created for SUNWfreeipmr package var/cache/ipmimonitoringsdrcache Uncommitted new directory created for SUNWfreeipmr package etc/logrotate.d Committed new directory created for SUNWfreeipmr package, if does not exist SUNWfreeipmiu Uncommitted name of package usr/lib Committed new directory created for SUNWfreeipmu package, if does not exist usr/include Committed new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/spec Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/sdr-cache Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/locate Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/cmds Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/interface Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/fiid Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/api Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/util Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/record-format Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/debug Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/include/freeipmi/driver Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/share/man/man3 Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/man/man4 Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/man/man5 Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/man/man1m Committed new directory created for SUNWfreeipmu package, if does not exist usr/share Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/doc Committed new directory created for SUNWfreeipmu package, if does not exist usr/share/doc/freeipmi Uncommitted new directory created for SUNWfreeipmu package, if does not exist usr/share/doc/freeipmi/info Uncommitted new directory created for SUNWfreeipmu package, if does not exist libipmidetect Uncommitted usr/lib/libipmidetect.so.0.0.0, A library for IPMI node detection. libipmiconsole Uncommitted usr/lib/libipmiconsole.so.2.0.3, A library for Serial-over-Lan (SOL) console access. SOL console access is abstracted into a file descriptor interface, so users may read and write console data through a file descriptor. libfreeipmi Uncommitted usr/lib/libfreeipmi.so.6.1.2, A C library that includes KCS, SSIF, and OpenIPMI drivers, IPMI 1.5 and IPMI 2.0 LAN communication interfaces, IPMI packet building utilities, IPMI command utilities, and utilities for reading/interpreting/managing IPMI. libipmimonitoring Uncommitted usr/lib/libipmimonitoring.so.1.1.2, A library for sensor monitoring and interpretation. Sensor monitoring and interpretation of those sensors is abstracted into an API with an iterator interface. bmc-info Uncommitted a tool to read information about a BMC such as device version numbers, device support, and global IDs (guids). bmc-config Uncommitted a tool to configure general BMC and IPMI information. Supports configuration of usernames, passwords, networking information, security, Serial-over-LAN (SOL), and other core fields. bmc-watchdog Uncommitted a tool/daemon to manage a BMC Watchdog. This tool is typically used for system timeout management and automatic system restarts in the event of a system crash. ipmi-chassis Uncommitted a tool to manage/monitor a chassis, such as chassis power, identification, and status. ipmi-fru Uncommitted a tool to read field replaceable unit (FRU) information from a motherboard/machine. ipmi-sel Uncommitted a tool to read and manage IPMI System Event Log (SEL) records. SEL records store system event information and may be useful for debugging problems. ipmi-sensors Uncommitted a tool to read IPMI sensor readings and sensor data repository (SDR) information. ipmipower Uncommitted a tool for remote power control. ipmiconsole Uncommitted a tool for Serial-over-Lan (SOL) console access. ipmimonitoring Uncommitted a tool for sensor monitoring and interpretation. The tool is similar to ipmi-sensors, but sensor readings are analyzed and mapped into Nominal, Warning, and Critical states. ipmi-raw Uncommitted a tool that provides hex input/output of IPMI commands. ipmi-locate Uncommitted a tool that can probe for information about the location of a BMC device, such as device addresses. pef-config Uncommitted a tool to configure Platform Event Filtering (PEF) information. ipmi-chassis-config Uncommitted a tool to configure IPMI chassis information. Supports configuration of boot device, power restore policy, and other chassis related fields. ipmi-sensors-config Uncommitted a tool to configure IPMI sensors. Supports configuration of sensor thresholds, sensor events, and other sensor related fields. bmc-device Uncommitted a tool to perform advanced BMC commands. ipmiping Uncommitted an IPMI ping tool for debugging. rmcpping Uncommitted a RMCP ping tool for debugging. ipmi-oem Uncommitted an IPMI tool for OEM specific commands. ipmidetect / ipmidetectd Uncommitted a tool and daemon for IPMI node detection Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- bmc_intf.h Contracted Private located in /onnv/onnv-gate/usr/src/uts/common/sys/bmc_intf.h - how to ask for contract? libgcrypt Committed located in /usr/lib/libgcrypt.so.11 6. Resources and Schedule: 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.5. ARC review type: Automatic 6.6. ARC Exposure: open --Boundary_(ID_fYXto2u+4/n0lieiVW2OQA) Content-type: text/x-vcard; name=Michael_Kearney.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Michael_Kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:Sun Microsystems, Inc.;Archive Core Engineering adr:500 Eldorado Blvd.;;Mailstop UBRM05-390;Broomfield;CO;80021;US email;internet:Michael.Kearney@Sun.com title:Staff Software Engineer tel;work:303-272-2402 tel;fax:303-272-6554 x-mozilla-html:TRUE url:http://www.sun.com/ version:2.1 end:vcard --Boundary_(ID_fYXto2u+4/n0lieiVW2OQA)-- From Darren.Moffat@sun.com Mon Apr 20 02:40:39 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3K9ecmt026159 for ; Mon, 20 Apr 2009 02:40:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3K9eQK2002079 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 20 Apr 2009 17:40:37 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00N0787P3500@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 02:40:37 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE00F4G87OE570@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 02:40:37 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3K9eaBE020635 for ; Mon, 20 Apr 2009 09:40:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00A007IZG400@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 10:40:36 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE00A8787DKU10@fe-emea-09.sun.com>; Mon, 20 Apr 2009 10:40:26 +0100 (BST) Date: Mon, 20 Apr 2009 10:40:25 +0100 From: Darren J Moffat Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Michael Kearney Cc: LSARC-ext@sun.com Message-id: <49EC4309.2080201@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 396 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. Please address the above issues and move the case to be reviewed in PSARC. -- Darren J Moffat From Michael.Kearney@sun.com Mon Apr 20 06:37:10 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KDb9ee024532 for ; Mon, 20 Apr 2009 06:37:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3KDaoBS017436 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 20 Apr 2009 14:37:08 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE0011LJ5W5L00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 07:37:08 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE00FM9J5VYI50@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 07:37:07 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3KDb7U5018151 for ; Mon, 20 Apr 2009 13:37:07 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00D00J3TQ000@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 07:37:07 -0600 (MDT) Received: from [129.147.49.125] ([unknown] [129.147.49.125]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE006HKJ5TL720@mail-amer.sun.com>; Mon, 20 Apr 2009 07:37:05 -0600 (MDT) Date: Mon, 20 Apr 2009 07:37:05 -0600 From: Michael Kearney Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49EC4309.2080201@Sun.COM> Sender: Michael.Kearney@sun.com To: Darren J Moffat Cc: Michael Kearney , LSARC-ext@sun.com Message-id: <49EC7A81.8040507@Sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_7frz+7JXiiAvyeeUSe+hGA)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 2709 This is a multi-part message in MIME format. --Boundary_(ID_7frz+7JXiiAvyeeUSe+hGA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT I've updated the IAM file to reflect fast track rather than self review.   Sorry, my bad.

       Best Regards,
             Michael

Darren J Moffat wrote:
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.

Please address the above issues and move the case to be reviewed in PSARC.

--
Darren J Moffat


--
Michael Kearney
Staff Software Engineer

Sun Microsystems, Inc.
MS UBRM05-390, 500 Eldorado Blvd
Broomfield, CO 80021 US
Phone 303-272-2402
Fax 303-272-6554
Email Michael.Kearney@Sun.COM
--Boundary_(ID_7frz+7JXiiAvyeeUSe+hGA) Content-type: text/x-vcard; name=Michael_Kearney.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Michael_Kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:Sun Microsystems, Inc.;Archive Core Engineering adr:500 Eldorado Blvd.;;Mailstop UBRM05-390;Broomfield;CO;80021;US email;internet:Michael.Kearney@Sun.com title:Staff Software Engineer tel;work:303-272-2402 tel;fax:303-272-6554 x-mozilla-html:TRUE url:http://www.sun.com/ version:2.1 end:vcard --Boundary_(ID_7frz+7JXiiAvyeeUSe+hGA)-- From Darren.Moffat@Sun.COM Mon Apr 20 06:39:53 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KDdqkG024551 for ; Mon, 20 Apr 2009 06:39:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3KDdpGN011625 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 20 Apr 2009 06:39:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00E05JAG2G00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 06:39:52 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE009CQJAFVJ60@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 06:39:51 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KDdogh002534 for ; Mon, 20 Apr 2009 13:39:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00H00IUWQ300@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 14:39:50 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE00ENXJA5HX00@fe-emea-09.sun.com>; Mon, 20 Apr 2009 14:39:41 +0100 (BST) Date: Mon, 20 Apr 2009 14:39:41 +0100 From: Darren J Moffat Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49EC7A81.8040507@Sun.com> Sender: Darren.Moffat@Sun.COM To: Michael Kearney Cc: Michael Kearney , LSARC-ext@Sun.COM Message-id: <49EC7B1D.5080305@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7A81.8040507@Sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 761 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 Regards, > Michael > > Darren J Moffat wrote: >> 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. >> >> Please address the above issues and move the case to be reviewed in >> PSARC. From Michal.Bachorik@sun.com Mon Apr 20 06:52:48 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KDqmJ8024732 for ; Mon, 20 Apr 2009 06:52:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3KDqjnw015737 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 20 Apr 2009 07:52:47 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00511JVZ5C00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 06:52:47 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE003SQJVXFT10@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 06:52:46 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KDqjSQ026471 for ; Mon, 20 Apr 2009 13:52:45 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00900JOFSV00@fe-emea-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 14:52:45 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE00EFUJVWHX10@fe-emea-09.sun.com>; Mon, 20 Apr 2009 14:52:44 +0100 (BST) Date: Mon, 20 Apr 2009 15:52:20 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49EC4309.2080201@Sun.COM> Sender: Michal.Bachorik@sun.com To: Darren J Moffat Cc: Michael Kearney , LSARC-ext@sun.com Message-id: <49EC7E14.40305@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_naR/UeKhqzU5nujro60QzQ)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2047 This is a multi-part message in MIME format. --Boundary_(ID_naR/UeKhqzU5nujro60QzQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 > interaction with the existing ipmitool is covered. Nor do I see any > way that the two daemons are started - I'd expect SMF services. Yes, there are two SMF services - one for bmc-watchdog, second for ipmidetecd. I thought it was clear from the Fast Track project document (section 5, "There will be a SMF manifest for each daemon taking care of daemon lifecycle."). Regarding the "ipmitool" - I was in contact with guys working on/with "ipmitool" (Kevin.Song@Sun.COM, Hesam.Kohanteb@Sun.COM, turgo-ipmi@Sun.COM ..) to clarify some technical details regarding the BMC driver, and they did not raise any objections/concerns regarding porting of freeipmi to Open Solaris, they were rather looking forward for it. Does my answer satisfy your question, or there should be detailed description what functionality is covered by ipmitool/freeipmi and whether they do compete or complement? Regards, Michal > > Please address the above issues and move the case to be reviewed in > PSARC. > > -- > Darren J Moffat > --Boundary_(ID_naR/UeKhqzU5nujro60QzQ) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_naR/UeKhqzU5nujro60QzQ)-- From Michal.Bachorik@sun.com Mon Apr 20 07:07:37 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KE7bPa025238 for ; Mon, 20 Apr 2009 07:07:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3KE7YFO028984 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 20 Apr 2009 07:07:37 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00657KKOQ500@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 07:07:36 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE003PPKKMFW40@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 07:07:35 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KE7YFH029370 for ; Mon, 20 Apr 2009 14:07:34 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00K00KBOUN00@fe-emea-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 15:07:34 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE00H1KKKGF010@fe-emea-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 15:07:28 +0100 (BST) Date: Mon, 20 Apr 2009 16:07:04 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49EC4309.2080201@Sun.COM> Sender: Michal.Bachorik@sun.com Cc: LSARC-ext@sun.com Message-id: <49EC8188.8090201@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_BS1RF6cmMDiXzKpA0WQdRA)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2053 This is a multi-part message in MIME format. --Boundary_(ID_BS1RF6cmMDiXzKpA0WQdRA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 > interaction with the existing ipmitool is covered. Nor do I see any > way that the two daemons are started - I'd expect SMF services. Yes, there are two SMF services - one for bmc-watchdog, second for ipmidetecd. I thought it was clear from the Fast Track project document (section 5, "There will be a SMF manifest for each daemon taking care of daemon lifecycle."). Regarding the "ipmitool" - I was in contact with guys working on/with "ipmitool" (Kevin.Song@Sun.COM, Hesam.Kohanteb@Sun.COM, turgo-ipmi@Sun.COM ..) to clarify some technical details regarding the BMC driver, and they did not raise any objections/concerns regarding porting of freeipmi to Open Solaris, they were rather looking forward for it. Does my answer satisfy your question, or there should be detailed description what functionality is covered by ipmitool/freeipmi and whether they do compete or complement? Regards, Michal PS: resending email to keep list on cc (had some troubles with my registration to opensolaris-arc@opensolaris.org) --Boundary_(ID_BS1RF6cmMDiXzKpA0WQdRA) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_BS1RF6cmMDiXzKpA0WQdRA)-- From Darren.Moffat@sun.com Mon Apr 20 07:13:24 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KEDMXg025394 for ; Mon, 20 Apr 2009 07:13:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3KEDMD5032411 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 20 Apr 2009 08:13:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00F0DKU9RT00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 07:13:21 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE009JKKU8VD90@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 07:13:21 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KEDKNO000461 for ; Mon, 20 Apr 2009 14:13:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00K00KBOUN00@fe-emea-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 15:13:20 +0100 (BST) Received: from [192.168.1.103] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE00HEOKTKF010@fe-emea-10.sun.com>; Mon, 20 Apr 2009 15:12:57 +0100 (BST) Date: Mon, 20 Apr 2009 15:12:56 +0100 From: Darren J Moffat Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49EC7E14.40305@sun.com> Sender: Darren.Moffat@sun.com To: Michal Bachorik - Sun Microsystems - Prague Czech Republic Cc: Michael Kearney , LSARC-ext@sun.com Message-id: <49EC82E8.8010701@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20090211) Status: RO Content-Length: 1745 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). >> >> 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. > Yes, there are two SMF services - one for bmc-watchdog, second for > ipmidetecd. I thought it was clear from the Fast Track project document > (section 5, "There will be a SMF > manifest for each daemon taking care of daemon lifecycle."). It wasn't what should be provided is the FMRI of the SMF service. > Regarding the "ipmitool" - I was in contact with guys working on/with > "ipmitool" (Kevin.Song@Sun.COM, Hesam.Kohanteb@Sun.COM, > turgo-ipmi@Sun.COM ..) to clarify some technical details regarding the > BMC driver, and they did not raise any objections/concerns regarding > porting of freeipmi to Open Solaris, they were rather looking forward > for it. Does my answer satisfy your question, or there should be > detailed description what functionality is covered by ipmitool/freeipmi > and whether they do compete or complement? I think the ARC needs to be presented with why this is needed given we have ipmitool. Also is there any impact to having these freeimpi daemons running given Solaris already has FMA ? What is the relationship between the daemons in this case and the ipmievd one from PSARC/2006/412 ? Particularly in light of the long discussion in that case about FAM. -- Darren J Moffat From Michael.Kearney@sun.com Mon Apr 20 10:19:44 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KHJhJU025664; Mon, 20 Apr 2009 10:19:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3KHJd27020627; Tue, 21 Apr 2009 01:19:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE0060HTGSBI00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 20 Apr 2009 10:19:41 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE003D0TGSK420@nwk-avmta-1.sfbay.Sun.COM>; Mon, 20 Apr 2009 10:19:40 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3KHJetV009175; Mon, 20 Apr 2009 17:19:40 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00500QT5LQ00@mail-amer.sun.com>; Mon, 20 Apr 2009 11:19:40 -0600 (MDT) Received: from [129.147.49.125] ([unknown] [129.147.49.125]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE006A9TGRSC30@mail-amer.sun.com>; Mon, 20 Apr 2009 11:19:39 -0600 (MDT) Date: Mon, 20 Apr 2009 11:19:38 -0600 From: Michael Kearney Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49EC7B1D.5080305@Sun.COM> Sender: Michael.Kearney@sun.com To: Darren J Moffat Cc: Michael Kearney , LSARC-ext@sun.com, PSARC-ext@sun.com Message-id: <49ECAEAA.80104@Sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_r+lCZmOvfyZJ0JL/bfMOPA)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7A81.8040507@Sun.com> <49EC7B1D.5080305@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 3334 This is a multi-part message in MIME format. --Boundary_(ID_r+lCZmOvfyZJ0JL/bfMOPA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Added PSARC-ext@sun.com to the interested party list.

    Regards,
          Michael

Darren J Moffat wrote:
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 Regards,
             Michael

Darren J Moffat wrote:
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.

Please address the above issues and move the case to be reviewed in PSARC.



--
Michael Kearney
Staff Software Engineer

Sun Microsystems, Inc.
MS UBRM05-390, 500 Eldorado Blvd
Broomfield, CO 80021 US
Phone 303-272-2402
Fax 303-272-6554
Email Michael.Kearney@Sun.COM
--Boundary_(ID_r+lCZmOvfyZJ0JL/bfMOPA) Content-type: text/x-vcard; name=Michael_Kearney.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Michael_Kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:Sun Microsystems, Inc.;Archive Core Engineering adr:500 Eldorado Blvd.;;Mailstop UBRM05-390;Broomfield;CO;80021;US email;internet:Michael.Kearney@Sun.com title:Staff Software Engineer tel;work:303-272-2402 tel;fax:303-272-6554 x-mozilla-html:TRUE url:http://www.sun.com/ version:2.1 end:vcard --Boundary_(ID_r+lCZmOvfyZJ0JL/bfMOPA)-- From Michael.Kearney@sun.com Mon Apr 20 10:19:44 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KHJhJU025664; Mon, 20 Apr 2009 10:19:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3KHJd27020627; Tue, 21 Apr 2009 01:19:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE0060HTGSBI00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 20 Apr 2009 10:19:41 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE003D0TGSK420@nwk-avmta-1.sfbay.Sun.COM>; Mon, 20 Apr 2009 10:19:40 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3KHJetV009175; Mon, 20 Apr 2009 17:19:40 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00500QT5LQ00@mail-amer.sun.com>; Mon, 20 Apr 2009 11:19:40 -0600 (MDT) Received: from [129.147.49.125] ([unknown] [129.147.49.125]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE006A9TGRSC30@mail-amer.sun.com>; Mon, 20 Apr 2009 11:19:39 -0600 (MDT) Date: Mon, 20 Apr 2009 11:19:38 -0600 From: Michael Kearney Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49EC7B1D.5080305@Sun.COM> Sender: Michael.Kearney@sun.com To: Darren J Moffat Cc: Michael Kearney , LSARC-ext@sun.com, PSARC-ext@sun.com Message-id: <49ECAEAA.80104@Sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_r+lCZmOvfyZJ0JL/bfMOPA)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7A81.8040507@Sun.com> <49EC7B1D.5080305@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 3334 This is a multi-part message in MIME format. --Boundary_(ID_r+lCZmOvfyZJ0JL/bfMOPA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Added PSARC-ext@sun.com to the interested party list.

    Regards,
          Michael

Darren J Moffat wrote:
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 Regards,
             Michael

Darren J Moffat wrote:
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.

Please address the above issues and move the case to be reviewed in PSARC.



--
Michael Kearney
Staff Software Engineer

Sun Microsystems, Inc.
MS UBRM05-390, 500 Eldorado Blvd
Broomfield, CO 80021 US
Phone 303-272-2402
Fax 303-272-6554
Email Michael.Kearney@Sun.COM
--Boundary_(ID_r+lCZmOvfyZJ0JL/bfMOPA) Content-type: text/x-vcard; name=Michael_Kearney.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Michael_Kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:Sun Microsystems, Inc.;Archive Core Engineering adr:500 Eldorado Blvd.;;Mailstop UBRM05-390;Broomfield;CO;80021;US email;internet:Michael.Kearney@Sun.com title:Staff Software Engineer tel;work:303-272-2402 tel;fax:303-272-6554 x-mozilla-html:TRUE url:http://www.sun.com/ version:2.1 end:vcard --Boundary_(ID_r+lCZmOvfyZJ0JL/bfMOPA)-- From Michal.Bachorik@sun.com Mon Apr 20 12:25:26 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KJPQ2d025043 for ; Mon, 20 Apr 2009 12:25:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3KJPOnO026984 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 20 Apr 2009 12:25:25 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIE00L0PZADO600@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 12:25:25 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIE00K9XZABY620@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 12:25:24 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KJPMCv001591 for ; Mon, 20 Apr 2009 19:25:22 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00400Z633100@fe-emea-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Mon, 20 Apr 2009 20:25:22 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIE00EWAZA5HXA0@fe-emea-09.sun.com>; Mon, 20 Apr 2009 20:25:18 +0100 (BST) Date: Mon, 20 Apr 2009 21:24:54 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49EC82E8.8010701@Sun.COM> Sender: Michal.Bachorik@sun.com To: Darren J Moffat Cc: Michael Kearney , LSARC-ext@sun.com Message-id: <49ECCC06.9080208@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_dUehuhazEpLiz1B5uAjRCg)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 3298 This is a multi-part message in MIME format. --Boundary_(ID_dUehuhazEpLiz1B5uAjRCg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 services. >> Yes, there are two SMF services - one for bmc-watchdog, second for >> ipmidetecd. I thought it was clear from the Fast Track project >> document (section 5, "There will be a SMF >> manifest for each daemon taking care of daemon lifecycle."). > > It wasn't what should be provided is the FMRI of the SMF service. Sure: - FMRI of bmc-watchdog is "system/freeipmi/bmc-watchdog" - FMRI of impidetectd is "system/freeipmi/ipmidetectd" > >> Regarding the "ipmitool" - I was in contact with guys working >> on/with "ipmitool" (Kevin.Song@Sun.COM, Hesam.Kohanteb@Sun.COM, >> turgo-ipmi@Sun.COM ..) to clarify some technical details regarding >> the BMC driver, and they did not raise any objections/concerns >> regarding porting of freeipmi to Open Solaris, they were rather >> looking forward for it. Does my answer satisfy your question, or >> there should be detailed description what functionality is covered by >> ipmitool/freeipmi and whether they do compete or complement? > > I think the ARC needs to be presented with why this is needed given we > have ipmitool. Answer directly from my director Fritz Ferstl (Friedrich.Ferstl@sun.com) : "We need freeimpi because it is used by 'Tortuga', the provisioning core of our OpenSolaris HPC SW stack. 'Tortuga' is open source and thus uses other open source components such as freeipmi. Usage of ipmitool has been assessed but freeipmi has found to be a better fit for the time being." > > 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 for example: - power-cycle remotely if needed. - shut down/startup machine if needed > > What is the relationship between the daemons in this case and the > ipmievd one from PSARC/2006/412 ? Particularly in light of the long > discussion in that case about FAM. The "ipmievd" is just logging the IPMI events to syslog while freeipmi "bmc-watchdog" is able to also trigger an action upon receive of an IPMI event. The "ipmidetecd" is able to find new machines in specified subnets that are exposing an IPMI interface and add it to "freeipmi managed" hosts. > > -- > Darren J Moffat --Boundary_(ID_dUehuhazEpLiz1B5uAjRCg) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_dUehuhazEpLiz1B5uAjRCg)-- From gdamore@sun.com Mon Apr 20 12:42:53 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KJgqkE026062 for ; Mon, 20 Apr 2009 12:42:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3KJgqhw003920 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 20 Apr 2009 12:42:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIF00A0303FQ300@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 12:42:51 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIF0007503EGNE0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 12:42:50 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3KJgoQb019009 for ; Mon, 20 Apr 2009 12:42:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIE00E00ZXWFD00@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 20 Apr 2009 12:42:50 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIF00BL6037GK90@fe-sfbay-10.sun.com>; Mon, 20 Apr 2009 12:42:44 -0700 (PDT) Date: Mon, 20 Apr 2009 12:42:43 -0700 From: "Garrett D'Amore" Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49ECCC06.9080208@sun.com> Sender: Garrett.Damore@sun.com To: Michal Bachorik - Sun Microsystems - Prague Czech Republic Cc: Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49ECD033.2000804@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3480 Michal Bachorik - Sun Microsystems - Prague Czech Republic wrote: > >> >>> Regarding the "ipmitool" - I was in contact with guys working >>> on/with "ipmitool" (Kevin.Song@Sun.COM, Hesam.Kohanteb@Sun.COM, >>> turgo-ipmi@Sun.COM ..) to clarify some technical details regarding >>> the BMC driver, and they did not raise any objections/concerns >>> regarding porting of freeipmi to Open Solaris, they were rather >>> looking forward for it. Does my answer satisfy your question, or >>> there should be detailed description what functionality is covered >>> by ipmitool/freeipmi and whether they do compete or complement? >> >> I think the ARC needs to be presented with why this is needed given >> we have ipmitool. > Answer directly from my director Fritz Ferstl > (Friedrich.Ferstl@sun.com) : > > "We need freeimpi because it is used by 'Tortuga', the provisioning > core of our OpenSolaris HPC SW stack. 'Tortuga' is open source and > thus uses other open source components such as freeipmi. Usage of > ipmitool has been assessed but freeipmi has found to be a better fit > for the time being." I'd like this spelled out in more detail. Specifically, *why* is freeipmi deemed a better fit? Is it simply a matter of licensing, or are the technical or architectural considerations here. One of the problems we (Sun) have historically suffered from is *too many* different service processor and platform management systems. I'm personally not too keen to integrate another one. Other questions (sorry if these seem obvious -- I've little experience with service processor stuff since the E10K SSP. :-) Can freeimpi and ipmitool coexist on the same platform? What int4tr Is this really a Linux familiarity case? IPMI specs seem to require signing an "Adopters agreement for IPMI" from Intel. Has anyone checked to see if freeipmi has followed the necessary steps so our legal bases are covered for integrating it? >> >> 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 for example: > - power-cycle remotely if needed. > - shut down/startup machine if needed I don't think the question here was answered... what is the impact on local FMA on a machine using freeipmi? Can freeipmi be used to monitor a local machine and notify FMA? Is it necessarily true that there is no overlap between these subsystems? >> >> What is the relationship between the daemons in this case and the >> ipmievd one from PSARC/2006/412 ? Particularly in light of the long >> discussion in that case about FAM. > > The "ipmievd" is just logging the IPMI events to syslog while freeipmi > "bmc-watchdog" is able to also trigger an action upon receive of an > IPMI event. The "ipmidetecd" is able to find new machines in specified > subnets that are exposing an IPMI interface and add it to "freeipmi > managed" hosts. Have the security implications of this been properly reviewed by a member of the security team? How does one ensure that a machine running ipmidetecd and the watchdog doesn't reboot a system that it shouldn't? Are there any authorization or authentication steps taken? Again, this might all be covered as part of IPMI itself, and so seem to be obvious, but not all the readers here (certainly not this author) are familiar with IPMI. -- Garrett From Nicolas.Williams@sun.com Mon Apr 20 13:04:36 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3KK4ZYZ026804 for ; Mon, 20 Apr 2009 13:04:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3KK4Wr5029095; Mon, 20 Apr 2009 21:04:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIF00B0B13KT700@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Apr 2009 13:04:32 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIF00A9T13JXZ10@nwk-avmta-2.sfbay.sun.com>; Mon, 20 Apr 2009 13:04:31 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3KK2WbZ014839; Mon, 20 Apr 2009 15:02:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3KK2W83014838; Mon, 20 Apr 2009 15:02:32 -0500 (CDT) Date: Mon, 20 Apr 2009 15:02:32 -0500 From: Nicolas Williams Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49ECD033.2000804@sun.com> To: "Garrett D'Amore" Cc: Michal Bachorik - Sun Microsystems - Prague Czech Republic , Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <20090420200232.GZ1500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1019 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 freeipmi is able to > >watch IPMI events from remote machines and perform for example: > >- power-cycle remotely if needed. > >- shut down/startup machine if needed > > I don't think the question here was answered... what is the impact on > local FMA on a machine using freeipmi? Can freeipmi be used to monitor > a local machine and notify FMA? Is it necessarily true that there is > no overlap between these subsystems? Most importantly: is there any negative impact on FMA? But also, FMA and SMF both seem to allow for the possibility of a networked future in that FMRIs are practically URIs. So maybe it's time to fund a project to make that happen? (That could be advice by the ARC to the PAC.) Nico -- From Michael.Kearney@sun.com Tue Apr 21 10:51:10 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LHpANu007412; Tue, 21 Apr 2009 10:51:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3LHp9P9010514; Tue, 21 Apr 2009 10:51:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIG00M1VPL8DR00@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Apr 2009 10:51:08 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIG00IFJPL7TA50@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Apr 2009 10:51:07 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3LHp7oI002762; Tue, 21 Apr 2009 17:51:07 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIG00M00OMEFM00@mail-amer.sun.com>; Tue, 21 Apr 2009 11:51:07 -0600 (MDT) Received: from [129.147.49.125] ([unknown] [129.147.49.125]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIG00DQRPKYGS30@mail-amer.sun.com>; Tue, 21 Apr 2009 11:50:58 -0600 (MDT) Date: Tue, 21 Apr 2009 11:50:58 -0600 From: Michael Kearney Subject: FreeIPMI [LSARC/2009/245 FastTrack] timeout extended one week to 05/01/2009 Sender: Michael.Kearney@sun.com To: LSARC-ext@sun.com, Michal Bachorik - Sun Microsystems - Prague Czech Republic , PSARC-ext@sun.com, Mark Carlson Message-id: <49EE0782.4010600@Sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_tr/70b6cqvG+BfNEUHBGyw)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 873 This is a multi-part message in MIME format. --Boundary_(ID_tr/70b6cqvG+BfNEUHBGyw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT FreeIPMI [LSARC/2009/245 FastTrack] timeout extended one week to 05/01/2009 to allow review in PSARC. --Boundary_(ID_tr/70b6cqvG+BfNEUHBGyw) Content-type: text/x-vcard; name=Michael_Kearney.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Michael_Kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:Sun Microsystems, Inc.;Archive Core Engineering adr:500 Eldorado Blvd.;;Mailstop UBRM05-390;Broomfield;CO;80021;US email;internet:Michael.Kearney@Sun.com title:Staff Software Engineer tel;work:303-272-2402 tel;fax:303-272-6554 x-mozilla-html:TRUE url:http://www.sun.com/ version:2.1 end:vcard --Boundary_(ID_tr/70b6cqvG+BfNEUHBGyw)-- From Michael.Kearney@sun.com Tue Apr 21 10:51:10 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3LHpANu007412; Tue, 21 Apr 2009 10:51:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3LHp9P9010514; Tue, 21 Apr 2009 10:51:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIG00M1VPL8DR00@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Apr 2009 10:51:08 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIG00IFJPL7TA50@nwk-avmta-2.sfbay.sun.com>; Tue, 21 Apr 2009 10:51:07 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3LHp7oI002762; Tue, 21 Apr 2009 17:51:07 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIG00M00OMEFM00@mail-amer.sun.com>; Tue, 21 Apr 2009 11:51:07 -0600 (MDT) Received: from [129.147.49.125] ([unknown] [129.147.49.125]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIG00DQRPKYGS30@mail-amer.sun.com>; Tue, 21 Apr 2009 11:50:58 -0600 (MDT) Date: Tue, 21 Apr 2009 11:50:58 -0600 From: Michael Kearney Subject: FreeIPMI [LSARC/2009/245 FastTrack] timeout extended one week to 05/01/2009 Sender: Michael.Kearney@sun.com To: LSARC-ext@sun.com, Michal Bachorik - Sun Microsystems - Prague Czech Republic , PSARC-ext@sun.com, Mark Carlson Message-id: <49EE0782.4010600@Sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_tr/70b6cqvG+BfNEUHBGyw)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 873 This is a multi-part message in MIME format. --Boundary_(ID_tr/70b6cqvG+BfNEUHBGyw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT FreeIPMI [LSARC/2009/245 FastTrack] timeout extended one week to 05/01/2009 to allow review in PSARC. --Boundary_(ID_tr/70b6cqvG+BfNEUHBGyw) Content-type: text/x-vcard; name=Michael_Kearney.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Michael_Kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:Sun Microsystems, Inc.;Archive Core Engineering adr:500 Eldorado Blvd.;;Mailstop UBRM05-390;Broomfield;CO;80021;US email;internet:Michael.Kearney@Sun.com title:Staff Software Engineer tel;work:303-272-2402 tel;fax:303-272-6554 x-mozilla-html:TRUE url:http://www.sun.com/ version:2.1 end:vcard --Boundary_(ID_tr/70b6cqvG+BfNEUHBGyw)-- From Michal.Bachorik@sun.com Fri Apr 24 07:38:23 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OEcM27027369 for ; Fri, 24 Apr 2009 07:38:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3OEcJYf017701 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 22:38:21 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM00K170NVDP00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 08:38:19 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00B6W0NU2M70@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 08:38:19 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OEcIxO013532 for ; Fri, 24 Apr 2009 14:38:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM009000KC8Q00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 15:38:18 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00BE60NKUN80@fe-emea-09.sun.com>; Fri, 24 Apr 2009 15:38:09 +0100 (BST) Date: Fri, 24 Apr 2009 16:37:42 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <20090420200232.GZ1500@Sun.COM> Sender: Michal.Bachorik@sun.com To: Nicolas Williams Cc: "Garrett D'Amore" , Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F1CEB6.1030105@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_s2+p+G7PgUXOB89ZO1y4mw)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <20090420200232.GZ1500@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 3425 This is a multi-part message in MIME format. --Boundary_(ID_s2+p+G7PgUXOB89ZO1y4mw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 for example: >>> - power-cycle remotely if needed. >>> - shut down/startup machine if needed >>> >> I don't think the question here was answered... what is the impact on >> local FMA on a machine using freeipmi? Can freeipmi be used to monitor >> a local machine and notify FMA? Is it necessarily true that there is >> no overlap between these subsystems? >> I am not FMA expert, but from what I know, FMA does not rely on service processor feature but on device drivers and OS features. On other hand, freeipmi (as a set of IPMI client tools) relies only on a service processor feature (and only on a service processor that supports IPMI 1.5/2.0, and not ELOM, ILOM etc.). Freeipmi CAN monitor local machine, if local machine HAS service processor feature. In current state, freeipmi is not able to notify FMA but if that would be needed, it could be done (s new feature). If local machines does NOT have service processor supporting IPMI, then freeipmi can NOT notify FMA. I think that there is NO overlap between freeipmi and FMA - first, freeipmi does not automatically switch monitoring services on, and even if it is switched on, it has to be defined what actions has to be performed under which circumstances. > > 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 configured in a way (I do not know if it is possible, just guessing) that it has to switch off the machine when CPU temperature reaches 60oC and freeipmi is faster then FMA (so it reboots the machine sooner, then FMA is able to perform shutdown), then YES, it can have negative impact. But in such sense, anything can have negative impact on FMA - for me, it is the administrator's responsibility to configure the machine in a way that it works reliable. It is important, that by default (after installation) freeimpi does NOTHING. it has to be configured to DO something. > But also, FMA and SMF both seem to allow for the possibility of a > networked future in that FMRIs are practically URIs. So maybe it's time > to fund a project to make that happen? (That could be advice by the ARC > to the PAC.) > I do not understand this - does it touch freeipmi ARC somehow? Regards, Michal > Nico > --Boundary_(ID_s2+p+G7PgUXOB89ZO1y4mw) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_s2+p+G7PgUXOB89ZO1y4mw)-- From gdamore@Sun.COM Fri Apr 24 08:46:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OFkkeA024813 for ; Fri, 24 Apr 2009 08:46:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3OFkah2027280 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 23:46:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM00J0B3TSEW00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 08:46:40 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00IF23TRCP20@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 08:46:39 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OFkYh9015757 for ; Fri, 24 Apr 2009 08:46:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM00L003AFKA00@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 08:46:35 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00FGP3THAFD0@fe-sfbay-09.sun.com>; Fri, 24 Apr 2009 08:46:30 -0700 (PDT) Date: Fri, 24 Apr 2009 08:46:29 -0700 From: "Garrett D'Amore" Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F1CEB6.1030105@sun.com> Sender: Garrett.Damore@Sun.COM To: Michal Bachorik - Sun Microsystems - Prague Czech Republic Cc: Nicolas Williams , Darren J Moffat , Michael Kearney , LSARC-ext@Sun.COM Message-id: <49F1DED5.3020909@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <20090420200232.GZ1500@Sun.COM> <49F1CEB6.1030105@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4348 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 freeipmi is able >>>> to watch IPMI events from remote machines and perform for example: >>>> - power-cycle remotely if needed. >>>> - shut down/startup machine if needed >>>> >>> I don't think the question here was answered... what is the impact >>> on local FMA on a machine using freeipmi? Can freeipmi be used to >>> monitor a local machine and notify FMA? Is it necessarily true >>> that there is no overlap between these subsystems? >>> > I am not FMA expert, but from what I know, FMA does not rely on > service processor feature but on device drivers and OS features. On > other hand, freeipmi (as a set of IPMI client tools) relies only on a > service processor feature (and only on a service processor that > supports IPMI 1.5/2.0, and not ELOM, ILOM etc.). > > Freeipmi CAN monitor local machine, if local machine HAS service > processor feature. In current state, freeipmi is not able to notify > FMA but if that would be needed, it could be done (s new feature). If > local machines does NOT have service processor supporting IPMI, then > freeipmi can NOT notify FMA. > > I think that there is NO overlap between freeipmi and FMA - first, > freeipmi does not automatically switch monitoring services on, and > even if it is switched on, it has to be defined what actions has to be > performed under which circumstances. Okay, it seems like for now, there isn't direct overlap unless the admin configures it. I believe there is potential for future interactions, though -- see 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 configured in a way (I do not > know if it is possible, just guessing) that it has to switch off the > machine when CPU temperature reaches 60oC and freeipmi is faster then > FMA (so it reboots the machine sooner, then FMA is able to perform > shutdown), then YES, it can have negative impact. > > But in such sense, anything can have negative impact on FMA - for me, > it is the administrator's responsibility to configure the machine in a > way that it works reliable. It is important, that by default (after > installation) freeimpi does NOTHING. it has to be configured to DO > something. 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 than a blind shut down. >> But also, FMA and SMF both seem to allow for the possibility of a >> networked future in that FMRIs are practically URIs. So maybe it's time >> to fund a project to make that happen? (That could be advice by the ARC >> to the PAC.) >> > > I do not understand this - does it touch freeipmi ARC somehow? The comments don't apply directly to you, except that perhaps we need to figure out in the future how to enable FMA to interact with IPMI or other service processor architectures. The advice would be something ARC would supply -- and not require any action on your part (at this time). On another front, I still don't think I've seen an answer to my questions about FreeIPMI & ipmitool interactions. Can they coexist? What are the interactions, if any? What is the justification for having a different tool than ipmitool? (You indicated that you'd done some analysis and chosen FreeIPMI, but no explanation was given about *why* this choice was made.) Is this just about Linux familiarity? Also, I'll repeat this question (although its really a C-Team issue and not an ARC one): IPMI specs seem to require signing an "Adopters agreement for IPMI" from Intel. Has anyone checked to see if freeipmi has followed the necessary steps so our legal bases are covered for integrating it? - Garrett > > Regards, > > Michal >> Nico >> > From Michal.Bachorik@sun.com Fri Apr 24 08:56:19 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OFuJfK025477 for ; Fri, 24 Apr 2009 08:56:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3OFu2Tm009337 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 09:56:18 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM0000D49UER00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 08:56:18 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00H0A49TJZ40@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 08:56:18 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OFuHNc021766 for ; Fri, 24 Apr 2009 15:56:17 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM00J003UUBN00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 16:56:17 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00BGC49OUNB0@fe-emea-09.sun.com>; Fri, 24 Apr 2009 16:56:14 +0100 (BST) Date: Fri, 24 Apr 2009 17:55:47 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49ECD033.2000804@sun.com> Sender: Michal.Bachorik@sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F1E103.2000108@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_t1eLNJmpcPWT+V8CDubqOg)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 11429 This is a multi-part message in MIME format. --Boundary_(ID_t1eLNJmpcPWT+V8CDubqOg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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@Sun.COM, Hesam.Kohanteb@Sun.COM, >>>> turgo-ipmi@Sun.COM ..) to clarify some technical details regarding >>>> the BMC driver, and they did not raise any objections/concerns >>>> regarding porting of freeipmi to Open Solaris, they were rather >>>> looking forward for it. Does my answer satisfy your question, or >>>> there should be detailed description what functionality is covered >>>> by ipmitool/freeipmi and whether they do compete or complement? >>> >>> I think the ARC needs to be presented with why this is needed given >>> we have ipmitool. >> Answer directly from my director Fritz Ferstl >> (Friedrich.Ferstl@sun.com) : >> >> "We need freeimpi because it is used by 'Tortuga', the provisioning >> core of our OpenSolaris HPC SW stack. 'Tortuga' is open source and >> thus uses other open source components such as freeipmi. Usage of >> ipmitool has been assessed but freeipmi has found to be a better fit >> for the time being." > > I'd like this spelled out in more detail. Specifically, *why* is > freeipmi deemed a better fit? Is it simply a matter of licensing, or > are the technical or architectural considerations here. For the UniCluster / Tortuga side freeipmi is used primarily for its "bmc-config" tool. The "bmc-config" command provides an easy way to extract the configuration information from on bmc and store it in a file that can be used to back up the configuration or be modified and pushed to other similar BMC's. Specifically UniCluster contains a tool called "bmc-tool" that allows you to extract the configuration from one bmc and push it to another while automatically replacing LAN configuration parameters. This tool is part of our general cluster BMC configuration strategy. The freeipmi tools, such as bmc-config, can be configured to use different drivers including the OpenIPMI driver (which is the default in our bmc-tool tool). > > One of the problems we (Sun) have historically suffered from is *too > many* different service processor and platform management systems. > I'm personally not too keen to integrate another one. freeipmi is just a CLIENT tool that supports ONLY IPMI service processors. > > Other questions (sorry if these seem obvious -- I've little experience > with service processor stuff since the E10K SSP. :-) > > 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) > > Is this really a Linux familiarity case? well, I believe it is. why it would not be? freeipmi has good name in linux world (as a set of ipmi client tools) > > IPMI specs seem to require signing an "Adopters agreement for IPMI" > from Intel. Has anyone checked to see if freeipmi has followed the > necessary steps so our legal bases are covered for integrating it? I will try to double check this, but I bet the "Adopters agreement for IPMI" has to be signed by companies implementing IPMI spec which is not freeipmi case (that are implementing client tools) - in fact, as the Sun is already providing servers with IPMI interface, I believe that Sun has signed "Adopters agreement for IPMI". > >>> >>> What is the relationship between the daemons in this case and the >>> ipmievd one from PSARC/2006/412 ? Particularly in light of the long >>> discussion in that case about FAM. >> >> The "ipmievd" is just logging the IPMI events to syslog while >> freeipmi "bmc-watchdog" is able to also trigger an action upon >> receive of an IPMI event. The "ipmidetecd" is able to find new >> machines in specified subnets that are exposing an IPMI interface and >> add it to "freeipmi managed" hosts. > > Have the security implications of this been properly reviewed by a > member of the security team? How does one ensure that a machine > running ipmidetecd and the watchdog doesn't reboot a system that it > shouldn't? Are there any authorization or authentication steps > taken? Again, this might all be covered as part of IPMI itself, and > so seem to be obvious, but not all the readers here (certainly not > this author) are familiar with IPMI. I am not aware of any member of security team that would do the security review - I did not know it is needed. If it is needed, I will try to arrange it - is there any process behind it, or can you give me a contact to someone? Regarding your question, I will try to enlighten it: 1. IPMI standard clearly defines the authentication and authorization of users (described in foss checkslist in 3.4.6, see bottom of email please) 2. user management is performed on SP side - so, on SP side you can define users (with credentials) and grant them permissions to perform certain activities. IPMI defines 3 groups of permissions (monitor/user, manager/operator, admin). - monitor/user has ability just monitor the platform - manager/operator has (in addition to monitor/user group) ability to perform for example power operations - admin has (in addtion to manager/operator) ability to manage SP (access control, reset SP, upload new firmware etc.) (through vendor extension, it is possible to setup SP in a way, that users are taken from DS (NIS, AD, LDAP) and permissions mapping is done through DS groups (e.g. all users from NIS group "ipmi_ops" will be granted "manager/operator" permissions)) 3. freeipmi (or any other IPMI client tool, e.g. ipmitool) has to specify the "SP user" to authenticate the access to SP. authorization to perform the action (reboot the machine, for example) is then done on SP side by comparing the authenticated user's permissions. By default, any SP is delivered with only ADMIN user with some "predefined" password. It is up-to system (lab) administrator to setup SP users that have ability to access the SP. In freeipmi client tools you need to specify user that is used when accessing the SP - this applies also for watchdog services. Example - command performed as user "mb123456": > ipmimonitoring -h latte2 -u uadmin where "-u uadmin" specifies that for authentication the user with name "uadmin" has to be used. for command to be successful, the user "uadmin" has to be defined on SP side and it has to be in group (at least) "monitor/user"AND a valid password for user "uadmin" has to be provided (the command will prompt for password upon invocation). For services (bmc-watchdog and ipmidetecd), the password for user that is configured to access the SP is stored in file and file is readable only by the user that is used to run the service. Regards, Michal PS: excerpt from freeipmi foss checklist regarding the IPMI security, as used by freeipmi: The authentication/authorization mechanism is part of project nework services (as defined by IPMI spec.) and it takes into acount the user identity. A functionality available to the user depends on successful authentication and on the user authorization. The project implements the authentication mechanism as requested by IMPI 1.5 and 2.0 specification. For communication involving IPMI 1.5 clients/sides, available authentication types are (defaults to MD5 if not specified): - NONE, - STRAIGHT_PASSWORD_KEY, - MD2, - MD5 For communication involving IPMI 2.0 clients/sides, it is possible to choose a "cipher suite" to be used. The Cipher Suite is a set of authentication, integrity, and confidentiality algorithms to use for IPMI 2.0 communication. The authentication algorithm identifies the algorithm to use for session setup, the integrity algorithm identifies the algorithm to use for session packet signatures, and the confidentiality algorithm identifies the algorithm to use for payload encryption. Defaults to cipher suite ID 3 if not specified (see below). The following cipher suite ids are currently supported: 0 - Authentication Algorithm = None; Integrity Algorithm = None; Confidentiality Algorithm = None 1 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = None; Confidentiality Algorithm = None 2 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = None 3 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = AES-CBC-128 ." .sp ." 4 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = xRC4-128 ." .sp ." 5 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm = HMAC-SHA1-96; Confidentiality Algorithm = xRC4-40 6 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = None; Confidentiality Algorithm = None 7 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = None 8 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = AES-CBC-128 ." .sp ." 9 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = xRC4-128 ." .sp ." 10 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = HMAC-MD5-128; Confidentiality Algorithm = xRC4-40 11 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = None 12 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = AES-CBC-128 ." .sp ." 13 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = xRC4-128 ." .sp ." 14 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm = MD5-128; Confidentiality Algorithm = xRC4-40 In addition, project supports specifying the privilege level (according the IPMI specification) which can be of (defaults to admin): - USER - OPERATOR - ADMIN Notice, that the authentication/authorization is not done at the operating system level, but on the IPMI level (adheres to requirements and recommendations of IPMI spec). > > -- Garrett > > --Boundary_(ID_t1eLNJmpcPWT+V8CDubqOg) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_t1eLNJmpcPWT+V8CDubqOg)-- From Michal.Bachorik@sun.com Fri Apr 24 09:08:11 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OG8ADe025827 for ; Fri, 24 Apr 2009 09:08:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3OG81fE022007 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 17:08:09 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM0051R4TKTF00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 10:08:08 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00B5M4TI2JD0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 10:08:07 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OG86Xs019938 for ; Fri, 24 Apr 2009 16:08:06 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM00A004DPFR00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 17:08:06 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00BRD4T2UNB0@fe-emea-09.sun.com>; Fri, 24 Apr 2009 17:07:53 +0100 (BST) Date: Fri, 24 Apr 2009 18:07:25 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F1DED5.3020909@sun.com> Sender: Michal.Bachorik@sun.com To: "Garrett D'Amore" Cc: Nicolas Williams , Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F1E3BD.9050704@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_1n6WD00g4YRYMKN8W2Dn+A)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <20090420200232.GZ1500@Sun.COM> <49F1CEB6.1030105@sun.com> <49F1DED5.3020909@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 4304 This is a multi-part message in MIME format. --Boundary_(ID_1n6WD00g4YRYMKN8W2Dn+A) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 configured in a way (I do not >> know if it is possible, just guessing) that it has to switch off the >> machine when CPU temperature reaches 60oC and freeipmi is faster then >> FMA (so it reboots the machine sooner, then FMA is able to perform >> shutdown), then YES, it can have negative impact. >> >> But in such sense, anything can have negative impact on FMA - for me, >> it is the administrator's responsibility to configure the machine in >> a way that it works reliable. It is important, that by default (after >> installation) freeimpi does NOTHING. it has to be configured to DO >> something. > > 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 than a > blind shut down. Shutting down a machine was just an example - I think IPMI could be capable of doing similar things (increase FAN speed, disabling core - i am not 100% sure if in current version, but IPMI is evolving as it is pretty much standard for platform operations management in HW) or even just for sending a SNMP alert or to send the email. I believe that FMA is important feature and useful, but there is one differentiator - ipmi can be used for watching the machine remotely and perform the platform operation without having access to operating system. this is important for HPCin situations, where large cluster (zounds of nodes) are needed to be restarted, or just shutdown without touching the OS (for example, OS re-provisioning is going to be performed and we do not wait until current OS would go down). > >>> But also, FMA and SMF both seem to allow for the possibility of a >>> networked future in that FMRIs are practically URIs. So maybe it's >>> time >>> to fund a project to make that happen? (That could be advice by the >>> ARC >>> to the PAC.) >>> >> >> I do not understand this - does it touch freeipmi ARC somehow? > > The comments don't apply directly to you, except that perhaps we need > to figure out in the future how to enable FMA to interact with IPMI or > other service processor architectures. The advice would be something > ARC would supply -- and not require any action on your part (at this > time). > > On another front, I still don't think I've seen an answer to my > questions about FreeIPMI & ipmitool interactions. > > Can they coexist? What are the interactions, if any? What is the > justification for having a different tool than ipmitool? (You > indicated that you'd done some analysis and chosen FreeIPMI, but no > explanation was given about *why* this choice was made.) Is this just > about Linux familiarity? > > Also, I'll repeat this question (although its really a C-Team issue > and not an ARC one): IPMI specs seem to require signing an "Adopters > agreement for IPMI" from Intel. Has anyone checked to see if freeipmi > has followed the necessary steps so our legal bases are covered for > integrating it? I just answered all 3 above questions in separate email, sorry for scattering the info. Regards, Michal > > - Garrett > >> >> Regards, >> >> Michal >>> Nico >>> >> > --Boundary_(ID_1n6WD00g4YRYMKN8W2Dn+A) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_1n6WD00g4YRYMKN8W2Dn+A)-- From gdamore@sun.com Fri Apr 24 09:15:01 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OGExOw025931 for ; Fri, 24 Apr 2009 09:14:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3OGErXb027029 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 17:14:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM0030154V3M00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 09:14:55 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00H6154VJY60@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 09:14:55 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OGEsdA011727 for ; Fri, 24 Apr 2009 09:14:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM0050050UGN00@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 09:14:54 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM004LV54M4680@fe-sfbay-09.sun.com>; Fri, 24 Apr 2009 09:14:46 -0700 (PDT) Date: Fri, 24 Apr 2009 09:14:46 -0700 From: "Garrett D'Amore" Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F1E103.2000108@sun.com> Sender: Garrett.Damore@sun.com To: Michal Bachorik - Sun Microsystems - Prague Czech Republic Cc: Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F1E576.5040305@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 663 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 From gdamore@sun.com Fri Apr 24 09:17:00 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OGGwW5025987 for ; Fri, 24 Apr 2009 09:16:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3OGGs17028280 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 17:16:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM00L135881H00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Fri, 24 Apr 2009 09:16:56 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00IL9587CT50@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Fri, 24 Apr 2009 09:16:56 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OGGtGP012000 for ; Fri, 24 Apr 2009 09:16:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM000004Z8Z100@fe-sfbay-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Fri, 24 Apr 2009 09:16:55 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM004IW57S1Q80@fe-sfbay-10.sun.com>; Fri, 24 Apr 2009 09:16:40 -0700 (PDT) Date: Fri, 24 Apr 2009 09:16:40 -0700 From: "Garrett D'Amore" Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F1E3BD.9050704@sun.com> Sender: Garrett.Damore@sun.com To: Michal Bachorik - Sun Microsystems - Prague Czech Republic Cc: Nicolas Williams , Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F1E5E8.4050607@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <20090420200232.GZ1500@Sun.COM> <49F1CEB6.1030105@sun.com> <49F1DED5.3020909@sun.com> <49F1E3BD.9050704@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2606 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 and performs shutdown when CPU >>> temperature reaches 60oC while FMA is configured in a way (I do not >>> know if it is possible, just guessing) that it has to switch off the >>> machine when CPU temperature reaches 60oC and freeipmi is faster >>> then FMA (so it reboots the machine sooner, then FMA is able to >>> perform shutdown), then YES, it can have negative impact. >>> >>> But in such sense, anything can have negative impact on FMA - for >>> me, it is the administrator's responsibility to configure the >>> machine in a way that it works reliable. It is important, that by >>> default (after installation) freeimpi does NOTHING. it has to be >>> configured to DO something. >> >> 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 than a >> blind shut down. > > Shutting down a machine was just an example - I think IPMI could be > capable of doing similar things (increase FAN speed, disabling core - > i am not 100% sure if in current version, but IPMI is evolving as it > is pretty much standard for platform operations management in HW) or > even just for sending a SNMP alert or to send the email. The issue here isn't IPMI, but rather what is "freeipmi" capable of doing, and if it is being used for "control", then there are potential ways that the freeipmi tool and FMA can step on each other's toes. > > I believe that FMA is important feature and useful, but there is one > differentiator - ipmi can be used for watching the machine remotely > and perform the platform operation without having access to operating > system. this is important for HPCin situations, where large cluster > (zounds of nodes) are needed to be restarted, or just shutdown without > touching the OS (for example, OS re-provisioning is going to be > performed and we do not wait until current OS would go down). Ok. > I just answered all 3 above questions in separate email, sorry for > scattering the info. Yep, saw that. Thanks. - Garrett > > Regards, > > Michal >> >> - Garrett >> >>> >>> Regards, >>> >>> Michal >>>> Nico >>>> >>> >> > From Michal.Bachorik@sun.com Fri Apr 24 09:24:17 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OGOFWM026108 for ; Fri, 24 Apr 2009 09:24:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3OGO5S6018126 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Sat, 25 Apr 2009 00:24:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM0043D5KB8D00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 09:24:11 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00HMA5K8K650@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 09:24:09 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OGO76C023976 for ; Fri, 24 Apr 2009 16:24:07 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM00F005DXIZ00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 17:24:07 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00B415K6UNC0@fe-emea-09.sun.com>; Fri, 24 Apr 2009 17:24:07 +0100 (BST) Date: Fri, 24 Apr 2009 18:23:41 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F1E5E8.4050607@sun.com> Sender: Michal.Bachorik@sun.com To: "Garrett D'Amore" Cc: Nicolas Williams , Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F1E78D.2080400@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_gNYv+8IuxXv65+TeUEt+Hg)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <20090420200232.GZ1500@Sun.COM> <49F1CEB6.1030105@sun.com> <49F1DED5.3020909@sun.com> <49F1E3BD.9050704@sun.com> <49F1E5E8.4050607@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1691 This is a multi-part message in MIME format. --Boundary_(ID_gNYv+8IuxXv65+TeUEt+Hg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT >>> >>> 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 than a blind shut down. >> >> Shutting down a machine was just an example - I think IPMI could be >> capable of doing similar things (increase FAN speed, disabling core - >> i am not 100% sure if in current version, but IPMI is evolving as it >> is pretty much standard for platform operations management in HW) or >> even just for sending a SNMP alert or to send the email. > > The issue here isn't IPMI, but rather what is "freeipmi" capable of > doing, and if it is being used for "control", then there are potential > ways that the freeipmi tool and FMA can step on each other's toes. > Mhm, I see now - is there anything that I should do about this? Michal --Boundary_(ID_gNYv+8IuxXv65+TeUEt+Hg) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_gNYv+8IuxXv65+TeUEt+Hg)-- From Michal.Bachorik@sun.com Fri Apr 24 11:40:26 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OIeQOP029558 for ; Fri, 24 Apr 2009 11:40:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3OIeDOP059642 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 12:40:25 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM00L21BVC6F00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 12:40:24 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM009XCBV8LX60@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 12:40:21 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OIeKrL028078 for ; Fri, 24 Apr 2009 18:40:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM00K00BP76700@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 19:40:20 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00B6DBV7UND0@fe-emea-09.sun.com>; Fri, 24 Apr 2009 19:40:20 +0100 (BST) Date: Fri, 24 Apr 2009 20:39:54 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F1E576.5040305@sun.com> Sender: Michal.Bachorik@sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F2077A.2070604@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_1aCUtB23PAyv/6LbO0CaBA)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2142 This is a multi-part message in MIME format. --Boundary_(ID_1aCUtB23PAyv/6LbO0CaBA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 > > --Boundary_(ID_1aCUtB23PAyv/6LbO0CaBA) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_1aCUtB23PAyv/6LbO0CaBA)-- From gdamore@sun.com Fri Apr 24 11:50:31 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OIoVPO029800 for ; Fri, 24 Apr 2009 11:50:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3OIoUQj012044 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 11:50:30 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM00707CC60I00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 11:50:30 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM005PJCC6EQ40@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 11:50:30 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OIoUQA004263 for ; Fri, 24 Apr 2009 11:50:30 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM00E00C7CV700@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 11:50:30 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM006XDCBXY8A0@fe-sfbay-09.sun.com>; Fri, 24 Apr 2009 11:50:22 -0700 (PDT) Date: Fri, 24 Apr 2009 11:50:21 -0700 From: "Garrett D'Amore" Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F2077A.2070604@sun.com> Sender: Garrett.Damore@sun.com To: Michal Bachorik - Sun Microsystems - Prague Czech Republic Cc: Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F209ED.6090902@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2252 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 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 >> >> > From Michal.Bachorik@sun.com Fri Apr 24 12:11:16 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OJBEc9002381 for ; Fri, 24 Apr 2009 12:11:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3OJB92p001306 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 20:11:14 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM0010FDAN7M00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 13:11:11 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM009MLDAMM080@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 13:11:10 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OJB99D000884 for ; Fri, 24 Apr 2009 19:11:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM00700CZLHC00@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 20:11:09 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00JFCDAKTQB0@fe-emea-10.sun.com>; Fri, 24 Apr 2009 20:11:09 +0100 (BST) Date: Fri, 24 Apr 2009 21:10:44 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F209ED.6090902@sun.com> Sender: Michal.Bachorik@sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F20EB4.2020104@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_kcg1XzKyX1/8ASLl9VEBGQ)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 3131 This is a multi-part message in MIME format. --Boundary_(ID_kcg1XzKyX1/8ASLl9VEBGQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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 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 >>> >>> >> > > --Boundary_(ID_kcg1XzKyX1/8ASLl9VEBGQ) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_kcg1XzKyX1/8ASLl9VEBGQ)-- From gdamore@sun.com Fri Apr 24 12:31:51 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3OJVo2f027108 for ; Fri, 24 Apr 2009 12:31:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3OJVU8i014827 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 24 Apr 2009 20:31:50 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIM0041DE8ZU100@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 12:31:47 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIM00NW9E8Y0780@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 12:31:46 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3OJVkns014538 for ; Fri, 24 Apr 2009 12:31:46 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIM00000E4M1K00@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 24 Apr 2009 12:31:46 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIM00D5CE8VKHB0@fe-sfbay-09.sun.com>; Fri, 24 Apr 2009 12:31:44 -0700 (PDT) Date: Fri, 24 Apr 2009 12:31:43 -0700 From: "Garrett D'Amore" Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F20EB4.2020104@sun.com> Sender: Garrett.Damore@sun.com To: Michal Bachorik - Sun Microsystems - Prague Czech Republic Cc: Darren J Moffat , Michael Kearney , LSARC-ext@sun.com Message-id: <49F2139F.6060706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2908 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 >>>> >>>> >>> >> >> > From daleg@elemental.org Mon Apr 27 15:41:31 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3RMfVnm029679 for ; Mon, 27 Apr 2009 15:41:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3RMfSBQ054229; Mon, 27 Apr 2009 16:41:29 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIS00507712KO00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 27 Apr 2009 15:41:26 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIS00EC2711HE70@nwk-avmta-1.sfbay.Sun.COM>; Mon, 27 Apr 2009 15:41:25 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3RMfP8p009082; Mon, 27 Apr 2009 22:41:25 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-1175138; Mon, 27 Apr 2009 22:41:24 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-35701459; Mon, 27 Apr 2009 22:41:24 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay1i.sun.com with ESMTP id BT-MMP-30491618; Mon, 27 Apr 2009 22:41:24 +0000 (Z) Received: from [10.75.10.106] (nat-204-14-233-149-rvo.net.salesforce.com [204.14.233.149]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n3RMfKd9025360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Apr 2009 18:41:21 -0400 (EDT) Date: Mon, 27 Apr 2009 18:41:13 -0400 From: Dale Ghent Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F2139F.6060706@sun.com> To: "Garrett D'Amore" Cc: Michal Bachorik - Sun Microsystems - Prague Czech Republic , Michael Kearney , LSARC-ext@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Mon, 27 Apr 2009 18:41:21 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=-2.6/5.0, scanned in 0.088sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> <49F2139F.6060706@sun.com> Status: RO Content-Length: 3473 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@opensolaris.org From Seth.Goldberg@Sun.COM Mon Apr 27 16:25:04 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3RNP4uw027179 for ; Mon, 27 Apr 2009 16:25:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n3RNP1h2009704 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 27 Apr 2009 17:25:03 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIS00K0391QF300@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 17:25:02 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIS003S991PPPD0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 17:25:02 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3RNP1Mi005720 for ; Mon, 27 Apr 2009 16:25:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIS004008UV6E00@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 16:25:01 -0700 (PDT) Received: from kasha ([unknown] [10.1.48.74]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIS00MIV91PK320@fe-sfbay-10.sun.com>; Mon, 27 Apr 2009 16:25:01 -0700 (PDT) Date: Mon, 27 Apr 2009 16:23:14 -0700 (PDT) From: Seth Goldberg Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: Sender: Seth.Goldberg@Sun.COM X-X-Sender: sethg@"bergsoft.West.Sun.COM." To: Dale Ghent Cc: "Garrett D'Amore" , Michal Bachorik - Sun Microsystems - Prague Czech Republic , Michael Kearney , LSARC-ext@Sun.COM Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> <49F2139F.6060706@sun.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) Status: RO Content-Length: 3808 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 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@opensolaris.org > > From gdamore@sun.com Mon Apr 27 16:30:31 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3RNUUto027333 for ; Mon, 27 Apr 2009 16:30:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3RNUQ6G003180 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 28 Apr 2009 00:30:30 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIS00L059AT0P00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 17:30:29 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIS0032W9ATQ4C0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 17:30:29 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3RNUT0h009013 for ; Mon, 27 Apr 2009 16:30:29 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIS004008UV6E00@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 27 Apr 2009 16:30:29 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIS00MXV9A2K330@fe-sfbay-10.sun.com>; Mon, 27 Apr 2009 16:30:02 -0700 (PDT) Date: Mon, 27 Apr 2009 16:30:01 -0700 From: "Garrett D'Amore" Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: Sender: Garrett.Damore@sun.com To: Seth Goldberg Cc: Dale Ghent , Michal Bachorik - Sun Microsystems - Prague Czech Republic , Michael Kearney , LSARC-ext@sun.com Message-id: <49F63FF9.5040401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> <49F2139F.6060706@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4377 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@opensolaris.org >> >> > From daleg@elemental.org Mon Apr 27 17:18:35 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3S0IYcW028034 for ; Mon, 27 Apr 2009 17:18:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n3S0IQlB005503; Tue, 28 Apr 2009 08:18:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIS00I01BITS800@nwk-avmta-1.sfbay.Sun.COM>; Mon, 27 Apr 2009 17:18:29 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIS00E1EBISHKE0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 27 Apr 2009 17:18:29 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3S0ISeL027423; Tue, 28 Apr 2009 00:18:28 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-1177112; Tue, 28 Apr 2009 00:16:28 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-34916276; Tue, 28 Apr 2009 00:16:27 +0000 (Z) Received: from mercury.elemental.org ([205.134.191.194] [205.134.191.194]) by relay1i.sun.com with ESMTP id BT-MMP-30520621; Tue, 28 Apr 2009 00:16:27 +0000 (Z) Received: from [10.75.10.106] (nat-204-14-233-149-rvo.net.salesforce.com [204.14.233.149]) (authenticated bits=0) by mercury.elemental.org (8.14.3/8.14.3/ELEMENTAL-4.0) with ESMTP id n3S0GMdY000533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Apr 2009 20:16:22 -0400 (EDT) Date: Mon, 27 Apr 2009 20:16:21 -0400 From: Dale Ghent Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F63FF9.5040401@sun.com> To: "Garrett D'Amore" Cc: Seth Goldberg , Michal Bachorik - Sun Microsystems - Prague Czech Republic , Michael Kearney , LSARC-ext@sun.com Message-id: <8CEA7D66-1412-4A8F-95AD-EAA7AD52DE71@elemental.org> MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mercury.elemental.org [205.134.191.194]); Mon, 27 Apr 2009 20:16:22 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.93.1, clamav-milter version 0.93.1 on mercury.elemental.org X-Virus-Status: Clean X-Antispam: No, score=-2.6/5.0, scanned in 0.117sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> <49F2139F.6060706@sun.com> <49F63FF9.5040401@sun.com> Status: RO Content-Length: 5886 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 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 I've often wondered about this aspect - being that IPMI LAN and BMC is pretty much the defacto Solaris <-> Hardware control interface on Sun x64 and UltraSPARC-T1 systems by way of ILOM. We even have our own IPMI library shipped with Solaris, of which FMA is the only consumer afaik. On the administration side, openipmi (ipmitool) has so far been the only shipping interface to BMC and LAN channels - which is all well and good as that is what Linux and other OSes tend to use. However that tool suffers from some inconsistency and has a hackish feel to it. The currently shipping ipmitool's "sunoem" subcommand doesn't do a thing when trying to manipulate ILOM from the OS (one has to install a second unbundled ipmitool into /opt from the "Sun Fire Xxxxx Server Software CD" to get that) which renders it pretty useless aside from reading SEL, sensors and the like. I've thought about extending prtdiag on x64 to use libipmi to add sensor and fru output like what you'd find on a SPARC system, but as noted in the comments of the prtdiag source, that has its own pitfalls. What Solaris is lacking is, dare I say, something akin (in concept) to Dell's OMSA racadm utility which they have for Linux and Windows. /dale > >> >> --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@opensolaris.org >>> >>> >> > From Michal.Bachorik@Sun.COM Thu Apr 30 03:51:21 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n3UApK52013584 for ; Thu, 30 Apr 2009 03:51:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n3UApJbi007581 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 30 Apr 2009 11:51:20 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KIW00M05U5JPW00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 30 Apr 2009 03:51:19 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KIW00DGYU56R6A0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 30 Apr 2009 03:51:19 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n3UAp5Qq022481 for ; Thu, 30 Apr 2009 10:51:05 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KIW00L00T9DE000@fe-emea-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 30 Apr 2009 11:51:05 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KIW002K0U51II80@fe-emea-10.sun.com>; Thu, 30 Apr 2009 11:51:03 +0100 (BST) Date: Thu, 30 Apr 2009 12:50:35 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <8CEA7D66-1412-4A8F-95AD-EAA7AD52DE71@elemental.org> Sender: Michal.Bachorik@Sun.COM To: Dale Ghent Cc: "Garrett D'Amore" , Seth Goldberg , Michael Kearney , LSARC-ext@Sun.COM Message-id: <49F9827B.3070502@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Cz5H4fSCRfa2FMwjGRWtOA)" X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> <49F2139F.6060706@sun.com> <49F63FF9.5040401@sun.com> <8CEA7D66-1412-4A8F-95AD-EAA7AD52DE71@elemental.org> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2973 This is a multi-part message in MIME format. --Boundary_(ID_Cz5H4fSCRfa2FMwjGRWtOA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT 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: >>> 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 > > I've often wondered about this aspect - being that IPMI LAN and BMC is > pretty much the defacto Solaris <-> Hardware control interface on Sun > x64 and UltraSPARC-T1 systems by way of ILOM. We even have our own > IPMI library shipped with Solaris, of which FMA is the only consumer > afaik. > > On the administration side, openipmi (ipmitool) has so far been the > only shipping interface to BMC and LAN channels - which is all well > and good as that is what Linux and other OSes tend to use. However > that tool suffers from some inconsistency and has a hackish feel to > it. The currently shipping ipmitool's "sunoem" subcommand doesn't do a > thing when trying to manipulate ILOM from the OS (one has to install a > second unbundled ipmitool into /opt from the "Sun Fire Xxxxx Server > Software CD" to get that) which renders it pretty useless aside from > reading SEL, sensors and the like. > > I've thought about extending prtdiag on x64 to use libipmi to add > sensor and fru output like what you'd find on a SPARC system, but as > noted in the comments of the prtdiag source, that has its own > pitfalls. What Solaris is lacking is, dare I say, something akin (in > concept) to Dell's OMSA racadm utility which they have for Linux and > Windows. > > /dale > --Boundary_(ID_Cz5H4fSCRfa2FMwjGRWtOA) Content-type: text/x-vcard; name=michal_bachorik.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michal_bachorik.vcf begin:vcard fn:Michal Bachorik n:Bachorik;Michal org:Sun Microsystems;SGE adr:;;V Parku 2308/8;Prague;CZ;14800;Czech Republic email;internet:michal.bachorik@sun.com title:Software Engineer tel;work:+420233009649 tel;home:+420241404479 tel;cell:+420775182551 x-mozilla-html:TRUE version:2.1 end:vcard --Boundary_(ID_Cz5H4fSCRfa2FMwjGRWtOA)-- From Michal.Bachorik@sun.com Tue May 5 08:29:22 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n45FTMKS004589 for ; Tue, 5 May 2009 08:29:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n45FTLsd013036 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 5 May 2009 08:29:22 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ600A19GCYTB00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 05 May 2009 08:29:22 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ6002EBGCLX650@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 05 May 2009 08:29:21 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n45FT8CW025513 for ; Tue, 05 May 2009 15:29:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ600A00F2KGT00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 05 May 2009 16:29:08 +0100 (BST) Received: from [10.18.143.62] ([unknown] [10.18.143.62]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ600BVSGC4TV70@fe-emea-09.sun.com>; Tue, 05 May 2009 16:28:54 +0100 (BST) Date: Tue, 05 May 2009 17:28:22 +0200 From: Michal Bachorik - Sun Microsystems - Prague Czech Republic Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <49F63FF9.5040401@sun.com> Sender: Michal.Bachorik@sun.com To: "Garrett D'Amore" Cc: Seth Goldberg , Dale Ghent , Michael Kearney , LSARC-ext@sun.com Message-id: <4A005B16.1000805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> <49F2139F.6060706@sun.com> <49F63FF9.5040401@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 6373 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@opensolaris.org >>> >>> >> > From gdamore@sun.com Tue May 5 08:46:30 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n45FkUK8004993 for ; Tue, 5 May 2009 08:46:30 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n45FkTk9028479 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 5 May 2009 09:46:29 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ600F05H5HKX00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 05 May 2009 09:46:29 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ6003CRH5G6H90@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 05 May 2009 09:46:28 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n45FkSsu012381 for ; Tue, 05 May 2009 08:46:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ600J00GW3WA00@fe-sfbay-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 05 May 2009 08:46:28 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ600LKXH5D4XF0@fe-sfbay-10.sun.com>; Tue, 05 May 2009 08:46:27 -0700 (PDT) Date: Tue, 05 May 2009 08:46:25 -0700 From: "Garrett D'Amore" Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <4A005B16.1000805@sun.com> Sender: Garrett.Damore@sun.com To: Michal Bachorik - Sun Microsystems - Prague Czech Republic Cc: Seth Goldberg , Dale Ghent , Michael Kearney , lsarc-ext@sun.com Message-id: <4A005F51.1020805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> <49F2139F.6060706@sun.com> <49F63FF9.5040401@sun.com> <4A005B16.1000805@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7478 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@opensolaris.org >>>> >>>> >>> >> > From Michal.Bachorik@sun.com Wed May 6 10:08:12 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46H8CwB025026 for ; Wed, 6 May 2009 10:08:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n46H88LT035131 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 6 May 2009 11:08:12 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ80012TFLLNG00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 06 May 2009 10:08:09 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ800FRWFL70A60@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 06 May 2009 10:08:07 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n46H7tI0006031 for ; Wed, 06 May 2009 17:07:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ800M00F8YJX00@fe-emea-10.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 06 May 2009 18:07:55 +0100 (BST) Received: from [129.157.19.102] ([unknown] [129.157.19.102]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ800GKFFL6UMC0@fe-emea-10.sun.com>; Wed, 06 May 2009 18:07:55 +0100 (BST) Date: Wed, 06 May 2009 19:07:47 +0200 From: Michal Bachorik Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <4A005F51.1020805@sun.com> Sender: Michal.Bachorik@sun.com To: "Garrett D'Amore" Cc: Seth Goldberg , Dale Ghent , Michael Kearney , LSARC-ext@sun.com Message-id: <4A01C3E3.7020702@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> <49F2139F.6060706@sun.com> <49F63FF9.5040401@sun.com> <4A005B16.1000805@sun.com> <4A005F51.1020805@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 8185 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@opensolaris.org >>>>> >>>>> >>>> >>> >> > > From gdamore@Sun.COM Wed May 6 10:28:32 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46HSVKb025528 for ; Wed, 6 May 2009 10:28:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n46HRtdL004188 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 6 May 2009 18:28:30 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ80046XGJG1O00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 06 May 2009 10:28:28 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ8001GVGJFET30@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 06 May 2009 10:28:27 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n46HSROb003217 for ; Wed, 06 May 2009 10:28:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ800D00GFSJ500@fe-sfbay-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 06 May 2009 10:28:27 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ800DCSGJ9RF80@fe-sfbay-09.sun.com>; Wed, 06 May 2009 10:28:22 -0700 (PDT) Date: Wed, 06 May 2009 10:28:20 -0700 From: "Garrett D'Amore" Subject: Re: FreeIPMI [LSARC/2009/245 Self Review] In-reply-to: <4A01C3E3.7020702@sun.com> Sender: Garrett.Damore@Sun.COM To: Michal Bachorik Cc: Seth Goldberg , Dale Ghent , Michael Kearney , LSARC-ext@Sun.COM Message-id: <4A01C8B4.5020309@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200904172049.n3HKnpSC014090@sac.sfbay.sun.com> <49EC4309.2080201@Sun.COM> <49EC7E14.40305@sun.com> <49EC82E8.8010701@Sun.COM> <49ECCC06.9080208@sun.com> <49ECD033.2000804@sun.com> <49F1E103.2000108@sun.com> <49F1E576.5040305@sun.com> <49F2077A.2070604@sun.com> <49F209ED.6090902@sun.com> <49F20EB4.2020104@sun.com> <49F2139F.6060706@sun.com> <49F63FF9.5040401@sun.com> <4A005B16.1000805@sun.com> <4A005F51.1020805@sun.com> <4A01C3E3.7020702@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 8670 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@opensolaris.org >>>>>> >>>>>> >>>>> >>>> >>> >> >> > > From Michael.Kearney@Sun.COM Wed May 6 11:25:15 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46IPEiE028859 for ; Wed, 6 May 2009 11:25:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n46IP8rq018562 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 7 May 2009 02:25:13 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ800B0DJ5ZFL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 06 May 2009 11:25:11 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ800E6SJ5XZVF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 06 May 2009 11:25:10 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n46IP9ap002414 for ; Wed, 06 May 2009 18:25:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ800I00ERVP600@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 06 May 2009 12:25:09 -0600 (MDT) Received: from [129.147.49.125] ([unknown] [129.147.49.125]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ8005XNJ5LWDC0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 06 May 2009 12:24:57 -0600 (MDT) Date: Wed, 06 May 2009 12:24:55 -0600 From: Michael Kearney Subject: FreeIPMI [LSARC/2009/245 Fast Track] Sender: Michael.Kearney@Sun.COM To: PSARC-ext@Sun.COM, Michal Bachorik - Sun Microsystems - Prague Czech Republic Message-id: <4A01D5F7.5030109@Sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_tgPudop02FP+VbdEFYUjhQ)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 1935 This is a multi-part message in MIME format. --Boundary_(ID_tgPudop02FP+VbdEFYUjhQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Status change from: waiting fast-track 05/08/2009
to: waiting need-opinion 05/08/2009
--
Michael Kearney
Staff Software Engineer

Sun Microsystems, Inc.
MS UBRM05-390, 500 Eldorado Blvd
Broomfield, CO 80021 US
Phone 303-272-2402
Fax 303-272-6554
Email Michael.Kearney@Sun.COM
--Boundary_(ID_tgPudop02FP+VbdEFYUjhQ) Content-type: text/x-vcard; name=Michael_Kearney.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Michael_Kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:Sun Microsystems, Inc.;Archive Core Engineering adr:500 Eldorado Blvd.;;Mailstop UBRM05-390;Broomfield;CO;80021;US email;internet:Michael.Kearney@Sun.com title:Staff Software Engineer tel;work:303-272-2402 tel;fax:303-272-6554 x-mozilla-html:TRUE url:http://www.sun.com/ version:2.1 end:vcard --Boundary_(ID_tgPudop02FP+VbdEFYUjhQ)-- From gdamore@sun.com Wed May 6 14:26:31 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46LQV1k001607 for ; Wed, 6 May 2009 14:26:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n46LQU9f053106 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 6 May 2009 15:26:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ80092LRK6IV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 06 May 2009 14:26:30 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ800KJOR6IEK70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 06 May 2009 14:18:18 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n46LIISl008940 for ; Wed, 06 May 2009 14:18:18 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ800100R2GFR00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 06 May 2009 14:18:18 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ800IU3R6H7EG0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 06 May 2009 14:18:17 -0700 (PDT) Date: Wed, 06 May 2009 14:18:17 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/245 FreeIPMI (opinion for review) Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <4A01FE99.3070901@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7530 Draft opinion follows. I've also stashed copies in the case directory. - Garrett sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: FreeIPMI Submitted by: Michal Bachorik File: PSARC/2009/245/opinion.ms Date: May 6th, 2009 Committee: Garrett D'Amore, Kais Belgaied, James D. Carlson, Richard Matthews, Darren Moffat, Sebastien Roy, and Glenn Skinner. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This case seeks to integrate the open source FreeIMPI tool, which is used with platforms conforming to the IPMI v1.5/2.0 specification. As such, it includes various tools to con- figure BMC and IPMI information, list information about BMC, manage/monitor a chassis, read FRU information, read/manage system event log records among other things. The project further includes the necessary libraries and header files for developing custom IPMI tools. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a minor release of the SFW consolidation. 3. Interfaces The project exports the following interfaces. _______________________________________________________________________ | Interfaces Exported | |______________________|________________|_____________________________| |Interface | Classification| Comments | |______________________|________________|_____________________________| |SUNWfreeipmr | Uncommitted | package | |SUNWfreeipmiu | Uncommitted | " | |ipmiconsole | Uncommitted | /var/log subdirectory | |______________________|________________|_____________________________| PSARC/2009/245 Copyright 2009 Sun Microsystems - 2 - _______________________________________________________________________ | Interfaces Exported | |______________________|________________|_____________________________| |Interface | Classification| Comments | |______________________|________________|_____________________________| |freeipmi | Uncommitted | " | |freeipmi | Uncommitted | /var/lib subdirectory | |ipmimonitoringsdrcache| Uncommitted | /var/cache subdirectory | |etc/logrotate.d | Committed | directory | |freeipmi | Uncommitted | /usr/include subdirectory | |freeipmi/spec | Uncommitted | " | |freeipmi/sdr-cache | Uncommitted | " | |freeipmi/locate | Uncommitted | " | |freeipmi/cmds | Uncommitted | " | |freeipmi/interface | Uncommitted | " | |freeipmi/fiid | Uncommitted | " | |freeipmi/api | Uncommitted | " | |freeipmi/util | Uncommitted | " | |freeipmi/record-format| Uncommitted | " | |freeipmi/debug | Uncommitted | " | |freeipmi/driver | Uncommitted | " | |freeipmi | Uncommitted | /usr/share/doc subdirectory| |freeipmi/info | Uncommitted | " | |libipmidetect | Uncommitted | library | |libipmiconsole | Uncommitted | " | |libfreeipmi | Uncommitted | " | |libipmimonitoring | Uncommitted | " | |bmc-info | Uncommitted | command | |bmc-config | Uncommitted | " | |bmc-watchdog | Uncommitted | " | |ipmi-chassis | Uncommitted | " | |ipmi-fru | Uncommitted | " | |ipmi-sel | Uncommitted | " | |ipmi-sensors | Uncommitted | " | |ipmipower | Uncommitted | " | |ipmiconsole | Uncommitted | " | |ipmimonitoring | Uncommitted | " | |ipmi-raw | Uncommitted | " | |ipmi-locate | Uncommitted | " | |pef-config | Uncommitted | " | |ipmi-chassis-config | Uncommitted | " | |ipmi-sensors-config | Uncommitted | " | |bmc-device | Uncommitted | " | |ipmiping | Uncommitted | " | |rmcpping | Uncommitted | " | |ipmi-oem | Uncommitted | " | |ipmidetect | Uncommitted | " | |ipmidetectd | Uncommitted | daemon | |______________________|________________|_____________________________| PSARC/2009/245 Copyright 2009 Sun Microsystems - 3 - The project imports the following interfaces. ____________________________________________ | Interfaces Imported | |__________|____________________|__________| |Interface | Classification | Comments| |__________|____________________|__________| |bmc_intf.h| Contracted Private| | |libgcrypt | Committed | | |__________|____________________|__________| 4. Opinion 4.1. Multiple IPMI frameworks During review, concerns about interactions between multiple IPMI frameworks (FreeIPMI and ipmitool) were raised. The project team indicated that no misbehavior had been found during testing. However, a member desired to make clear that we currently have an architecture of record for IPMI, and that is ipmi- tool (PSARC 2004/453). Therefore, while this case is approved on the merits of "familiarity", future projects are advised to use ipmitool when IPMI services are needed. 5. Minority Opinion(s) None. 6. Advisory Information Future projects wishing to use IPMI services are advised to use ipmitool (PSARC 2004/453) as that is the Solaris archi- tecture of record. If a change to some other toolset (such as FreeIPMI) is desired, then a PSARC case should be brought forward to make such a change. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2009/245. PSARC/2009/245 Copyright 2009 Sun Microsystems - 4 - 1. One Pager. File: 20090417_michal.bachorik 2. Intelligent Platform Management Interface - IPMI x86 Case: PSARC/2004/453 PSARC/2009/245 Copyright 2009 Sun Microsystems