Information Plan for Media Management System (MMS) 1.0

Revision History

Please send comments on this plan to barbara.e.higgins@sun.com

Contents

• Project Description

• Target Audience

• Extended Team

• Deliverables

• Use Cases

• Quality

• Production Process

• 508 Requirements

• People Resources

• Globalization

• Open Issues/Risks

• High-Level Schedule

Project Description

The Sun Media Management System (MMS) is based on IEEE standard 1244, Media Management System (MMS) which defines a set of commands for managing media, the Media Management Protocol (MMP). MMS is software that manages removable media and drives in robotic libraries.

The principal function of Sun's MMS implementation is to be a mounting service and a uniform interface for client applications in a distributed environment. Client applications interact with MMS, which in turn, interacts with the removable media archive. Client applications do not have to have different code to use different types of drives. One version of tape processing code will work for all device types.

Sun's MMS simplifies the MMP commands, presenting their functions through two interfaces: a management interface consisting of two Solaris commands whose options provide the most frequently-used MMP operations and an API consisting of 30+ commands that package the MMP commands with support for connection protocols.

The first client application is intended to be ADM. The MMS 1.0 will interface to the Sun Library Manager (formerly StorageTek ACSLS), through which it manages the tape archive as the removable media. Users of ADM can manage tapes in the tape archive through the intermediary, MMS 1.0.

Target Audience

The MMS documentation is written assuming that the reader has a good understanding of Solaris and storage administration. Potential audience members for MMS documentation:

• Sun external customers:

  • System administrators who are configuring a client application such as Sun's ADM or are installing MMS for use by a custom client application.

• Sun internal customers who need to connect ADM to MMS or to connect MMS to the Storage Library Manager:

  • Trained service providers

  • SSEs

  • Professional Services

  • System Administrators

Extended Team

The following tables contain contact details for people in the extended product release team.

Deliverables

The following tables list the documentation/training deliverables for MMS release. These deliverables were derived from the following specification documents:

• MMS Management CLI spec - version 0.5

• MMS FSD, version 0.8

Note: This section provides as much information as is available when this document is submitted for approval by the Product team (or equivalent).

Project Hours Estimates

The following estimates are subject to a number of factors, but it's a broad estimate of the work that is required. This estimate is only for the Administration Guide, which is the bulk of the work.

• Approx. 40 tasks x 2 pages per task = 80 pages

• Approx. 5 conceptual (Component) areas x 10 pages per area = 50 pages

• 130 pages X 4 Hours/Page = 600 hours = 13 weeks = 3-4 months

Alpha/Beta Deliverables

This project does require a beta delivery.

Use Cases

Initialization

On the MM:

• Start, stop, or restart MM

• Modify MM configurations

• Establish passwords for LM/DM, establish connections to LM/DM

• Client and Application registration

• Password management and access to Postgres Database, Set up database parameters

On other hosts:

• Enable daemon process

• Set up communication with the MM

Configuration & Operation

• Add client

• Add/Delete/Modify library

• Add/Delete/Modify drive (share, change drive physical mappings etc.)

• Change state of a drive - Set the drive or library to be in-operational

• Create/Delete a media pool, Manage media in a pool

• Mount media - load a media into a drive

• Unmount media - unload a media from a drive

• Export media - remove a media from MM

• Accept request

• Cancel request

Monitoring

• List libraries

• List drives

• List pools

• List outstanding requests

• List media by filter criteria (usage, status, media type, library, pool)

• List MM status

• List resources used by current application

• List messages

Quality

This section highlights the measures taken to ensure the quality of the content delivered as part of this project.

The information quality is tied to the following requirements from engineering:

• Timely notification to technical writer of new RFEs or information for the release

• Updated wikis and specs

• Timely and thorough reviews

Testing

The content created in this project will be tested by the test group during the FVT testing. Draft documentation will be made available at the start of the FVT.

Review Process

The content created in this project will be reviewed. It is important that the review is not the first contact that the contact creator has with the reviewers. To reach the review stage, the content creator has to receive information from all the information sources.

Editorial

The content created in this project will be edited by IPG production team.

Bug Tracking

Content bugs and bugs affecting content will be tracked in Bugster, using the mms/software/* categories.

Production Process

This section provides a high-level view of the production process used to create the deliverables of this project.

• Composition Tools: The content is created using text editors and Epic's Framemaker+SGML editor. The screencast will be created in Comtasia.

• Editorial Guidelines: The content created as part of this project will comply with Sun's editorial guidelines.

• Illustration Guidelines: The illustrations and graphics created as part of this project will comply with Sun's graphic guidelines.

• Trademarks: All Sun and third-party trademarks will be documented in accordance with the information provided by the TMARK tool.

• Archiving: After revenue release, writers and content-developers will archive content files in pubstool2.

508 Requirements

[x] The content delivered in this project will comply with the Sun's current guidelines for 508 requirements.

[ ] The content delivered in this project does not apply Sun's current guidelines for 508 requirements.

People Resources

This section provides high-level information about the Information Product resources required for this project.

Globalization

All documentation deliverables for this project will be translated after the RR date, including the help files saved as a book. The Help book may be sent to L10N earlier since it must be delivered to the code earlier than RR.

Since the troubleshooting information is being moved to a wiki, the information cannot be translated using the typical process. However, the current L10N big rules states that troubleshooting information does not need to be translated. So, a waiver should not be needed.

Open Issues/Risks

• Wiki - The product team needs to decide on which wiki to use for the troubleshooting information.

• Engineering Time - Beyond the standard reviews, the engineering, RPE, and PTS teams will be responsible for writing and updating the troubleshooting information on the wiki. The engineering team is also responsible for updating the man pages. In both cases, the writer will be responsible for reviewing this work as needed, but the writer is not the main contributor.

• Translated Troubleshooting Information - If we move the troubleshooting information to the wiki, it falls outside the current L10N process for translation. If the P-team decides that the troubleshooting information must be translated, we need to resolve this issue.

General Issues/Risks

• Design/Functional Specs - These documents must be provided by the engineering development team and maintained to reflect design changes that occur as the development cycle evolves. Any changes to the product design might have an impact on the schedule of deliverables.

• Prototype Availability - Stable prototypes must be available in time for the Information Products team to test their deliverables.

• Timely Reviews - Reviewers must return comments in a timely fashion. Members of the Information Products team will contact individual reviewers to schedule focused reviews and notify reviewers of upcoming reviews.

• UI/Functionality Freeze - At a point, all user interfaces, APIs, configuration files, and command-line utilities, must be frozen, and the freeze date must be adhered to. This freeze point must be early enough in the project schedule to give writers and content developers time to accurately capture the state of the product at time of freeze.

• Product Release Schedule - If the product release schedule changes, this change will have an impact on the schedule for Information Product deliverables.

• Hardware/Software- Availability of system on which to test content created.

High-Level Schedule