From tom.childers@sun.com Mon Aug 25 16:55:18 2008 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 m7PNtHcb029714 for ; Mon, 25 Aug 2008 16:55:17 -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 m7PNsuFl011643 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Aug 2008 07:55:16 +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 <0K660051ZL427T00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 16:55:14 -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 <0K66002URL3ZIXA0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 16:55:11 -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 m7PNtBeQ024352 for ; Mon, 25 Aug 2008 16:55:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6600M01L2GJV00@fe-sfbay-09.sun.com> (original mail from tom.childers@sun.com) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 16:55:11 -0700 (PDT) Received: from labnis-qfe4.SFBay.Sun.COM ([75.101.10.39]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6600IJ3L3F9L80@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 16:54:51 -0700 (PDT) Date: Mon, 25 Aug 2008 16:54:40 -0700 From: Tom Childers Subject: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] Sender: Thomas.Childers@sun.com To: lsarc-ext@sun.com Cc: Gary Lengyel Message-id: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: multipart/alternative; boundary="Boundary_(ID_+pW11S4Hagb64lTnjnEmsA)" X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2392 --Boundary_(ID_+pW11S4Hagb64lTnjnEmsA) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Please read the one-pager first. The one-pager is at http://sac.eng/Archives/CaseLog/arc/LSARC/2008/547/20080825_gary.lengyal , and the materials/guidelines document is at http://sac.eng/Archives/CaseLog/arc/LSARC/2008/547/materials/serviceability-guidelines-1.0.html There is also a StarOffice version in the materials directory. -tdc Tom Childers Sr. Staff Engineer Sun Microsystems, Inc. SOA/Business Integration Engineering Phone x31943/+1 415-226-3398 Mobile +1 415-272-3565 Fax +1 415-226-3398 Email Tom.Childers@Sun.COM --Boundary_(ID_+pW11S4Hagb64lTnjnEmsA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE Please read the one-pager f= irst.

The one-pager is at htt= p://sac.eng/Archives/CaseLog/arc/LSARC/2008/547/20080825_gary.lengyal= , and the materials/guidelines document is at http://sac.eng/Archives/CaseLog/arc/LSARC/20= 08/547/materials/serviceability-guidelines-1.0.html

There is also a StarOffice version in the materials directory.&= nbsp;

-tdc

Tom Childers
Sr. Staff Engineer

Sun Microsystems, Inc.
= SOA/Business Integration Engineering
Phone x31943/+1 415-226-3398=
Mobile +1 415-272-3565
Fax +1 415-226-3398
Email Tom.Childers@Sun.COM

