@(#) LSARC Questions Version 2.0u @(#)LSARC 1.30 07/12/07 __________________________________________________________________ Copyright 2007 Sun Microsystems, Inc. 0. Remind us: 0.1 The case number for this project? LSARC 2008/040 0.2 This questionnaire is for an [x] Inception Review or [ ] Commitment Review 0.3 Name(s) of person(s) answering the questions? Gary Horton 0.4 Are these case materials considered public or confidential? Public 1. What specifically is the proposal that we are reviewing? See Functional Spec, section 1 1.2 Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", "micro" or "patch" change and why? (See the release type definitions in http://sac.eng.sun.com/BestPractices/release_taxonomy.html ) See Functional Spec, section 1.3 2. What is the motivation for it? What are the expected benefits for Sun? By what criteria will you judge its success? See Functional Spec, section 1.2 3. The plan: 3.1 Who (what groups in what business units) are working on it? See Functional Spec, section 1.4.1 3.2 What is the current status? Porting of the source from OpenPegasus is underway. Configuration and testing issues around SSL, PAM and SLP are under discussion between the project team and key players in the OpenPegasus community. Discussions with owners of SMC and the existing WBEM services are underway regarding reconfiguration of port usage in those products so that OpenPegasus can own the WBEM standard ports (5988 and 5989). An OpenSolaris project site has been established, and inbound/outbound Open Source Reviews are almost completed. 3.3 Has a design review been done? N/A - this is not a development effort per se 3.4 What Product Approval Committee (PAC) do you expect to approve this project? Solaris PAC 4. Related Projects: 4.1 What not-yet-delivered Sun projects (libraries, hardware, etc.) does this project depend upon (i.e., need to be successful)? None 4.2 What non-Sun projects does this project depend upon? None 4.3 What other projects depend on this one? None 4.4 What other active projects at Sun are related to your project, and how are they related? Comstar will be using SMI-S as as standard management interface that will be hosted by Pegasus. 4.5 What future projects should be started or avoided to help your project succeed, and why? Existing clients and providers should be retooled to interoperate with the OpenPegasus CIMOM. The existing WBEM services product should then be EOL'd. These steps will reinforce OpenPegasus as the implementation of choice for Sun's WBEM strategy. 4.6 What open source communities does this project interact with? The OpenPegasus community, an Open Group project: http://openpegasus.org 5. What technical approach has been selected by the project? The central effort has no "new development" effort, it is simply a port of existing source code from the OpenPegasus project to execute on Solaris x86 and SPARC platforms. The approach as such is largely a compile-and-test with the addition of platform definitions to the codebase supporting Solaris x86 and SPARC. Peripheral efforts include minor modifications to the existing SMC codebase to reconfigure that project's port usage, configuration of access control with RBAC, and process control configuration using SMF. 6. How is the project delivered into the system? Is it bundled or unbundled? The CIMOM will be bundled into Nevada. What are your delivery vehicles (WOS, CTEAM...) Standard Solaris packaging Identify package abbreviations, directory names, library names, databases, etc. See Functional Specification, Section 3 7. Hardware Platform Dependencies: 7.1 What are the project's hardware platform dependencies, including Sun or third-party add-on hardware that is explicitly supported. The target platforms are 32-bit and 64-bit Solaris on x86 and SPARC architectures. 7.2 Are Solaris components expected to work on SPARC and x86? If not, why? What will be affected in porting? Any problems if porting to another architecture were desirable? Support for both SPARC and x86 is the primary goal of the overall project. New platform definitions will be introduced into the codebase to specify the compilation process. The same exercise would be needed to port to another architecture. 7.3 Are there issues with "binary" interfaces, which would be incompatible on various instruction set architectures? WBEM providers, i.e. software components that represent a managed resource, can be plugged in to the CIMOM to extend the overall capability. These providers are often available as binary downloads from the resource vendor, e.g. for managing the Qlogic HBA. When providers are written to the Common Manageability Programming Interface (CMPI), a standard maintained by the Open Group, there is no problem with binary compatibility; however, providers using the OpenPegasus C++ interface must be compiled with the same compiler as the CIMOM itself. An alternative does exist (CIMPLE - http://cimple.org) that provides for writing providers in C++ that are then binary compatible with the CMPI interface. 8. Compatibility and Interoperability (Consider a compatibility matrix, if the information is nontrivial.) 8.1S OS compatibility: 8.1.1 For Solaris components, what Solaris release(s) does it run on or work with? Nevada 8.1.2 Does it run on Linux? What distribution(s) and version(s)? Distributions of the OpenPegasus project are available for Linux; however, support for that OS is not in scope for this project. That said, a source RPM is available on the OpenPegasus web site that can be used to build binaries for most LSB-compliant RPM-based Linux distributions and versions. A "Supported Platforms" matrix for the latest release of OpenPegasus (http://www.openpegasus.org/pp/uploads/40/14933/ReleaseNotes.htm) includes the following OS/compiler combinations: zLinux/gcc, Linux Itanium/gcc, Linux IA-32/gcc (versions 2.9x, 3.xx, 4.xx), Linux X86_64/gcc (versions 2.9x, 3.xx, 4.xx). Finally, a comprehensive list of RHEL and SLES RPMs as function of OpenPegasus release can be found at http://www.openpegasus.org/pr/documents.tpl?CALLER=index.tpl; in short, the target platforms are RHEL3 (Intel-32, Itanium-64), SLES9 (Intel-32, Itanium-64, x86_64), and RHEL4 (Intel-32, Itanium-64, x86_64). The latest release of OpenPegasus, 2.7.x, is the codebase from which this project is working, and it currently provides only the source distribution. 8.1.3 Might the project need any extra adaptation to work successfully with future (i.e., later) releases? patches? Ongoing maintenance is indeed a possibility. It is our hope that we can enlist members of the OpenPegasus community to facilitate such maintenance and, for that matter, evolution. 8.2S Do Solaris components depend on OS features not in the core OS (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional loadable kernel modules)? What packages or clusters must be installed first (if the "core" set of packages is insufficient)? Do the packages express those dependencies explicitly? No dependency on non-core OS features. 8.3 Do Solaris components use any system interfaces, commands, or features not in POSIX or the Single Unix Specification? What is the minimum version of those standards required? (POSIX.1-1990, UNIX98, UNIX2003?) No direct access to operating system resources is done by this project. 8.4 Do Linux components use any interfaces, commands, or features not in the Linux System Base? What is the minimum LSB version required? N/A - Linux support is not in scope for this project. 8.4 With what releases of what other projects or products does this project interoperate? Using what interfaces? (Provide reference to ARC case approving these interfaces or a specification and proposed stability classification for the interfaces.) None 8.5 What internationalization (I18n) issues are involved? What languages *can* be supported by localization without modifying the base product, whether or not a localization is currently planned? What I18N interfaces will the project adhere to? If strings are used, how are they accessed -- Solaris-mostly gettext(), X/Open catgets(), GNU gettext? What items and interfaces are (or are not) being internationalized? See Functional Specification, Section 2.8.4 8.6 Are there any existing or proposed standards it conforms to or deviates from? Examples: SPARC/x86 ABI, POSIX, Open Group standards, IETF RFCs, national or international standards. Include version numbers where applicable. See Functional Spec, section 1.1 8.7 Can this version co-exist or interoperate with earlier and later versions? with alternative implementations (perhaps by other vendors)? Is switching between installed versions or implementations possible? What is involved? This is the initial release of the product, there are no earlier or later versions. This product can co-exist with alternative implementations if those products recognize ports already in use and fall back to alternate ports, subsequently relying on clients' usage of SLP to discover them dynamically. Since the product implements WBEM standards, swapping out implementations or installed versions is in theory possible; again in theory, this should be a plug-and-play exercise. 8.8 Does the project move, disable, delete, circumvent or change any files, components, or services outside the project? See Functional Specification, Section 2.4.5 for a discussion around co-existence with existing Solaris WBEM service. 8.9 Does it use any interfaces (for example, a driver using kernel structures) that are private to another consolidation? read or write /dev/kmem? trap directly into the kernel, instead of via libc functions? No such usage is in play. 8.10 What components (e.g., libraries or packages) are shared with other projects or products? SUNWopenssl-libraries SUNWslpu /etc/pam.d RBAC configuration files Service Management Facility 8.11 Can customization (e.g., OEM relabeling) be accomplished via resource files that are separable from the source code? No user interface is presented by the project; OEM relabeling per se is as such not relevant. 8.12 Device Drivers: N/A 9. Technical Content 9.1 Architecture Diagram: Include in case materials an Architecture Diagram, showing the major components, major interfaces, and all customer-visible interfaces and inter-project interfaces. Give each a number or brief name for use in the Interface Table below. See Functional Spec, section 2.1 9.2 Interface Table: Include Imported and Exported Interface Tables showing all customer-visible interfaces and inter-project interfaces and significant internal interfaces (inter-subsystem and inter-invocation). Interfaces are not just function calls. Include user interfaces (graphical, browser based, character based), configuration files, XML DTD's, database schemas, network protocols, port numbers, etc. See Functional Spec, section 2.2 9.3 Identify names and contents of packages, directories, libraries, databases, etc. Identify package abbreviations (SUNWxxx) and contents figuratively ("configuration command line utilities"). | Tentative package name is SUNWcimserver, located in /opt/SUNWcimserver. | SUNWcimserver will install the CIM server and all associated components, | e.g. repository, client and provider libraries, etc. 9.4 Package manifest: TBD 10. The operational environment: 10.1 Command line or calling syntax: What options/operands are supported? See OpenPegasus distribution, ./doc/Admin_Guide_Release.pdf, section 3: OpenPegasus Command Line Utilities Two of the commands exceed 9 characters. However, since we are only porting an existing open source component, it is beyond the scope of this project to alter these since they are in effect committed public APIs. 10.1.1 Is there support for standard forms, e.g. X11(5) manpage's "-display", etc.? If not, why not? The DISPLAY setting is not applicable to this project. 10.1.2 Are these options propagated to sub-environments? Unknown; this is an implementation detail of the existing overall component that is not clearly documented, i.e. knowledge of the implementation is beyond the scope of this project since this is an existing open source component; for that matter, we have no control over changes to that implementation. 10.2 Can it be included in a shell pipeline? How does it use standard input, output and error? The following commands accept stdin as input: cimmof - compile MOF files into the CIM repository, using input specified via stdin as the input MOF file wbemexec - submit a CIM operation to the CIM Server for execution, using stdin to obtain the XML encoded CIM operation request. The following commands send output to stdout: wbemexec - submit a CIM operation to the CIM Server for execution; the result of the operation is returned to stdout, and consists of the CIM response encoded in XML Generally, all command messages are sent to stdout as specified in section 7.2.4 of the OpenPegasus Admin_Guide_Release (in the OpenPegasus distribution, ./doc/Admin_Guide_Release.pdf) The following commands send explanatory error messages to stderr: cimauth - add, modify, remove or list CIM user authorizations cimconfig - get, set, unset or list CIMOM configuration properties. cimmof, cimmofl - compile MOF files into the CIM Repository cimprovider - disable, enable, remove or list registered CIM providers or CIM provider modules and module status cimserver - start or stop the CIM Server; display the version number of the CIM Server osinfo - returns infomation about the operating system running on a host system. wbemexec - submit a CIM operation to the CIM Server for execution 10.3 Environment Variables: 10.3.1 What environment variables are used? Describe values and semantics. As defined in the following OpenPegasus document: http://www.openpegasus.org/pp/uploads/40/14873/PEP292_RecommendedReleaseOptions.htm 10.3.2 What is the default behavior if the environment variable is not set? As defined in the following OpenPegasus document: http://www.openpegasus.org/pp/uploads/40/14873/PEP292_RecommendedReleaseOptions.htm 10.3.3 What environment variables are set? As defined in the following OpenPegasus document: http://www.openpegasus.org/pp/uploads/40/14873/PEP292_RecommendedReleaseOptions.htm 10.4 For Solaris, Linux, or other Unix programs, what are their exit status values? What nonzero status values have what meanings? Success: 0 Error: 1 Specific meanings for error exits are as defined in the man pages for each command. 10.5S Signals issued? Signals caught? (See "man signal".) What are their semantics? | From a static analysis of the code, no signals are issued; SIGHUP, SIGINT and SIGTERM are | caught and result in a graceful process shutdown. 10.6 Device drivers directly used (e.g. /dev/audio)? None 10.8 Does it use any "hidden" files (filename begins with "."), system files, or temporary files? None 10.9 Does it use any locking files? Does it use Solaris locking facilities? A single file is used for managing concurrent logging by different components. fcntl is the mechanism used here. 10.10 Can it execute remotely? In a distributed fashion? Is the user aware that the tool is executing remotely? A client can establish a remote session, and the user is typically aware of this since the user has issued remote connection parameters to the CIM server. There is no provision for distributed execution. 10.11S Solaris/Linux/Unix Libraries If you have code, include output from both "dump -Lv" and "ldd"; but note that the ARC wants to know what the project will deliver, regardless of what developers currently have. % ldd cimserver libpegservice.so => ../lib/libpegservice.so libpegclient.so => ../lib/libpegclient.so libpegserver.so => ../lib/libpegserver.so libpeguser.so => ../lib/libpeguser.so libpegprm.so => ../lib/libpegprm.so libNamespaceProvider.so => ../lib/libNamespaceProvider.so libpegindicationservice.so => ../lib/libpegindicationservice.so libpeghandlerservice.so => ../lib/libpeghandlerservice.so libConfigSettingProvider.so => ../lib/libConfigSettingProvider.so libDefaultProviderManager.so => ../lib/libDefaultProviderManager.so libProviderRegistrationProvider.so => ../lib/libProviderRegistrationProvider.so libpegauthentication.so => ../lib/libpegauthentication.so libUserAuthProvider.so => ../lib/libUserAuthProvider.so libpegqueryexpression.so => ../lib/libpegqueryexpression.so libpegcql.so => ../lib/libpegcql.so libpegquerycommon.so => ../lib/libpegquerycommon.so libpegwql.so => ../lib/libpegwql.so libCIMQueryCapabilitiesProvider.so => ../lib/libCIMQueryCapabilitiesProvider.so libpegprovidermanager.so => ../lib/libpegprovidermanager.so libCIMOMStatDataProvider.so => ../lib/libCIMOMStatDataProvider.so libInteropProvider.so => ../lib/libInteropProvider.so libCertificateProvider.so => ../lib/libCertificateProvider.so libpegslp.so => ../lib/libpegslp.so libpegpmservice.so => ../lib/libpegpmservice.so libpegprovider.so => ../lib/libpegprovider.so libpegexportserver.so => ../lib/libpegexportserver.so libpegrepository.so => ../lib/libpegrepository.so libpegconfig.so => ../lib/libpegconfig.so libpegcommon.so => ../lib/libpegcommon.so libpthread.so.1 => /usr/lib/libpthread.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libxnet.so.1 => /usr/lib/libxnet.so.1 libCstd.so.1 => /usr/lib/libCstd.so.1 libpam.so.1 => /usr/lib/libpam.so.1 librt.so.1 => /usr/lib/librt.so.1 libCrun.so.1 => /usr/lib/libCrun.so.1 libm.so.2 => /usr/lib/libm.so.2 libw.so.1 => /usr/lib/libw.so.1 libthread.so.1 => /usr/lib/libthread.so.1 libc.so.1 => /usr/lib/libc.so.1 libpegslp_client.so => ../lib/libpegslp_client.so libssl.so.0.9.8 => /usr/sfw/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 => /usr/sfw/lib/libcrypto.so.0.9.8 libslp.so.1 => /usr/lib/libslp.so.1 libslp.so.1 (SUNW_1.1) => (version not found) libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libscf.so.1 => /lib/libscf.so.1 libresolv.so.2 => /lib/libresolv.so.2 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 libcrypto_extra.so.0.9.8 => (file not found) % dump -Lv cimserver cimserver: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libpegservice.so [2] NEEDED libpegclient.so [3] NEEDED libpegserver.so [4] NEEDED libpeguser.so [5] NEEDED libpegprm.so [6] NEEDED libNamespaceProvider.so [7] NEEDED libpegindicationservice.so [8] NEEDED libpeghandlerservice.so [9] NEEDED libConfigSettingProvider.so [10] NEEDED libDefaultProviderManager.so [11] NEEDED libProviderRegistrationProvider.so [12] NEEDED libpegauthentication.so [13] NEEDED libUserAuthProvider.so [14] NEEDED libpegqueryexpression.so [15] NEEDED libpegcql.so [16] NEEDED libpegquerycommon.so [17] NEEDED libpegwql.so [18] NEEDED libCIMQueryCapabilitiesProvider.so [19] NEEDED libpegprovidermanager.so [20] NEEDED libCIMOMStatDataProvider.so [21] NEEDED libInteropProvider.so [22] NEEDED libCertificateProvider.so [23] NEEDED libpegslp.so [24] NEEDED libpegpmservice.so [25] NEEDED libpegprovider.so [26] NEEDED libpegexportserver.so [27] NEEDED libpegrepository.so [28] NEEDED libpegconfig.so [29] NEEDED libpegcommon.so [30] NEEDED libpthread.so.1 [31] NEEDED libdl.so.1 [32] NEEDED libsocket.so.1 [33] NEEDED libnsl.so.1 [34] NEEDED libxnet.so.1 [35] NEEDED libCstd.so.1 [36] NEEDED libpam.so.1 [37] NEEDED librt.so.1 [38] NEEDED libCrun.so.1 [39] NEEDED libm.so.2 [40] NEEDED libw.so.1 [41] NEEDED libthread.so.1 [42] NEEDED libc.so.1 [43] INIT 0x805b9dc [44] FINI 0x805ba9c [45] RUNPATH /opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib:/usr/ccs/lib:/usr/lib [46] RPATH /opt/SUNWspro/lib/rw7:/opt/SUNWspro/lib:/usr/ccs/lib:/usr/lib [47] HASH 0x80500e8 [48] STRTAB 0x8051cfc [49] STRSZ 0x2b4e [50] SYMTAB 0x805113c [51] SYMENT 0x10 [52] SUNW_SYMTAB 0x80506dc [53] SUNW_SYMSZ 0x1620 [54] SUNW_SORTENT 0x4 [55] SUNW_SYMSORT 0x80548ec [56] SUNW_SYMSORTSZ 0x320 [57] CHECKSUM 0x8251 [58] VERNEED 0x805484c [59] VERNEEDNUM 0x4 [60] PLTSZ 0x3c0 [61] PLTREL 0x11 [62] JMPREL 0x8054c9c [63] REL 0x8054c0c [64] RELSZ 0x450 [65] RELENT 0x8 [66] DEBUG 0 [67] FEATURE_1 PARINIT [68] FLAGS 0 [69] FLAGS_1 0 [70] SUNW_STRPAD 0x200 [71] PLTGOT 0x806c6f4 10.11.1 What dynamic (aka "shared") libraries does it use directly or indirectly, including via dlopen/dlsym(3x)? | The following libraries are known to load dynamically: | | libpegslp_client.so | libCMPIProviderManager.so | libscf.so.1 | libuutil.so.1 | libgen.so.1 | libmd.so.1 | libmd_psr.so.1 | libmp.so.2 | Pegasus supports dynamic loading of CMPI providers using dlopen/dlsym, but individual provider aspects are not part of this case. 10.11.2 With what -R options will executables be built? Possibly /usr/sfw/lib/64 for 64 bit distro.. support for 64-bit is currently being tested. TBD by commitment review. 10.11.3 Does it use any static libraries? None 10.11.4 What libraries does your project export? libpegclient.so, libpegprovider.so, and libpegcommon.so provide the C++ client and provider APIs. 10.12 Does your project use or ship database or persistent storage software? Persistence is needed for the CIM repository, though RDBMS technology per se is not in use. 10.12.1 What software does it use? An internal proprietary implementation is used for the CIM repository. 10.12.2 Does it meet the SAC Policy on using standard databases? (see the Database Policy at http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=dbpolicy.bp ) If NO, please provide the reason: [ ] does not meet technical requirements (please specify) [x] product already shipping with non-compliant technology [ ] customer requires we use a specific database [ ] other (please describe) 10.12.3 Is the database technology available for customer use? No, not for general purpose use 10.12.4 Does the customer have to explicitly manage/administer the technology? Command line utilities are available to initialize the repository and to compile MOF files into classes in the repository 10.13 Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? No such dependencies. 11. System Administration Interfaces: 11.1 How will the project's deliverables be installed? pkgadd 11.2 How will the project's deliverables be uninstalled? pkgrm 11.3 How will the project's deliverables be configured and reconfigured? Command line parameters can be supplied on startup of the CIM server to configure behavior for that session, and a reconfiguration command utillity can be used at runtime to alter behavior either immediately, for some subset of overall configuration parameters, or on the next session startup. See the man pages for cimserver and cimconfig for details. 11.4 Does it need installation within any global system tables? Does your package edit existing files in a common directory (/etc/vfstab for example)? If so, how do you remove your edits when your package is removed? If your package is reinstalled over itself, does it recognize that the edits are already there or does it make all new entries? See Functional Specification, Section 3.2.2 11.5 Does your package use components of other unbundled packages? If so, how do you find those packages? The project does not rely on any unbundled Solaris packages. 11.6 Can your product be installed to an alternate filesystem (using "pkgadd -R") for use with diskless/auto clients or live upgrade? The product will be installed using ${PKG_INSTALL_ROOT:-/} as the assumed target filesystem. 11.7 Can your product be installed anywhere on the target system and still function (is it relocatable)? (BASEDIR) The product will be installable in a relocatable manner. 11.7.1 Has your project changed or introduced any package procedural scripts (postinstall, preremove, etc)? If YES, are these scripts well-behaved with respect to alternate roots? That is, when these packages are added or removed using -R, do they cause any changes to be made to /? The correct answers are either "No" or "Yes, Yes, and No". Yes, yes and no 11.8 Even relocatable packages may have one or two elements that *must* go in a certain place (/etc files for example). Are these "absolute" elements in the pkgmap or are they being installed with a postinstall script? If installed with a postinstall, how does the administrator check their integrity (how does pkgchk know about them)? | N.A. 11.9 How does a new version of your package upgrade a prior version? The CIM server is shut down, the repository is archived, the old package is uninstalled, the new package is installed (including reinitializing the system with the archived repository) and the CIM server is started back up. 11.10 Does your package replace a filesystem object delivered by a prior package? If so, how do you inform the other package that it doesn't own this file anymore? How do you return the original package to its original state if your package is pkgrm'd? No such filesystem object replacement is done. 11.11 Have you grouped generic functionalities that may be used by other projects into their own packages (KLG widgets, a third-party set of device drivers)? If not how do other projects know this generic functionality is installed? Are you using existing classes and libraries as far as possible? No reusable functionalities are delivered, and in cases where generic functionality is needed, existing classes and libraries are used. Cases in point include Solaris SLP, OpenSSL, Solaris PAM and Solaris RBAC. 11.12 How is it started? For a daemon: does it use SMF (if on Solaris) or inetd? If not, why not? If SMF, does it comply with the SMF best practices in http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=SMF.bp ? See Functional Specification, Sections 2.1 (last paragraph) and 2.4.5 11.13 Does it use a naming service such as NIS, DNS, LDAP? Directly, or through the name service switch? No naming service is used. 11.14 What are its on-going maintenance requirements (e.g. keeping global tables up to date, trimming files)? Pegasus default logging functionality is described here: The Logger class logs to a standard log. Once the standard log gets larger than 32MB the original is copied to a new file with a name that contains a date/time stamp. The standard log is then restarted empty. There are also filters via a bitmask that can be used to limit the amount of data logged. Alternately, it's possible to use syslog. We are presently advised by the open source community that we can configure this by setting "DEFINES += -DPEGASUS_USE_SYSLOGS" in our platform makefile, though this has not yet been tested. This is a point to be discussed in the inception review. 11.15 Can administration be done from a remote machine? How? Administration interfaces are in the form of local command-line scripts only, no remote admin is possible. 11.16 Can all GUI administration also be performed without the GUI? How? There is no GUI administration. 11.17 What command or scripting language is used? Bourne shell. 11.18 Does the project include runtime license checking? Why? How is it accomplished? How does it cope with changes of the underlying system due to hardware replacement or virtualization? No runtime license checking is done. 11.19 Are there any restrictions or other architectural effects from contractual obligations, copyright restrictions, technology royalty structure, or open source license requirements? The Pegasus project uses the MIT open source license. 12. The Window System/Desktop Operational Environment: 12.0 Does the project include a GUI (Graphical User Interface)? None 13. Brainstorming Interfaces (exported and imported): Include in your Interface Table any of the following that apply. You may comment on them here, if you wish. See Functional Specification, section 2.2 (Interfaces). 13.2 Protocols (public or private, including RPCs) HTTP is the transport protocol. Ports 5988 and 5989 are the default configurations, with alternate ports 6988 and 6989 supported via configuration changes and/or startup arguments. 13.3 Drag and Drop: what objects and what are the semantics? N.A. 13.4 GNOME ORB (bonobo) remote calls, Web service calls (SOAP, etc.), ToolTalk messages? None 13.5 Files used as an interface, e.g. Resources, config files, etc. The only public interface exposed as files is the MOF file collection (see 13.6). 13.6 Significant file formats, names, syntax, and semantics? Is there an /etc/magic entry for any new file format? What will file(1) say? The project provides a utility that compiles MOF (Managed Object Format) files into the CIM repository, typically representing classes in the management domain. The MOF file format is a well-known standard as specified in http://www.dmtf.org/standards/published_documents/DSP0004V2.3_final.pdf. It is a BNF-based language used to declare classes, operations, properties, associations and etc. as needed to describe managed resources. 13.7 Interfaces to applications it interoperates or communicates with? (Perhaps pipes, shared memory.) CIM over HTTP is used by clients in a request-response protocol. 13.8 Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? No namespaces. 13.9 Other External Interfaces? See Functional Specification, Section 2.2.1 13.10 Brainstorming Significant Internal Interfaces None 13.11 Protocols (public or private) CIM-XML, HTTP (See Functional Specification, section 2.2 for details) 13.12 Private ORB, RPC, SOAP, RMI, etc. transactions None 13.13 Files and their Formats MOF files (See Functional Specification, section 2.2 for details) 13.14 Do any internal interfaces save state across invocations? The CIM repository provides persistence. The configuration files (./cimserver_planned.conf and ./cimserver_current.conf) save state for, respectively, current and planned configurations, i.e. the current runtime environment and the "next" session. 13.15 Other Internal Interfaces? None 14. Questions for Every Interface: These questions should be asked for every one of the project's interfaces; the answers are therefore often listed in Section 9.2 (Don't repeat.) Only the interesting answers are normally discussed. For purposes of addressing various of the following questions, here are the listed interfaces from Functional Specification, section 2.2: Exported interfaces: HTTP ports CLI commands: cimauth cimconfig cimmof cimprovider cimserver cimreparchive osinfo wbemexec cimsub cimtrust cimuser C++ APIs CMPI API OpenPegasus Schema OpenPegasus Configuration Parameters OpenPegasus SDK DMTF CIM Schema 2.13.1 xmlCIM CIM Operations over HTTP CIM Query Language MOF Language MOF Files bundled w/Pegasus RBAC Profiles SLP Advertisements SMF Manifest Compile-time symbols C++ Provider API libraries: libpegclient.so, libpegprovider.so, and libpegcommon.so Imported Interfaces not already specified as an exported interface: Solaris PAM SMF SLP OpenSSL HTTP XML DTD RBAC CIM Infrastructure Specification CIM-XML 32-bit Solaris libraries: /usr/lib/libpthread.so.1 /usr/lib/libdl.so.1 /usr/lib/libsocket.so.1 /usr/lib/libnsl.so.1 /usr/lib/libxnet.so.1 /usr/lib/libCstd.so.1 /usr/lib/libpam.so.1 /usr/lib/librt.so.1 /usr/lib/libCrun.so.1 /usr/lib/usr/lib/libm.so.2 /usr/lib/libw.so.1 /usr/lib/libthread.so.1 /usr/lib/libc.so.1 /usr/sfw/lib/libssl.so.0.9.8 /usr/sfw/lib/libcrypto.so.0.9.8 /usr/lib/libslp.so.1 /lib/libmp.so.2 /lib/libmd.so.1 /lib/libscf.so.1 /lib/libresolv.so.2 /usr/sfw/lib/libgcc_s.so.1 /lib/libuutil.so.1 /lib/libgen.so.1 64-bit Solaris libraries: /lib/amd64/libpthread.so.1 /lib/amd64/libdl.so.1 /lib/amd64/libsocket.so.1 /lib/amd64/libnsl.so.1 /lib/amd64/libxnet.so.1 /usr/lib/amd64/libCstd.so.1 /lib/amd64/libpam.so.1 /lib/amd64/librt.so.1 /usr/lib/amd64/libCrun.so.1 /lib/amd64/libm.so.2 /lib/amd64/libthread.so.1 /lib/amd64/libc.so.1 /usr/sfw/lib/amd64/libssl.so.0.9.8 /usr/sfw/lib/amd64/libcrypto.so.0.9.8 /usr/lib/amd64/libslp.so.1 /lib/amd64/libscf.so.1 /lib/amd64/libuutil.so.1 /lib/amd64/libgen.so.1 /lib/amd64/libmd.so.1 /lib/amd64/libmp.so.2 14.1 Propose the stability/commitment classification of the interface -- Committed (formerly Public, Stable or Standard), Uncommitted (formerly Unstable), Volatile, Project Private, etc. -- per the SAC Interface Taxonomy document at http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp All interfaces are Committed. 14.2 Who controls the interface (i.e., could make changes to it)? Point out any interfaces not solely controlled by Sun. All interfaces are controlled by the OpenPegasus community, except for the following: HTTP(S) ports - controlled by DMTF (http://www.dmtf.org) CIM (Schema, xmlCIM, CIM Operations over HTTP, CIM Query Language, MOF language, CIM-XML, CIM Infrastructure) - controlled by DMTF SLP protocol - Internet Engineering Task Force (http://www.ietf.org) XML - W3C Controlled by OpenPegasus community (http://opengroup.org/): Command Line scripts (see Functional Specification, section 2.2.1 for details) C++ API for clients, providers and indications consumers CMPI Provider API OpenPegasus schema OpenPegasus Configuration Parameters OpenPegasus SDK 14.3 Interface Specification: 14.3.1 Where is the interface specified (documented)? See Functional Specification, Section 2.2 14.3.2 Is the specification complete enough for a re-implementation? Yes, all interfaces are Committed. 14.3.3 Will the project deliver to customers documentation for the interface? Exported interfaces only are relevant to this question: HTTP ports - yes CLI - yes C++ APIs - yes CMPI API - yes OpenPegasus Schema - yes OpenPegasus Configuration Parameters - yes OpenPegasus SDK - yes DMTF CIM Schema 2.13.1 - no xmlCIM - no CIM Operations over HTTP - no CIM Query Language - no MOF Language - no MOF Files bundled w/Pegasus - yes RBAC Profiles - yes SLP Advertisements - yes SMF Manifest - yes 14.3.4 Are the interfaces documented clearly enough for a non-Sun client to use them successfully? Yes 14.4 Interface Versioning and Projected Evolution 14.4.1 Present Change: if any interface is an update to or replacement for a previous one, what was the stability classification of the previous version? Is this backwards-compatible? Describe any migration story to mitigate the conversion. This is a new project; there are no updates or replacements of previous interfaces. 14.4.2 Future Evolution: Even if an interface is new, it should be prepared for evolution. How will a transition to a new version to be accomplished? What are the expected consequences to ISVs and users and administrators? What provisions are made now to minimize or manage the pain (to clients) of future evolution? Future evolution of several of the interfaces are under the control of the OpenPegasus community. That said, it is that community stated intentions to maintain backwards compatibility. Sometimes there are situations beyond their control - see section titled "Conformance Exceptions to DMTF Specifications" in PEP 40 document at http://www.openpegasus.org/pp/uploads/40/14933/ReleaseNotes.htm for an example; in this case, e.g., the community takes steps as necessary to mitigate the issue and provide a workaround. In general, however, the product's primary interfaces are based on industry standards, so the concern here is synonymous with concern around industry standards from bodies such as the DMTF, Open Group, W3C and IETF. 15. Performance and Scalability: 15.1 What are the performance goals of the project? How were they evaluated (or how will they be)? On what type of test platform? How will performance regressions be identified? See Functional Specification, Section 2.5.1 15.2 Are there any limits to scalability, such as a fixed-size array forcing a maximum number of clients, users, simultaneous connections, etc.? Are any data structures (e.g., kernel structures) so huge that large numbers of them are impractical? See Functional Specification, Section 2.5.3 15.3 Resource Consumption: 15.3.1 Attempt to describe resource consumption scaling, even crudely. For example, if each client consumes 1MB of memory, you could say: Memory_required = 1MB * Nclients See Functional Specification, Section 2.5.5 15.3.2 Which resources are likely to be bottlenecks? See Functional Specification, Section 2.5.3 15.4 Does the application pause for significant amounts of time? No. 15.5 Multi-threading: What is your project's MT model? What must an MT client do to use your interface(s) safely? How does your project use threads internally? How does it expect its client to use threads? If it uses call-backs, can the called entity create a thread and recursively call back? Is it prepared for multi-thread & multi-core systems like Niagara and Opteron? The http monitor supports multiple sessions and is inherently multi-threaded due to the request-response nature of the protocol. 15.6 What is the impact on system performance (positive or negative)? The impact on system performance depends on level of load from CIM requests and from number of providers in use at any given time. 15.6.1 What is the average memory usage or working set of this component? See Functional Specification, Section 2.5.5 15.6.2S How much of this is shared/sharable by other apps? None is sharable. 15.7 Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? No wake-up is done; the CIM server remains in running mode throughout its lifecycle. 15.8 Will it require large files/databases (for example, new fonts)? Footprint of the CIM repository is a function of the number of managed objects stored there, however usually such objects are stored directly in each provider. 15.9 Do files/databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? That would need to be measured in a provider context, since it will be a function of how many and what type of providers are loaded by the user. However, that is not the focus of this project; Pegasus is simply providing the framework for this pluggable environment. 15.10 What are the project's effects on boot time requirements? See Functional Specification, Section 3.2.3 16. Security: Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. See Security Questionnaire in case materials. 17. Availability and Serviceability 17.1 How will it respond to failures? (Does it ever require reboot? Can it lock up? Is there a way for the user to "unstick it"?) Shouldn't require reboot. As a non-trivial process, lock-up is of course a possibility; unstick it with ctl-C or kill -9. In either event, any failures will not bring the host system down, cause a kernel panic, etc. 17.2 How does your project deal with network failures (including partition and re-integration)? See Functional Specification, Section 2.6.3 17.3 Can it save and restore state? Is any special action required if the filesystem is rolled-back to previous state (such as via ZFS or other filesystem snapshot technologies)? See Functional Specification, Section 2.6.5 17.4 Can it checkpoint and recover? Can its files be corrupted by failures? Does it clean up any locks/files after crashes? No. File corruption is feasible, however as noted in 17.3, regeneration of persistent data is possible. Since, as per question 10.9, fcntl is used for file locking, cleanup after crashes is managed as per man fcntl: All locks associated with a file for a given process are removed when a file descriptor for that file is closed by that process or the process holding that file descriptor terminates. 17.5 Will it participate in the Solaris Fault Management Architecture (http://fma.eng.sun.com/)? No. 17.6 Can the project's deliverables be patched and upgraded without requiring a reboot? Without a noticeable service interruption? No reboot required. Service interruption is possible. 17.7 How will patches be installed? Standard Solaris patch mechanisms. 18. Adaptability to a Changing World: 18.1 Any plans for supporting operating systems other than Solaris (Linux, Microsoft Windows, MacOS X, AIX, HP/UX, etc.)? No 18.2 How does it deal with issues in the 64-bit world, including 64-bit address spaces, 64-bit integers, and 64-bit files? See Functional Specification, Section 2.8.5 18.3 How will the project provide services to other projects? Standard WBEM interfaces 18.3.1 Current or planned usage of CORBA IDL, IIOP, and an ORB? If an ORB, hich one (Bonobo, Java IDL, ...)? None 18.3.2 Current or planned Java Beans, especially J2EE? None 18.3.3 Current or planned Web Services interfaces (SOAP, etc.?) None 18.4 What is its relationship (or difficulties) with . . . 18.4.1 the Internet? Web Services? Uses HTTP protocol with CIM/XML encoding 18.4.2 Java? J2EE? Application Servers? Java-based clients and providers can use the CIM server, but efforts around developing those components is not part of this project. There is no relationship to application servers. 18.4.3 "Network of Things" (thin clients, portable devices, cell phones, wireless networking, kitchen appliances with IP addresses?) CIMOM is the central hub, supporting any clients that leverage the standard WBEM interface 18.4.4 Multimedia? N.A. 18.4.5 Networked storage (SANs, NAS) N.A., other than the general ability to manage objects of this type (assuming profile and provider availability) 18.4.5 Infiniband? N.A., other than the general ability to manage objects of this type (assuming profile and provider availability) 18.4.6 Network identity services? N.A., other than the general ability to manage objects of this type (assuming profile and provider availability) 18.4.7 Virtualized environments (Xen, Zones, VMWare)? N.A., other than the general ability to manage objects of this type (assuming profile and provider availability) 19. Issues? Please identify the issues for which you would like ARC guidance. (e.g. Interface classification, deviations from standards, architectural conflicts, release constraints...) None. Any issues outstanding from previous reviews (or the case's mail archive)? None. 20. Appendices and References 20.1 Interface Tables, Package Manifests, etc See case materials. 20.2 References to other documents (one-pager, design papers, interface contracts, etc.). Copies are to be placed in the case directory. See case materials. 20.3 Comments For Us? 20.3.1 How many engineer hours went into preparation of case materials, including answering this questionnaire (that would not otherwise have been needed for other purposes)? to-date: 16 hours 20.3.2 Do you think it was time well spent? Yes, and additionally I'm sure there are insights that I'll receive after looking back at what is my first ARC review. 20.3.3 How many engineer hours went into answering this questionnaire alone? to-date: 8 hours 20.3.4 Comments on this questionnaire should be mailed to lsarc-chair@sac.eng.sun.com. No comments at present. 20.3.5 Comments on your case owner, the review process, or the experience may be placed here if they're not too personal, may be mailed to the chair or arc-chairs@sac, or may be expressed to John Plocher (x87604), or your divisional CTO. No comments at present.