--Boundary_(ID_+pW11S4Hagb64lTnjnEmsA)-- From tom.childers@sun.com Mon Aug 25 16:58:36 2008 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 m7PNwZFF029899 for ; Mon, 25 Aug 2008 16:58: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 m7PNwQBP023798 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Aug 2008 00:58:34 +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 <0K6600G09L9LWZ00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 16:58:33 -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 <0K6600FC3L9K3130@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 16:58:32 -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 m7PNwVel018465 for ; Mon, 25 Aug 2008 16:58:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6600C01KX83T00@fe-sfbay-10.sun.com> (original mail from tom.childers@sun.com) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 16:58:31 -0700 (PDT) Received: from labnis-qfe4.SFBay.Sun.COM ([75.101.10.39]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6600GY5L9E0O80@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 16:58:26 -0700 (PDT) Date: Mon, 25 Aug 2008 16:58:15 -0700 From: Tom Childers Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> Sender: Thomas.Childers@sun.com To: lsarc-ext@sun.com Cc: Gary Lengyel Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: multipart/alternative; boundary="Boundary_(ID_plT/LIxpIJewn8xqA/TE5g)" X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> Status: RO Content-Length: 24855 --Boundary_(ID_plT/LIxpIJewn8xqA/TE5g) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT My apologies, I just sent out links to documents that cannot be accessed outside of Sun. The documents are attached. Tom Childers Sr. Staff Engineer Sun Microsystems, Inc. SOA/Business Integration Engineering Phone x31943/+1 415-226-3398 Mobile +1 415-272-3565 Fax +1 415-226-3398 Email Tom.Childers@Sun.COM --Boundary_(ID_plT/LIxpIJewn8xqA/TE5g) Content-type: multipart/mixed; boundary="Boundary_(ID_bAXiMczdDI0KKuGzW4gu+Q)" --Boundary_(ID_bAXiMczdDI0KKuGzW4gu+Q) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE My apologies, I just sent o= ut links to documents that cannot be accessed outside of Sun. The doc= uments are attached.

Tom Childers
Sr. Staf= f Engineer

Sun Microsystems, Inc.
SOA/Business In= tegration Engineering
Phone x31943/+1 415-226-3398
Mobile +1 = 415-272-3565
Fax +1 415-226-3398
Email Tom.Childers@Sun.COM

--Boundary_(ID_bAXiMczdDI0KKuGzW4gu+Q) Content-type: text/plain; name="S12y guidelines one-pager.txt"; x-unix-mode=0644 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename="S12y guidelines one-pager.txt" Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: OpenARC Serviceability Guidelines 1.2. Name of Document Author/Supplier: Tom Childers and Gary Lengyel 1.3. Date of This Document: August 5, 2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: OpenSolaris ARC 1.4.2. The ARC(s) you expect to review your project: OpenSolaris ARC 1.5. Email Aliases: 1.5.2. Responsible Engineer: gary.lengyel@sun.com 1.5.4. Interest List: tom.childers@sun.com 2. Project Summary 2.1. Project Description: This project establishes a set of guidelines for improving software "serviceability", based on extensive experience by the Serviceability Engineering organization at Sun. 2.2. Risks and Assumptions: None known. 3. Business Summary 3.1. Problem Area: Open source software products (and indeed all software) tend to have product-specific procedures, interfaces and mechanisms for installation, configuration, uninstallation, logging, tracing, and in general, diagnosing problems. This makes it very difficult for customers to identify and solve configuration, behavior and performance issues. 3.2. Market/Requester: Sun Serviceability Engineering 3.3. Business Justification: Certain software capabilities (for example, an uninstaller that completely removes a product) make it much easier to use and administer software products. By identifying the qualities and characteristics that make a product "serviceable", these guidelines can help open source developers create products that are more desirable and easier to manage over the life of the product. 3.4. Competitive Analysis: There is no direct competition for this effort, however portions of other open source projects are improving software serviceability. For example, GlassFish OpenInstaller and Update Center help address serviceability issues. The Open Solutions Alliance, http://www.opensolutionsalliance.org, is addressing some of these issues with a completely different approach. 3.5. Opportunity Window/Exposure: Adoption of these guidelines should improve open source software serviceability characteristics over the next several years. 3.6. How will you know when you are done?: This effort will be complete when a set of serviceability guidelines are incorporated into the ARC Best Practices on the OpenSolaris ARC web site. 4. Technical Description: 4.1. Details: Some years ago, Sun defined "Serviceability" as the measure of how easy it is to service a product. A serviceable product is: easy to install and upgrade easy to configure easy to run and keep running easy to figure out what is wrong when a problem occurs Over the last decade, Sun Serviceability Engineering has built up a database of hundreds of "Product Serviceability Requirements", and used these requirements to perform serviceability evaluations of Sun software and hardware products. An evaluation delivers a "scorecard" showing strengths and weaknesses, plus a cost model for ongoing support and sustaining effort. Internally, these evaluations have enabled Sun to improve the installation, configuration, "diagnosability", and administrative qualities of a large variety of products, including Solaris, Glassfish, Directory Server, Netbeans, and many others. This set of guidelines are a simple, qualitative description of the set of software product features that, according to Sun's experience, make the products easier to use and administer, and less expensive to own and maintain, over the lifecycle of the product. In the future, we may be able to take advantage of Serviceability evaluations to simplify the ARC process and perhaps create an open- source equivalent of the Sun Serviceability Evaluation. 4.2. Bug/RFE Number(s): N/A 4.3. In Scope: Establishment of guidelines for OpenSolaris ARC 4.4. Out of Scope: Changes to the existing ARC process to take advantage of these guidelines, or establishment of any process or review board to enforce these guidelines. 4.5. Interfaces: None. 4.6. Doc Impact: None. 4.7. Admin/Config Impact: Adoption of these guidelines will encourage more consistent installation and configuration practices, and support of Connected Services and use of Glassfish OpenInstaller and UpdateCenter and equivalent products. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: N/A 4.10. Packaging & Delivery: N/A 4.11. Security Impact: N/A 4.12. Dependencies: N/A 5. Reference Documents: Serviceability Guidelines, submitted as ARC case materials. 6. Resources and Schedule: 6.1. Projected Availability: Guidelines are immediately available for review. 6.2. Cost of Effort: No further cost. Approximately 8 staff-days went into the preparation of this material. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: N/A 6.4.7. Target RTI Date/Release: N/A 6.4.8. Target Code Design Review Date: N/A 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: Part of OpenSolaris 7. Prototype Availability: 7.1. Prototype Availability: 7.2. Prototype Cost: --Boundary_(ID_bAXiMczdDI0KKuGzW4gu+Q) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

--Boundary_(ID_bAXiMczdDI0KKuGzW4gu+Q) Content-type: text/html; name=serviceability-guidelines-1.0.html; x-mac-type=4E4F2546; x-unix-mode=0644 Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: attachment; filename=serviceability-guidelines-1.0.html =09 =09 =09 =09 =09 =09 =09 =09

Serviceability Guidelines for Software Development

Gary Lengyel, Sun Microsystems, Inc.

Version 1.0, August 25, 2008

This paper presents an overview of the serviceability guidelines for open-source software products reviewed by the Open Architecture Review Committee(s). The guidelines are outlined in five major areas:

Product =09Installation and Removal
=09
Product =09Configuration and Verification
=09
Problem =09Management
=09
Problem =09Logging and Recording =09
=09
Documentation =09and Troubleshooting Support
=09

Also provided is a section for Solaris-specific products.

Product Installation and Removal

These guidelines ensure an installation will work, will have an audit trail, and that the correct product distribution kit is installed. The uninstaller guidelines ensure that the system can be restored to its state prior to product installation.

Support =09for automated patching and updating of products shall be =09implemented.
=09
The =09installer should verify operating system dependencies before =09installing the product.
=09
The =09installer should verify the existence of any dependent and/or =09required software versions before installing the product. For =09example, a Java product may require that a specific or minimum =09version of the Java virtual machine or developer kit (JVM or JDK) = is =09already installed, or a product may require the presence of a =09specific registry or database.
=09
Installation =09procedures shall log all user input. =09
=09
Installation =09procedures shall verify that the product installation (or upgrade = or =09patch) has been completed successfully.
=09
The =09names of all files in the product installation package shall follo= w =09the standard format for the associated platform, include the =09platform name and a unique version identifier for product, upgrade= , =09or patch.
=09
An =09uninstaller will be included with each product installation. =09
=09
The =09uninstaller shall only remove those files installed or generated b= y =09the product, and shall remove all knowledge of the product from th= e =09system. This includes any registry entries, configuration files, =09and directories, as well as product binaries, archives and =09libraries. =09
=09
The =09uninstaller shall provide the means to either keep or discard any =09end-user or configuration data associated with the installation. F= or =09example, user names, passwords, deployment descriptors, generated =09source code, development repositories, and network identifiers =09should all be optionally preserved when a product is uninstalled.<= /SPAN>
=09
The =09uninstaller shall verify that the product has been successfully =09removed from the system. =09
=09
A =09log entry shall be made to record the completion status following =09the installation or removal of an upgrade, patch, rollback, or the =09product itself. The log entries shall include the unique version =09identifier for the installed product, patch or upgrade.

Product Configuration and Verification

These guidelines ensure that any changes made to user-configurable settings cannot negatively impact the product and that the product will run as expected by verifying the attributes and integrity of the products files.

The =09product shall attempt to validate and ensure that any configuratio= n =09changes made by the user are valid. =09
=09
Any =09range limits used by the product shall not be hard-coded (outside = of =09values such as MAXINT). This allows service provider personnel to =09modify settings such as time-out values to assist in diagnosis. =09
=09
Settings =09and configuration inconsistencies that may result in illegal =09configurations shall be reported via system messaging facilities. = =09
=09
The =09product shall provide a means to check and validate the ownership =09and protection of its files. Configuration files that contain =09sensitive information (such as user names and passwords) shall be =09protected from read or write access by any other user except the =09owner of the product installation.
=09
The =09product shall verify that any required daemons are started at =09product startup.
=09
The =09product shall ensure that no files exist that can prevent the =09product from running (i.e., lock files, temporary files, etc.)

Problem Management

These guidelines ensure th= at a diagnostician can easily locate the source of a problem.

The =09product shall be able to capture the state of the product on deman= d =09as well as during a fatal error
=09
The =09product shall validate internal and external parameters to functio= n =09and method calls.
=09
The =09product shall detect and report if utilized resources (for example= , =09memory and disk space) are being depleted, along with =09recommendations as to what should be done.
=09
The =09product shall provide consistent logging mechanisms, message =09formats, log files, and log file locations.

Problem Logging and Recording

These guidelines ensure that the required information needed to diagnose a problem is available:

Each =09log file should contain the unique name and version and patch =09identifier for the product.
=09
Log =09file sizes shall be user-configurable
=09
Logs =09shall archive entries when its maximum file size is exceed to make =09room for new entries
=09
The =09product shall record all error events in persistent storage and =09shall conform to the system standard (for example, Java products =09should utilize JSR 47 logging interfaces).
=09
The =09product shall log all configuration changes, and shall include the =09following information:
=09
Setting =09name
=09
New =09value
=09
Previous =09value
=09
Timestamp
=09
Name =09and version of the change agent
=09
=09
The =09product shall terminate (throttle) the reporting and logging of =09correctable errors for a fixed period of time when high frequency = of =09such errors occur. Error throttling period values shall be field =09adjustable.
=09
The =09product shall include the following information every log entry:
=09
Timestamp =09- preferably in a standard format (RFC 3339 or similar) =09
=09
Module =09- Acronym of the module generating the message =09
=09
LogLevel =09=E2=80=93 Indicates =09relative severity, following an applicable standard if any.=
=09
MessageId =09- Unique within the product =09
=09
MessageText =09- brief text message explaining the message =09
=09
ContextInfo =09- key values that go with the message (context). Include stack tra= ce =09if program error is suspected.

Documen= tation and Troubleshooting Support

These guidelines present the documentation required by a service provider to aid in the diagnosis and verification of product functionality. Such documentation needed by any service provider include:

Test =09plans
=09
Tested =09configurations list
=09
Data =09scrubbing procedures
=09
Re-certification =09procedures
=09
Troubleshooting =09guide
=09
Error =09code list
=09
List =09of TCP/IP ports used by products
=09
Minimum =09OS configuration list

In addition, access to all documentation (specifications, architecture documents, design, source code, debug and rebuild) is required.

Solaris Specific Guidelines

This section presents guidelines to be used by the Solaris Operating System and/or those products designed to execute on Solaris.

Any =09products for installation on Solaris shall use the Service =09Management Facility (SMF) to ensure correct daemon startup and =09management.
=09
DTrace =09probes shall be utilized to promote ease of diagnosis and =09traceability.
=09
Product =09events (errors) shall utilize the Solaris Fault Manager for =09reporting and diagnosis.
=09
Implementation =09of the Image Packaging System (once completed and available) shall =09be used for the installation of software packages

--Boundary_(ID_bAXiMczdDI0KKuGzW4gu+Q) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

--Boundary_(ID_bAXiMczdDI0KKuGzW4gu+Q)-- --Boundary_(ID_plT/LIxpIJewn8xqA/TE5g)-- From Alan.Coopersmith@sun.com Mon Aug 25 18:12:06 2008 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 m7Q1C6Fn003023 for ; Mon, 25 Aug 2008 18:12:06 -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 m7Q1C3QM051503 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 25 Aug 2008 19:12:06 -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 <0K6600K03OO5EU00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 18:12:05 -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 <0K6600FOJOO53480@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 18:12:05 -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 m7Q1C5Uj023806 for ; Mon, 25 Aug 2008 18:12:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6600N01OG15000@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 18:12:05 -0700 (PDT) Received: from [10.6.102.118] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K66001OXOO4EEE0@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 25 Aug 2008 18:12:04 -0700 (PDT) Date: Mon, 25 Aug 2008 18:12:04 -0700 From: Alan Coopersmith Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: Sender: Alan.Coopersmith@sun.com To: Tom Childers Cc: lsarc-ext@sun.com, Gary Lengyel Message-id: <48B35864.10802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 3209 Tom Childers wrote: > My apologies, I just sent out links to documents that cannot be accessed > outside of Sun. The documents are attached. Materials in open cases on sac.eng get mirrored out to the ARC community on opensolaris.org automatically - it just takes a while (usually within a day unless it breaks - ask Plocher for details). > * Support for automated patching and updating of products shall be > implemented. > * The installer should verify operating system dependencies before > installing the product. > * The installer should verify the existence of any dependent and/or > required software versions before installing the product. [...] > * Installation procedures shall verify that the product installation > (or upgrade or patch) has been completed successfully. So these would all be satisfied by just delivering IPS packages right? > * Installation procedures shall log all user input. except for sensitive data like passwords, surely. > * An uninstaller will be included with each product installation. Is this necessary for products installed via a packaging system? Wouldn't just a list of packages to remove via rpm/ips/pkgrm suffice in most cases? > * The product shall provide a means to check and validate the > ownership and protection of its files. Configuration files that > contain sensitive information (such as user names and passwords) > shall be protected from read or write access by any other user > except the owner of the product installation. Are pkg verify (IPS) & pkgchk considered sufficient for products installed as packages? > * The product shall ensure that no files exist that can prevent the > product from running (i.e., lock files, temporary files, etc.) What does this mean - products can't have lock files or other files that would ever stop them from running? Or that they need to make sure those files are all removed at some given time? (If so, when?) > * The product shall validate internal and external parameters to > function and method calls. Given the size of the ARC case for just getting printf() to check for NULL pointers, I imagine it would take decades to do this for even a small portion of the Solaris libraries. (On the other hand, having a rule recorded that says we need to do this would reduce the arguing in such ARC cases.) > * The product shall detect and report if utilized resources (for > example, memory and disk space) are being depleted, along with > recommendations as to what should be done. Every program on the system needs to implement it's own memory leak checker? > * Product events (errors) shall utilize the Solaris Fault Manager > for reporting and diagnosis. Isn't FMA only for hardware faults, not software errors? (Certainly I've never seen anything to suggest most of the software I work on should use FMA, or even could - if this is intended to be wider spread, much more documentation, sample code, and advocacy is needed to get the word out.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Mon Aug 25 18:13:37 2008 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 m7Q1DasV003069 for ; Mon, 25 Aug 2008 18:13:36 -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 m7Q1DaoI051877 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Mon, 25 Aug 2008 19:13:36 -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 <0K6600H01OQOLB00@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Mon, 25 Aug 2008 19:13:36 -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 <0K6600CR9OQNIV20@brm-avmta-1.central.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Mon, 25 Aug 2008 19:13:35 -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 m7Q1DZZL023903 for ; Mon, 25 Aug 2008 18:13:35 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6600J01OONP200@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for psarc-members@sun.com (ORCPT psarc-members@sun.com); Mon, 25 Aug 2008 18:13:35 -0700 (PDT) Received: from [10.6.102.118] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6600MLEOQMA3D0@fe-sfbay-10.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Mon, 25 Aug 2008 18:13:34 -0700 (PDT) Date: Mon, 25 Aug 2008 18:13:34 -0700 From: Alan Coopersmith Subject: [Fwd: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008]] Sender: Alan.Coopersmith@Sun.COM To: psarc-members@Sun.COM Cc: Tom Childers Message-id: <48B358BE.9000209@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1057 For those on PSARC who don't monitor the LSARC or OpenSolaris-ARC mailing lists, you might want to check out this case, since much of it applies to software delivered via PSARC too. -alan- -------- Original Message -------- Subject: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] Date: Mon, 25 Aug 2008 16:54:40 -0700 From: Tom Childers To: lsarc-ext@sun.com CC: Gary Lengyel Please read the one-pager first. The one-pager is at http://sac.eng/Archives/CaseLog/arc/LSARC/2008/547/20080825_gary.lengyal, and the materials/guidelines document is at http://sac.eng/Archives/CaseLog/arc/LSARC/2008/547/materials/serviceability-guidelines-1.0.html There is also a StarOffice version in the materials directory. -tdc * Tom Childers * Sr. Staff Engineer *Sun Microsystems, Inc.* SOA/Business Integration Engineering Phone x31943/+1 415-226-3398 Mobile +1 415-272-3565 Fax +1 415-226-3398 Email Tom.Childers@Sun.COM From Darren.Moffat@sun.com Tue Aug 26 08:01:18 2008 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 m7QF1Hc9022402 for ; Tue, 26 Aug 2008 08:01:17 -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 m7QF19jD004202 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Aug 2008 23:01:16 +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 <0K6700F1RR22KE00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 08:01:14 -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 <0K6700ANIR1Z7M90@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 08:01:11 -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 m7QF1Agn023551 for ; Tue, 26 Aug 2008 15:01:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700801QB6IK00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 16:01:10 +0100 (BST) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6700BTSR1R4EA0@fe-emea-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 16:01:04 +0100 (BST) Date: Tue, 26 Aug 2008 16:01:03 +0100 From: Darren J Moffat Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <48B35864.10802@sun.com> Sender: Darren.Moffat@sun.com To: Alan Coopersmith Cc: Tom Childers , Gary Lengyel , lsarc-ext@sun.com Message-id: <48B41AAF.4020904@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: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 547 Alan Coopersmith wrote: >> * Product events (errors) shall utilize the Solaris Fault Manager >> for reporting and diagnosis. > > Isn't FMA only for hardware faults, not software errors? (Certainly I've > never seen anything to suggest most of the software I work on should use FMA, > or even could - if this is intended to be wider spread, much more documentation, > sample code, and advocacy is needed to get the word out.) FMA is for software too. ZFS is software and it does quite a bit of FMA integration. -- Darren J Moffat From Gary.Lengyel@sun.com Tue Aug 26 08:33:45 2008 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 m7QFXiIu022765 for ; Tue, 26 Aug 2008 08:33:44 -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 m7QFXg7s020390 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Aug 2008 16:33:43 +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 <0K6700F0JSK59P00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 09:33:41 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6700A0DSK28J70@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 09:33:39 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7QFXc9p009418 for ; Tue, 26 Aug 2008 15:33:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700001SEW4T00@mail-amer.sun.com> (original mail from Gary.Lengyel@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 09:33:38 -0600 (MDT) Received: from macbook-3.local ([129.150.36.43]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6700BOLSK0RZC0@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 09:33:37 -0600 (MDT) Date: Tue, 26 Aug 2008 09:33:37 -0600 From: Gary Lengyel Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <48B35864.10802@sun.com> Sender: Gary.Lengyel@sun.com To: Alan Coopersmith Cc: Tom Childers , lsarc-ext@sun.com Message-id: <48B42251.5010409@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hyk7dZG3GCcp0X7D5IFCvA)" X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 12688 This is a multi-part message in MIME format. --Boundary_(ID_hyk7dZG3GCcp0X7D5IFCvA) Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT Thanks for the feedback Alan. Responses inline... gary Alan Coopersmith wrote: > Tom Childers wrote: > >> My apologies, I just sent out links to documents that cannot be accessed >> outside of Sun. The documents are attached. >> > > Materials in open cases on sac.eng get mirrored out to the ARC community on > opensolaris.org automatically - it just takes a while (usually within a day > unless it breaks - ask Plocher for details). > > > >> * Support for automated patching and updating of products shall be >> implemented. >> * The installer should verify operating system dependencies before >> installing the product. >> * The installer should verify the existence of any dependent and/or >> required software versions before installing the product. [...] >> * Installation procedures shall verify that the product installation >> (or upgrade or patch) has been completed successfully. >> > > So these would all be satisfied by just delivering IPS packages right? > For (Open)Solaris, yes. If a product has its own installer, then these points would have to be satisfied within that installer. > >> * Installation procedures shall log all user input. >> > > except for sensitive data like passwords, surely. > > Oh yes... >> * An uninstaller will be included with each product installation. >> > > Is this necessary for products installed via a packaging system? > Wouldn't just a list of packages to remove via rpm/ips/pkgrm suffice in > most cases? > You are correct. As with a product with its own installer, then it would have to provide its own uninstaller. > > >> * The product shall provide a means to check and validate the >> ownership and protection of its files. Configuration files that >> contain sensitive information (such as user names and passwords) >> shall be protected from read or write access by any other user >> except the owner of the product installation. >> > > Are pkg verify (IPS) & pkgchk considered sufficient for products installed > as packages? > Yes. > >> * The product shall ensure that no files exist that can prevent the >> product from running (i.e., lock files, temporary files, etc.) >> > > What does this mean - products can't have lock files or other files that > would ever stop them from running? Or that they need to make sure those > files are all removed at some given time? (If so, when?) > The latter. Take Mozilla and Firefox for example. There are times when the process(es) stop running, and a lock file is left open. You cannot restart the application. You have to know that its execution is being prevented because a lock file exists (Joe user may not know that and has to log a service desk call). This is intended to prevent that scenario. When? Application startup. > > >> * The product shall validate internal and external parameters to >> function and method calls. >> > > Given the size of the ARC case for just getting printf() to check for > NULL pointers, I imagine it would take decades to do this for even a > small portion of the Solaris libraries. (On the other hand, having a > rule recorded that says we need to do this would reduce the arguing in > such ARC cases.) > I realize there are pros and cons to this. The intent is to help backline support and Sustaining in localizing problems. Validation could also introduce performance issues. We have to determine when/where this is done. Obviously not on functions and methods that are called many times a second. > >> * The product shall detect and report if utilized resources (for >> example, memory and disk space) are being depleted, along with >> recommendations as to what should be done. >> > > Every program on the system needs to implement it's own memory leak checker? > That would be nice....probably very unreasonable and improbable to do however. To reduce the number of service calls related to performance, we'd like to notify the customer if an application is utilizing/is responsible for the consumption of disk/memory before the system performance is degraded to the point the system appears hung. In other words, "Am I the application causing this?". Make sense? > >> * Product events (errors) shall utilize the Solaris Fault Manager >> for reporting and diagnosis. >> > > Isn't FMA only for hardware faults, not software errors? (Certainly I've > never seen anything to suggest most of the software I work on should use FMA, > or even could - if this is intended to be wider spread, much more documentation, > sample code, and advocacy is needed to get the word out.) > > As Darren pointed out, no. ZFS and even FMA itself uses it. SMF uses the message scheme. -- /Gary Lengyel/ /Sr. Staff Engineer, Software Architect/ /Serviceability Engineering/ /Service Delivery Enablement, Global Customer Services/ /877-522-2081, x51952/ --Boundary_(ID_hyk7dZG3GCcp0X7D5IFCvA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 7BIT Thanks for the feedback Alan. Responses inline... gary

Alan Coopersmith wrote:

Tom Childers wrote:

My apologies, I just sent out links to documents that cannot be accessed
outside of Sun. The documents are attached.


Materials in open cases on sac.eng get mirrored out to the ARC community on
opensolaris.org automatically - it just takes a while (usually within a day
unless it breaks - ask Plocher for details).

    * Support for automated patching and updating of products shall be
      implemented.
    * The installer should verify operating system dependencies before
      installing the product.
    * The installer should verify the existence of any dependent and/or
      required software versions before installing the product. [...]
    * Installation procedures shall verify that the product installation
      (or upgrade or patch) has been completed successfully.


So these would all be satisfied by just delivering IPS packages right?

For (Open)Solaris, yes. If a product has its own installer, then these points would have to be satisfied within
that installer.

    * Installation procedures shall log all user input.


except for sensitive data like passwords, surely.

Oh yes...

    * An uninstaller will be included with each product installation.


Is this necessary for products installed via a packaging system?
Wouldn't just a list of packages to remove via rpm/ips/pkgrm suffice in
most cases?

You are correct. As with a product with its own installer, then it would have to provide its own uninstaller.

   *  The product shall provide a means to check and validate the
      ownership and protection of its files. Configuration files that
      contain sensitive information (such as user names and passwords)
      shall be protected from read or write access by any other user
      except the owner of the product installation.


Are pkg verify (IPS) & pkgchk considered sufficient for products installed
as packages?

Yes.

   *  The product shall ensure that no files exist that can prevent the
      product from running (i.e., lock files, temporary files, etc.)


What does this mean - products can't have lock files or other files that
would ever stop them from running?   Or that they need to make sure those
files are all removed at some given time?  (If so, when?)

The latter. Take Mozilla and Firefox for example. There are times when the process(es) stop running, and a lock
file is left open. You cannot restart the application. You have to know that its execution is being prevented
because a lock file exists (Joe user may not know that and has to log a service desk call). This is intended to
prevent that scenario.

When? Application startup.

    *  The product shall validate internal and external parameters to
      function and method calls.


Given the size of the ARC case for just getting printf() to check for
NULL pointers, I imagine it would take decades to do this for even a
small portion of the Solaris libraries.   (On the other hand, having a
rule recorded that says we need to do this would reduce the arguing in
such ARC cases.)

I realize there are pros and cons to this. The intent is to help backline support and Sustaining in localizing
problems. Validation could also introduce performance issues. We have to determine when/where this is
done. Obviously not on functions and methods that are called many times a second.

    * The product shall detect and report if utilized resources (for
      example, memory and disk space) are being depleted, along with
      recommendations as to what should be done.


Every program on the system needs to implement it's own memory leak checker?

That would be nice....probably very unreasonable and improbable to do however. To reduce the number of service
calls related to performance, we'd like to notify the customer if an application is utilizing/is responsible for the
consumption of disk/memory before the system performance is degraded to the point the system appears hung.
In other words, "Am I the application causing this?". Make sense?

    * Product events (errors) shall utilize the Solaris Fault Manager
      for reporting and diagnosis.


Isn't FMA only for hardware faults, not software errors?   (Certainly I've
never seen anything to suggest most of the software I work on should use FMA,
or even could - if this is intended to be wider spread, much more documentation,
sample code, and advocacy is needed to get the word out.)

As Darren pointed out, no. ZFS and even FMA itself uses it. SMF uses the message scheme.

Gary Lengyel

Sr. Staff Engineer, Software Architect

Serviceability Engineering

Service Delivery Enablement, Global Customer Services

877-522-2081, x51952

--Boundary_(ID_hyk7dZG3GCcp0X7D5IFCvA)-- From John.Fischer@Sun.COM Tue Aug 26 09:40:38 2008 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 m7QGebGr026274 for ; Tue, 26 Aug 2008 09:40:38 -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 m7QGeVsX009633 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Aug 2008 00:40:36 +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 <0K6700J0PVNMTB00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:40:34 -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 <0K6700AFRVNL8UD0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:40:33 -0600 (MDT) 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 m7QGeXAN023540 for ; Tue, 26 Aug 2008 16:40:33 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700D01V73AK00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:40:33 -0600 (MDT) Received: from 129.145.154.66 ([129.145.154.66]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6700LMTVNAGV30@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:40:25 -0600 (MDT) Date: Tue, 26 Aug 2008 09:40:22 -0700 From: John Fischer Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <48B42251.5010409@Sun.COM> Sender: John.Fischer@Sun.COM To: Gary Lengyel Cc: John Fischer , Alan Coopersmith , Tom Childers , lsarc-ext@Sun.COM Reply-to: John.Fischer@Sun.COM Message-id: <1219768819.9503.209.camel@sr1-umpk-16> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> Status: RO Content-Length: 1913 Gary, To me the guidelines are overly general for a best practice. The problem with them being overly general then the project teams will have to fight with the committees to allow an exception. Or worse the project teams will be hesitant to come to the committees to get a review because they do not adhere to this general policy. The Mozilla/Firefox example is a very good one. The lock file that you are pointing out is designed to do exactly what it is doing. It is attempting to prevent multiple copies of the tool from running. If the tool exits normally then the lock file is removed. However, if the tool is still running and the same profile is being using then it should not start another instance of itself. However, the way that the guideline is written: > * The product shall ensure that no files exist that can prevent the > product from running (i.e., lock files, temporary files, etc.) It does not allow for such a situation. Thus no lock file or temporary file could prevent another instance of a product from running. Thanks, John On Tue, 2008-08-26 at 08:33, Gary Lengyel wrote: > > > * The product shall ensure that no files exist that can prevent the > > > product from running (i.e., lock files, temporary files, etc.) > > > > > What does this mean - products can't have lock files or other files that > > would ever stop them from running? Or that they need to make sure those > > files are all removed at some given time? (If so, when?) > > > The latter. Take Mozilla and Firefox for example. There are times when > the process(es) stop running, and a lock > file is left open. You cannot restart the application. You have to > know that its execution is being prevented > because a lock file exists (Joe user may not know that and has to log > a service desk call). This is intended to > prevent that scenario. > > When? Application startup. From John.Plocher@sun.com Tue Aug 26 09:59:06 2008 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 m7QGx6jI028842 for ; Tue, 26 Aug 2008 09:59:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7QGx2dX005138 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Aug 2008 09:59:05 -0700 (PDT) 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 <0K6700K1ZWIGYT00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:59:04 -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 <0K6700KJEWIFNQ00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:59:04 -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 m7QGx3ow007373 for ; Tue, 26 Aug 2008 09:59:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700B01WHOZL00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 09:59:03 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6700LO9WIFO060@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 09:59:03 -0700 (PDT) Date: Tue, 26 Aug 2008 09:58:59 -0700 From: John Plocher Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <1219768819.9503.209.camel@sr1-umpk-16> Sender: John.Plocher@sun.com To: John.Fischer@sun.com Cc: Gary Lengyel , Tom Childers , Alan Coopersmith , lsarc-ext@sun.com Message-id: <48B43653.50802@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: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 1096 John Fischer wrote: > The Mozilla/Firefox example is a very good one. The lock file > that you are pointing out is designed to do exactly what it > is doing. It is attempting to prevent multiple copies of the > tool from running. It is exactly the right example to use. The "Mozilla Failure" is a Denial of Service one - if Mozilla crashes (which it does, sometimes frequently), the lockfile is not removed, and then new instances won't start - even though there is no other instance to guard against. If the lock file handling was "smarter", it would notice that the lock file was stale and invalid, and allow the user to override it. This is the "problem with lock files" that the guideline is trying to address - not the fact that there are lockfiles in the first place. The Mozilla problem is so bad that IT/OPS has a GNOME menu item on all its corporate desktop installs to "remove Mozilla lockfiles". It did this because the support call volume was huge - hundreds of service tickets daily saying "I can't start a browser!" all root caused to a brain dead lockfile scheme. -John From John.Fischer@sun.com Tue Aug 26 10:05:46 2008 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 m7QH5jL6029320 for ; Tue, 26 Aug 2008 10:05:45 -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 m7QH5eYm020159 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Aug 2008 01:05:44 +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 <0K6700L0PWTKGB00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 11:05:44 -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 <0K6700KBQWTJNG00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 11:05:44 -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 m7QH5hfn007091 for ; Tue, 26 Aug 2008 17:05:43 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700601WGWYP00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 11:05:43 -0600 (MDT) Received: from 129.145.154.66 ([129.145.154.66]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6700BYHWSXUD80@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 11:05:23 -0600 (MDT) Date: Tue, 26 Aug 2008 10:05:21 -0700 From: John Fischer Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <48B43653.50802@Sun.Com> Sender: John.Fischer@sun.com To: John Plocher Cc: Gary Lengyel , Tom Childers , Alan Coopersmith , lsarc-ext@sun.com Reply-to: John.Fischer@sun.com Message-id: <1219770320.9503.237.camel@sr1-umpk-16> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> Status: RO Content-Length: 645 John, Then rewrite the guideline to say something about correcting left over lock files and not lockfiles in general. This is my problem with the guideline. It is overly general. Again, the guideline states: > * The product shall ensure that no files exist that can prevent the > product from running (i.e., lock files, temporary files, etc.) i.e., do not use lock files or temporary files to prevent the product from running. Thanks, John On Tue, 2008-08-26 at 09:58, John Plocher wrote: > This is the "problem with lock files" that the guideline is trying to > address - not the fact that there are lockfiles in the first place. From John.Plocher@sun.com Tue Aug 26 10:31:08 2008 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 m7QHV86B029922 for ; Tue, 26 Aug 2008 10:31:08 -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 m7QHV6RQ016196 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Aug 2008 11:31:08 -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 <0K6700007XZW1J00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 11:31:08 -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 <0K6700K7EXZVNR30@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 11:31:07 -0600 (MDT) 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 m7QHV7qv012242 for ; Tue, 26 Aug 2008 10:31:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700C01XP6G900@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:31:07 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K67000JPXZRRP00@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:31:03 -0700 (PDT) Date: Tue, 26 Aug 2008 10:30:59 -0700 From: John Plocher Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <1219770320.9503.237.camel@sr1-umpk-16> Sender: John.Plocher@sun.com To: John.Fischer@sun.com Cc: Gary Lengyel , Tom Childers , Alan Coopersmith , lsarc-ext@sun.com Message-id: <48B43DD3.3050308@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: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> <1219770320.9503.237.camel@sr1-umpk-16> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 1263 John Fischer wrote: > John, > > Then rewrite the guideline to say something about correcting > left over lock files and not lockfiles in general. This is > my problem with the guideline. It is overly general. This is intended to be a best practice, and not a policy. As such, it reflects the current best understanding of an area where guidance is needed. Don't forget, good guidance is often overly general by intent, simply because it needs to apply to a very diverse set of applications. > Again, the guideline states: > >> * The product shall ensure that no files exist that can prevent the >> product from running (i.e., lock files, temporary files, etc.) > > i.e., do not use lock files or temporary files to prevent > the product from running. Using lockfiles to validly prevent an application from running when it shouldn't is not the focus here - which should be obvious from the context of the "how to best service things that are broken" document itself. Tom/Gary: In order to prevent future misunderstandings like this, please change the guideline above to read The product shall ensure that no files exist that can improperly prevent the product from running (i.e., stale lock files, temporary files, etc.) -John From tom.childers@Sun.COM Tue Aug 26 10:33:53 2008 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 m7QHXqQ3029978 for ; Tue, 26 Aug 2008 10:33:53 -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 m7QHXjZA015462 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 26 Aug 2008 18:33:52 +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 <0K670000NY4F8A00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 11:33:51 -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 <0K6700KEOY4ENR30@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 11:33:50 -0600 (MDT) 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 m7QHXnEJ012585 for ; Tue, 26 Aug 2008 10:33:49 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6700M01XXADO00@fe-sfbay-09.sun.com> (original mail from tom.childers@sun.com) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:33:49 -0700 (PDT) Received: from [192.168.15.2] ([75.101.10.233]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K670000CY45RP20@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 26 Aug 2008 10:33:49 -0700 (PDT) Date: Tue, 26 Aug 2008 10:33:33 -0700 From: Tom Childers Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <48B43DD3.3050308@Sun.Com> Sender: Thomas.Childers@Sun.COM To: Gary Lengyel Cc: lsarc-ext@Sun.COM Message-id: <5D4E39F0-72E8-478D-8DD4-1668CC0709F2@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> <1219770320.9503.237.camel@sr1-umpk-16> <48B43DD3.3050308@Sun.Com> Status: RO Content-Length: 1679 Gary, this seems like a good tweak. Also during our LSARC meeting this morning, John F. suggested changing the word "shall" to "should" throughout the guidelines. These are not requirements, and the wording *should* be spacious :-) Can you please make these two changes and send me an update, for reposting? Thanks, -tdc On Aug 26, 2008, at 10:30 AM, John Plocher wrote: > John Fischer wrote: >> John, >> Then rewrite the guideline to say something about correcting >> left over lock files and not lockfiles in general. This is >> my problem with the guideline. It is overly general. > > This is intended to be a best practice, and not a policy. As such, > it reflects the current best understanding of an area where guidance > is needed. Don't forget, good guidance is often overly general by > intent, simply because it needs to apply to a very diverse set of > applications. > >> Again, the guideline states: >>> * The product shall ensure that no files exist that can prevent the >>> product from running (i.e., lock files, temporary files, etc.) >> i.e., do not use lock files or temporary files to prevent >> the product from running. > > Using lockfiles to validly prevent an application from running when > it shouldn't is not the focus here - which should be obvious from the > context of the "how to best service things that are broken" document > itself. > > Tom/Gary: In order to prevent future misunderstandings like > this, please change the guideline above to read > > The product shall ensure that no files exist that can > improperly prevent the product from running (i.e., stale > lock files, temporary files, etc.) > > -John From tom.childers@sun.com Tue Aug 26 12:12:28 2008 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 m7QJCRwZ004069 for ; Tue, 26 Aug 2008 12:12:28 -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 m7QJBktc025989; Tue, 26 Aug 2008 20:12:26 +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 <0K680010T2OPZZ00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 12:12:25 -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 <0K6800L1D2OO1LA0@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 12:12:24 -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 m7QJCOdT026431; Tue, 26 Aug 2008 12:12:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K680070114HX200@fe-sfbay-09.sun.com> (original mail from tom.childers@sun.com); Tue, 26 Aug 2008 12:12:24 -0700 (PDT) Received: from labnis-qfe4.SFBay.Sun.COM ([75.101.10.233]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6800CJZ2NVUWF0@fe-sfbay-09.sun.com>; Tue, 26 Aug 2008 12:11:55 -0700 (PDT) Date: Tue, 26 Aug 2008 12:11:47 -0700 From: Tom Childers Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <5D4E39F0-72E8-478D-8DD4-1668CC0709F2@sun.com> Sender: Thomas.Childers@sun.com To: lsarc-ext@sun.com Cc: Gary Lengyel Message-id: <24CB063E-C9E2-4FD0-9403-D8F59F1FEDD7@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: multipart/mixed; boundary="Boundary_(ID_fmnGgYgzEraXqZA7lmQeiA)" X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> <1219770320.9503.237.camel@sr1-umpk-16> <48B43DD3.3050308@Sun.Com> <5D4E39F0-72E8-478D-8DD4-1668CC0709F2@sun.com> Status: RO Content-Length: 17411 --Boundary_(ID_fmnGgYgzEraXqZA7lmQeiA) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT Here is an updated version of the guidelines document for this case, incorporating the feedback so far. The doc is available at http://www.opensolaris.org/os/community/arc/caselog/2008/547/ , and the new versions should propagate to the opensolaris.org web page soon. -tdc --Boundary_(ID_fmnGgYgzEraXqZA7lmQeiA) Content-type: text/html; name=serviceability-guidelines-1.1.html; x-mac-type=4E4F2546; x-unix-mode=0644 Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: attachment; filename=serviceability-guidelines-1.1.html =09 =09 =09 =09 =09 =09 =09 =09

Serviceability Guidelines for Software Development

Gary Lengyel, Sun Microsystems, Inc.

Version 1.1, August 26, 2008

Product =09Installation and Removal
=09
Product =09Configuration and Verification
=09
Problem =09Management
=09
Problem =09Logging and Recording =09
=09
Documentation =09and Troubleshooting Support
=09

Also provided is a section for Solaris-specific products.

Product Installation and Removal

Support =09for automated patching and updating of products should be =09implemented.
=09
The =09installer should verify operating system dependencies before =09installing the product.
=09
The =09installer should verify the existence of any dependent and/or =09required software versions before installing the product. For =09example, a Java product may require that a specific or minimum =09version of the Java virtual machine or developer kit (JVM or JDK) = is =09already installed, or a product may require the presence of a =09specific registry or database.
=09
Installation =09procedures should log all user input (with the exception of =09sensitive data such as passwords).
=09
Installation =09procedures should verify that the product installation (or upgrade =09or patch) has been completed successfully.
=09
The =09names of all files in the product installation package should foll= ow =09the standard format for the associated platform, include the =09platform name and a unique version identifier for product, upgrade= , =09or patch.
=09
An =09uninstaller should be included with each product installation. =09
=09
The =09uninstaller should only remove those files installed or generated = by =09the product, and should remove all knowledge of the product from t= he =09system. This includes any registry entries, configuration files, =09and directories, as well as product binaries, archives and =09libraries. =09
=09
The =09uninstaller should provide the means to either keep or discard any =09end-user or configuration data associated with the installation. F= or =09example, user names, passwords, deployment descriptors, generated =09source code, development repositories, and network identifiers =09should all be optionally preserved when a product is uninstalled.<= /SPAN>
=09
The =09uninstaller should verify that the product has been successfully =09removed from the system. =09
=09
A =09log entry should be made to record the completion status following =09the installation or removal of an upgrade, patch, rollback, or the =09product itself. The log entries should include the unique version =09identifier for the installed product, patch or upgrade.

Product Configuration and Verification

The =09product should attempt to validate and ensure that any configurati= on =09changes made by the user are valid. =09
=09
Any =09range limits used by the product should not be hard-coded (outside =09of values such as MAXINT). This allows service provider personnel = to =09modify settings such as time-out values to assist in diagnosis. =09
=09
Settings =09and configuration inconsistencies that may result in illegal =09configurations should be reported via system messaging facilities.= =09
=09
The =09product should provide a means to check and validate the ownership =09and protection of its files. Configuration files that contain =09sensitive information (such as user names and passwords) should be =09protected from read or write access by any other user except the =09owner of the product installation.
=09
The =09product should verify that any required daemons are started at =09product startup.
=09
The =09product should ensure that no files exist that can improperly =09prevent the product from running (i.e., stale lock files, temporar= y =09files, etc.)

Problem Management

These guidelines ensure th= at a diagnostician can easily locate the source of a problem.

The =09product should be able to capture the state of the product on dema= nd =09as well as during a fatal error
=09
The =09product should validate internal and external parameters to functi= on =09and method calls.
=09
The =09product should detect and report if utilized resources (for exampl= e, =09memory and disk space) are being depleted, along with =09recommendations as to what should be done.
=09
The =09product should provide consistent logging mechanisms, message =09formats, log files, and log file locations.

Problem Logging and Recording

These guidelines ensure that the required information needed to diagnose a problem is available:

Each =09log file should contain the unique name and version and patch =09identifier for the product.
=09
Log =09file sizes should be user-configurable
=09
Logs =09should archive entries when its maximum file size is exceed to mak= e =09room for new entries
=09
The =09product should record all error events in persistent storage and =09should conform to the system standard (for example, Java products =09should utilize JSR 47 logging interfaces).
=09
The =09product should log all configuration changes, and should include t= he =09following information:
=09
Setting =09name
=09
New =09value
=09
Previous =09value
=09
Timestamp
=09
Name =09and version of the change agent
=09
=09
The =09product should terminate (throttle) the reporting and logging of =09correctable errors for a fixed period of time when high frequency = of =09such errors occur. Error throttling period values should be field =09adjustable.
=09
The =09product should include the following information in every log entr= y:
=09
Timestamp =09- preferably in a standard format (RFC 3339 or similar) =09
=09
Module =09- Acronym of the module generating the message =09
=09
LogLevel =09=E2=80=93 Indicates =09relative severity, following an applicable standard if any.=
=09
MessageId =09- Unique within the product =09
=09
MessageText =09- brief text message explaining the message =09
=09
ContextInfo =09- key values that go with the message (context). Include stack tra= ce =09if program error is suspected.

Documen= tation and Troubleshooting Support

These guidelines present the documentation required by a service provider to aid in the diagnosis and verification of product functionality. Such documentation needed by any service provider include:

Test =09plans
=09
Tested =09configurations list
=09
Data =09scrubbing procedures
=09
Re-certification =09procedures
=09
Troubleshooting =09guide
=09
Error =09code list
=09
List =09of TCP/IP ports used by products
=09
Minimum =09OS configuration list

In addition, access to all documentation (specifications, architecture documents, design, source code, debug and rebuild) is required.

Solaris Specific Guidelines

This section presents guidelines to be used by the Solaris Operating System and/or those products designed to execute on Solaris.

Any =09products for installation on Solaris should use the Service =09Management Facility (SMF) to ensure correct daemon startup and =09management.
=09
DTrace =09probes should be utilized to promote ease of diagnosis and =09traceability.
=09
Product =09events (errors) should utilize the Solaris Fault Manager for =09reporting and diagnosis.
=09
Implementation =09of the Image Packaging System (once completed and available) shoul= d =09be used for the installation of software packages

Serviceability Guidelines for Software Development

Gary Lengyel, Sun Microsystems, Inc.

Version 1.1, August 26, 2008

Product =09Installation and Removal
=09
Product =09Configuration and Verification
=09
Problem =09Management
=09
Problem =09Logging and Recording =09
=09
Documentation =09and Troubleshooting Support
=09

Also provided is a section for Solaris-specific products.

Product Installation and Removal

Support =09for automated patching and updating of products should be =09implemented.
=09
The =09installer should verify operating system dependencies before =09installing the product.
=09
The =09installer should verify the existence of any dependent and/or =09required software versions before installing the product. For =09example, a Java product may require that a specific or minimum =09version of the Java virtual machine or developer kit (JVM or JDK) = is =09already installed, or a product may require the presence of a =09specific registry or database.
=09
Installation =09procedures should log all user input (with the exception of =09sensitive data such as passwords).
=09
Installation =09procedures should verify that the product installation (or upgrade =09or patch) has been completed successfully.
=09
The =09names of all files in the product installation package should foll= ow =09the standard format for the associated platform, include the =09platform name and a unique version identifier for product, upgrade= , =09or patch.
=09
An =09uninstaller should be included with each product installation. =09
=09
The =09uninstaller should only remove those files installed or generated = by =09the product, and should remove all knowledge of the product from t= he =09system. This includes any registry entries, configuration files, =09and directories, as well as product binaries, archives and =09libraries. =09
=09
The =09uninstaller should provide the means to either keep or discard any =09end-user or configuration data associated with the installation. F= or =09example, user names, passwords, deployment descriptors, generated =09source code, development repositories, and network identifiers =09should all be optionally preserved when a product is uninstalled.<= /SPAN>
=09
The =09uninstaller should verify that the product has been successfully =09removed from the system. =09
=09
A =09log entry should be made to record the completion status following =09the installation or removal of an upgrade, patch, rollback, or the =09product itself. The log entries should include the unique version =09identifier for the installed product, patch or upgrade.

Product Configuration and Verification

The =09product should attempt to validate and ensure that any configurati= on =09changes made by the user are valid. =09
=09
Any =09range limits used by the product should not be hard-coded (outside =09of values such as MAXINT). This allows service provider personnel = to =09modify settings such as time-out values to assist in diagnosis. =09
=09
Settings =09and configuration inconsistencies that may result in illegal =09configurations should be reported via system messaging facilities.= =09
=09
The =09product should provide a means to check and validate the ownership =09and protection of its files. Configuration files that contain =09sensitive information (such as user names and passwords) should be =09protected from read or write access by any other user except the =09owner of the product installation.
=09
The =09product should verify that any required daemons are started at =09product startup.
=09
The =09product should ensure that no files exist that can improperly =09prevent the product from running (i.e., stale lock files, temporar= y =09files, etc.)

Problem Management

These guidelines ensure th= at a diagnostician can easily locate the source of a problem.

The =09product should be able to capture the state of the product on dema= nd =09as well as during a fatal error
=09
The =09product should validate internal and external parameters to functi= on =09and method calls.
=09
The =09product should detect and report if utilized resources (for exampl= e, =09memory and disk space) are being depleted, along with =09recommendations as to what should be done.
=09
The =09product should provide consistent logging mechanisms, message =09formats, log files, and log file locations.

Problem Logging and Recording

These guidelines ensure that the required information needed to diagnose a problem is available:

Each =09log file should contain the unique name and version and patch =09identifier for the product.
=09
Log =09file sizes should be user-configurable
=09
Logs =09should archive entries when its maximum file size is exceed to mak= e =09room for new entries
=09
The =09product should record all error events in persistent storage and =09should conform to the system standard (for example, Java products =09should utilize JSR 47 logging interfaces).
=09
The =09product should log all configuration changes, and should include t= he =09following information:
=09
Setting =09name
=09
New =09value
=09
Previous =09value
=09
Timestamp
=09
Name =09and version of the change agent
=09
=09
The =09product should terminate (throttle) the reporting and logging of =09correctable errors for a fixed period of time when high frequency = of =09such errors occur. Error throttling period values should be field =09adjustable.
=09
The =09product should include the following information in every log entr= y:
=09
Timestamp =09- preferably in a standard format (RFC 3339 or similar) =09
=09
Module =09- Acronym of the module generating the message =09
=09
LogLevel =09=E2=80=93 Indicates =09relative severity, following an applicable standard if any.=
=09
MessageId =09- Unique within the product =09
=09
MessageText =09- brief text message explaining the message =09
=09
ContextInfo =09- key values that go with the message (context). Include stack tra= ce =09if program error is suspected.

Documen= tation and Troubleshooting Support

These guidelines present the documentation required by a service provider to aid in the diagnosis and verification of product functionality. Such documentation needed by any service provider include:

Test =09plans
=09
Tested =09configurations list
=09
Data =09scrubbing procedures
=09
Re-certification =09procedures
=09
Troubleshooting =09guide
=09
Error =09code list
=09
List =09of TCP/IP ports used by products
=09
Minimum =09OS configuration list

In addition, access to all documentation (specifications, architecture documents, design, source code, debug and rebuild) is required.

Solaris Specific Guidelines

This section presents guidelines to be used by the Solaris Operating System and/or those products designed to execute on Solaris.

Any =09products for installation on Solaris should use the Service =09Management Facility (SMF) to ensure correct daemon startup and =09management.
=09
DTrace =09probes should be utilized to promote ease of diagnosis and =09traceability.
=09
Product =09events (errors) should utilize the Solaris Fault Manager for =09reporting and diagnosis.
=09
Implementation =09of the Image Packaging System (once completed and available) shoul= d =09be used for the installation of software packages

--Boundary_(ID_fmnGgYgzEraXqZA7lmQeiA) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT --Boundary_(ID_fmnGgYgzEraXqZA7lmQeiA)-- From John.Fischer@sun.com Wed Aug 27 10:27:57 2008 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 m7RHRuhE015400 for ; Wed, 27 Aug 2008 10:27:57 -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 m7RHRtSP017804 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Aug 2008 18:27:56 +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 <0K6900C0FSIIK200@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 11:27:54 -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 <0K6900M2PSIHV3E0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 11:27:53 -0600 (MDT) 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 m7RHRrWJ018239 for ; Wed, 27 Aug 2008 17:27:53 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6900E01RL7XS00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 11:27:53 -0600 (MDT) Received: from 129.145.154.66 ([129.145.154.66]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6900A8LSIEE200@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 11:27:51 -0600 (MDT) Date: Wed, 27 Aug 2008 10:27:50 -0700 From: John Fischer Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <24CB063E-C9E2-4FD0-9403-D8F59F1FEDD7@sun.com> Sender: John.Fischer@sun.com To: Tom Childers Cc: John Fischer , lsarc-ext@sun.com, Gary Lengyel Reply-to: John.Fischer@sun.com Message-id: <1219858069.51279.166.camel@sr1-umpk-16> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> <1219770320.9503.237.camel@sr1-umpk-16> <48B43DD3.3050308@Sun.Com> <5D4E39F0-72E8-478D-8DD4-1668CC0709F2@sun.com> <24CB063E-C9E2-4FD0-9403-D8F59F1FEDD7@sun.com> Status: RO Content-Length: 578 Tom, Yesterday during LSARC you stated something about the intent of these guidelines were not necessarily at FOSS projects. Is that correct? If so then perhaps a short preamble is required for the guidelines. Thanks, John On Tue, 2008-08-26 at 12:11, Tom Childers wrote: > Here is an updated version of the guidelines document for this case, > incorporating the feedback so far. > > The doc is available at http://www.opensolaris.org/os/community/arc/caselog/2008/547/ > , and the new versions should propagate to the opensolaris.org web > page soon. > -tdc > > From Bill.Walker@Sun.COM Wed Aug 27 10:45:14 2008 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 m7RHjEBc015648 for ; Wed, 27 Aug 2008 10:45:14 -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 m7RHjEVW010773 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Aug 2008 10:45:14 -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 <0K6900707TBE1Y00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 10:45:14 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6900DMSTBD3BB0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 10:45:14 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m7RHjDEW014353 for ; Wed, 27 Aug 2008 17:45:13 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6900E01RL7XS00@mail-amer.sun.com> (original mail from Bill.Walker@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 11:45:13 -0600 (MDT) Received: from [127.0.0.1] ([129.150.35.171]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K69009NVTB55NA0@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 11:45:08 -0600 (MDT) Date: Wed, 27 Aug 2008 13:45:05 -0400 From: Bill Walker Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <1219858069.51279.166.camel@sr1-umpk-16> Sender: Bill.Walker@Sun.COM To: John.Fischer@Sun.COM Cc: Tom Childers , lsarc-ext@Sun.COM, Gary Lengyel Message-id: <48B592A1.9070400@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: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> <1219770320.9503.237.camel@sr1-umpk-16> <48B43DD3.3050308@Sun.Com> <5D4E39F0-72E8-478D-8DD4-1668CC0709F2@sun.com> <24CB063E-C9E2-4FD0-9403-D8F59F1FEDD7@sun.com> <1219858069.51279.166.camel@sr1-umpk-16> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 SeaMonkey/1.1.11 Status: RO Content-Length: 901 Though we should somehow express that we consider these "good practices" that we would welcome (or at least leave the door open for) FOSS folks to learn from or debate as well. So while we might not strictly require others to follow, we are happy to lead. bill. John Fischer wrote: > Tom, > > Yesterday during LSARC you stated something about the > intent of these guidelines were not necessarily at > FOSS projects. Is that correct? If so then perhaps > a short preamble is required for the guidelines. > > Thanks, > > John > > On Tue, 2008-08-26 at 12:11, Tom Childers wrote: >> Here is an updated version of the guidelines document for this case, >> incorporating the feedback so far. >> >> The doc is available at http://www.opensolaris.org/os/community/arc/caselog/2008/547/ >> , and the new versions should propagate to the opensolaris.org web >> page soon. >> -tdc >> >> > From tom.childers@sun.com Wed Aug 27 12:39:13 2008 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 m7RJdCKF020476 for ; Wed, 27 Aug 2008 12:39:13 -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 m7RJd17E010204 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 27 Aug 2008 20:39:11 +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 <0K6900L05YLBVG00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 13:39:11 -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 <0K6900DCAYLAKZ90@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 13:39:10 -0600 (MDT) 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 m7RJdAco012687 for ; Wed, 27 Aug 2008 12:39:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6900A01YH9AN00@fe-sfbay-09.sun.com> (original mail from tom.childers@sun.com) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 12:39:09 -0700 (PDT) Received: from [192.168.15.2] ([75.101.10.233]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K69003KYYKU9P20@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Aug 2008 12:39:02 -0700 (PDT) Date: Wed, 27 Aug 2008 12:38:42 -0700 From: Tom Childers Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: <48B592A1.9070400@Sun.COM> Sender: Thomas.Childers@sun.com To: Bill Walker , John Fischer Cc: lsarc-ext@sun.com, Gary Lengyel Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> <1219770320.9503.237.camel@sr1-umpk-16> <48B43DD3.3050308@Sun.Com> <5D4E39F0-72E8-478D-8DD4-1668CC0709F2@sun.com> <24CB063E-C9E2-4FD0-9403-D8F59F1FEDD7@sun.com> <1219858069.51279.166.camel@sr1-umpk-16> <48B592A1.9070400@Sun.COM> Status: RO Content-Length: 1223 Gary and I are intending these guidelines for the FOSS community, and would certainly like to provide a feedback mechanism. That's why it's an open case. If there is a way we can do this beyond the OpenARC process, I'd like to know. -tdc On Aug 27, 2008, at 10:45 AM, Bill Walker wrote: > > Though we should somehow express that we consider these "good > practices" that we would welcome (or at least leave the door open > for) FOSS folks to learn from or debate as well. So while we might > not strictly require others to follow, we are happy to lead. > > bill. > > > John Fischer wrote: >> Tom, >> Yesterday during LSARC you stated something about the intent of >> these guidelines were not necessarily at >> FOSS projects. Is that correct? If so then perhaps >> a short preamble is required for the guidelines. >> Thanks, >> John >> On Tue, 2008-08-26 at 12:11, Tom Childers wrote: >>> Here is an updated version of the guidelines document for this >>> case, incorporating the feedback so far. >>> >>> The doc is available at http://www.opensolaris.org/os/community/arc/caselog/2008/547/ >>> , and the new versions should propagate to the opensolaris.org >>> web page soon. >>> -tdc >>> >>> > From tom.childers@sun.com Tue Sep 2 21:07:09 2008 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 m83478Kh001171 for ; Tue, 2 Sep 2008 21:07:08 -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 m83477C3024418; Wed, 3 Sep 2008 12:07:07 +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 <0K6L00205Q3UN800@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Sep 2008 21:07:06 -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 <0K6L00MYOQ3UCO80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Sep 2008 21:07:06 -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 m83475qI006862; Tue, 02 Sep 2008 21:07:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6L00401PYUNV00@fe-sfbay-10.sun.com> (original mail from tom.childers@sun.com); Tue, 02 Sep 2008 21:07:05 -0700 (PDT) Received: from [192.168.15.2] ([75.101.10.233]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6L004QCQ3LMJB0@fe-sfbay-10.sun.com>; Tue, 02 Sep 2008 21:07:05 -0700 (PDT) Date: Tue, 02 Sep 2008 21:06:45 -0700 From: Tom Childers Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: Sender: Thomas.Childers@sun.com To: lsarc-ext@sun.com Cc: Bill Walker , Gary Lengyel Message-id: <71C736BC-BE55-4CD7-A3A3-D5EFAC82053B@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> <1219770320.9503.237.camel@sr1-umpk-16> <48B43DD3.3050308@Sun.Com> <5D4E39F0-72E8-478D-8DD4-1668CC0709F2@sun.com> <24CB063E-C9E2-4FD0-9403-D8F59F1FEDD7@sun.com> <1219858069.51279.166.camel@sr1-umpk-16> <48B592A1.9070400@Sun.COM> Status: RO Content-Length: 1680 The timer has expired, and this case is approved. When we add it to the web site, we will add some introductory info to encourage feedback and discussion, as Boll Walker suggested. I will follow up with ARC infrastructure folks to add it to our guidelines. Tom Childers Sr. Staff Engineer Sun Microsystems, Inc. SOA/Business Integration Engineering On Aug 27, 2008, at 12:38 PM, Tom Childers wrote: > Gary and I are intending these guidelines for the FOSS community, > and would certainly like to provide a feedback mechanism. That's why > it's an open case. If there is a way we can do this beyond the > OpenARC process, I'd like to know. > > -tdc > > On Aug 27, 2008, at 10:45 AM, Bill Walker wrote: > >> >> Though we should somehow express that we consider these "good >> practices" that we would welcome (or at least leave the door open >> for) FOSS folks to learn from or debate as well. So while we might >> not strictly require others to follow, we are happy to lead. >> >> bill. >> >> >> John Fischer wrote: >>> Tom, >>> Yesterday during LSARC you stated something about the intent of >>> these guidelines were not necessarily at >>> FOSS projects. Is that correct? If so then perhaps >>> a short preamble is required for the guidelines. >>> Thanks, >>> John >>> On Tue, 2008-08-26 at 12:11, Tom Childers wrote: >>>> Here is an updated version of the guidelines document for this >>>> case, incorporating the feedback so far. >>>> >>>> The doc is available at http://www.opensolaris.org/os/community/arc/caselog/2008/547/ >>>> , and the new versions should propagate to the opensolaris.org >>>> web page soon. >>>> -tdc >>>> >>>> >> > From sacadmin Tue Sep 2 21:07:10 2008 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 m83479L7001196 for ; Tue, 2 Sep 2008 21:07:10 -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 m83477C3024418; Wed, 3 Sep 2008 12:07:07 +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 <0K6L00205Q3UN800@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Sep 2008 21:07:06 -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 <0K6L00MYOQ3UCO80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Sep 2008 21:07:06 -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 m83475qI006862; Tue, 02 Sep 2008 21:07:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6L00401PYUNV00@fe-sfbay-10.sun.com> (original mail from tom.childers@sun.com); Tue, 02 Sep 2008 21:07:05 -0700 (PDT) Received: from [192.168.15.2] ([75.101.10.233]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6L004QCQ3LMJB0@fe-sfbay-10.sun.com>; Tue, 02 Sep 2008 21:07:05 -0700 (PDT) Date: Tue, 02 Sep 2008 21:06:45 -0700 From: Tom Childers Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: Sender: Thomas.Childers@sun.com To: lsarc-ext@sun.com Cc: Bill Walker , Gary Lengyel Message-id: <71C736BC-BE55-4CD7-A3A3-D5EFAC82053B@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> <1219770320.9503.237.camel@sr1-umpk-16> <48B43DD3.3050308@Sun.Com> <5D4E39F0-72E8-478D-8DD4-1668CC0709F2@sun.com> <24CB063E-C9E2-4FD0-9403-D8F59F1FEDD7@sun.com> <1219858069.51279.166.camel@sr1-umpk-16> <48B592A1.9070400@Sun.COM> Status: RO Content-Length: 1680 The timer has expired, and this case is approved. When we add it to the web site, we will add some introductory info to encourage feedback and discussion, as Boll Walker suggested. I will follow up with ARC infrastructure folks to add it to our guidelines. Tom Childers Sr. Staff Engineer Sun Microsystems, Inc. SOA/Business Integration Engineering On Aug 27, 2008, at 12:38 PM, Tom Childers wrote: > Gary and I are intending these guidelines for the FOSS community, > and would certainly like to provide a feedback mechanism. That's why > it's an open case. If there is a way we can do this beyond the > OpenARC process, I'd like to know. > > -tdc > > On Aug 27, 2008, at 10:45 AM, Bill Walker wrote: > >> >> Though we should somehow express that we consider these "good >> practices" that we would welcome (or at least leave the door open >> for) FOSS folks to learn from or debate as well. So while we might >> not strictly require others to follow, we are happy to lead. >> >> bill. >> >> >> John Fischer wrote: >>> Tom, >>> Yesterday during LSARC you stated something about the intent of >>> these guidelines were not necessarily at >>> FOSS projects. Is that correct? If so then perhaps >>> a short preamble is required for the guidelines. >>> Thanks, >>> John >>> On Tue, 2008-08-26 at 12:11, Tom Childers wrote: >>>> Here is an updated version of the guidelines document for this >>>> case, incorporating the feedback so far. >>>> >>>> The doc is available at http://www.opensolaris.org/os/community/arc/caselog/2008/547/ >>>> , and the new versions should propagate to the opensolaris.org >>>> web page soon. >>>> -tdc >>>> >>>> >> > From owner-sac-advocates Tue Sep 2 21:07:11 2008 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 m83478Kj001171 for ; Tue, 2 Sep 2008 21:07:11 -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 m83477C3024418; Wed, 3 Sep 2008 12:07:07 +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 <0K6L00205Q3UN800@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Sep 2008 21:07:06 -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 <0K6L00MYOQ3UCO80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Sep 2008 21:07:06 -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 m83475qI006862; Tue, 02 Sep 2008 21:07:05 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6L00401PYUNV00@fe-sfbay-10.sun.com> (original mail from tom.childers@sun.com); Tue, 02 Sep 2008 21:07:05 -0700 (PDT) Received: from [192.168.15.2] ([75.101.10.233]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6L004QCQ3LMJB0@fe-sfbay-10.sun.com>; Tue, 02 Sep 2008 21:07:05 -0700 (PDT) Date: Tue, 02 Sep 2008 21:06:45 -0700 From: Tom Childers Subject: Re: OpenARC Serviceability Guidelines [LSARC/2008/547 FastTrack timeout 09/02/2008] In-reply-to: Sender: Thomas.Childers@sun.com To: lsarc-ext@sun.com Cc: Bill Walker , Gary Lengyel Message-id: <71C736BC-BE55-4CD7-A3A3-D5EFAC82053B@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.928.1) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <205F655E-11BA-403D-996B-3F3469623FFD@sun.com> <48B35864.10802@sun.com> <48B42251.5010409@Sun.COM> <1219768819.9503.209.camel@sr1-umpk-16> <48B43653.50802@Sun.Com> <1219770320.9503.237.camel@sr1-umpk-16> <48B43DD3.3050308@Sun.Com> <5D4E39F0-72E8-478D-8DD4-1668CC0709F2@sun.com> <24CB063E-C9E2-4FD0-9403-D8F59F1FEDD7@sun.com> <1219858069.51279.166.camel@sr1-umpk-16> <48B592A1.9070400@Sun.COM> Status: RO Content-Length: 1680 The timer has expired, and this case is approved. When we add it to the web site, we will add some introductory info to encourage feedback and discussion, as Boll Walker suggested. I will follow up with ARC infrastructure folks to add it to our guidelines. Tom Childers Sr. Staff Engineer Sun Microsystems, Inc. SOA/Business Integration Engineering On Aug 27, 2008, at 12:38 PM, Tom Childers wrote: > Gary and I are intending these guidelines for the FOSS community, > and would certainly like to provide a feedback mechanism. That's why > it's an open case. If there is a way we can do this beyond the > OpenARC process, I'd like to know. > > -tdc > > On Aug 27, 2008, at 10:45 AM, Bill Walker wrote: > >> >> Though we should somehow express that we consider these "good >> practices" that we would welcome (or at least leave the door open >> for) FOSS folks to learn from or debate as well. So while we might >> not strictly require others to follow, we are happy to lead. >> >> bill. >> >> >> John Fischer wrote: >>> Tom, >>> Yesterday during LSARC you stated something about the intent of >>> these guidelines were not necessarily at >>> FOSS projects. Is that correct? If so then perhaps >>> a short preamble is required for the guidelines. >>> Thanks, >>> John >>> On Tue, 2008-08-26 at 12:11, Tom Childers wrote: >>>> Here is an updated version of the guidelines document for this >>>> case, incorporating the feedback so far. >>>> >>>> The doc is available at http://www.opensolaris.org/os/community/arc/caselog/2008/547/ >>>> , and the new versions should propagate to the opensolaris.org >>>> web page soon. >>>> -tdc >>>> >>>> >> >