Difference between revisions of "Production Ready Task Force Work Page"

Revision as of 17:00, 25 April 2008

Aperi Wiki Home

This page is for communicating thoughts and ideas on works in progress to the workgroup.

Known Issues

• Specification/SMI-S Level Issues

• Consistency -- Different implementations tend to do things slightly differently even if they don't have to. How can we tighten up the spec to define better the expected behaviour? High priority. SMI-S needs to get back-to-basics and tighten up the specification some more. Next steps would be to research what the variation between vendors/providers really is and use that to propose some real feedback.

• Backwards Compatibility (both within SNIA and for vendor extensions) -- How to ensure that products that use these standards don't end up painted in a corner where they can only work with one version at a time, or can't handle an upgrade of a component, etc. Medium-high priority. We need to come up with a way to register versions of vendor extensions and allow the client to determine up front if it's compatible with a given version of the provider.

• Lag between device function and SMI-S -- Is somewhat contradictory with earlier requirements/requests for avoiding spec churn and backward compatibility. How do we manage the conflict? Low priority (must not put backward compatibility at risk). Perhaps we can leverage a registered vendor extensions publication mechanism within SNIA. The idea is to publish model concepts that we're working on and use that material as foundation for new profiles and changes to profiles.

• Spec changes too quickly/much -- This makes it difficult for exploiters to code solutions as everything becomes a moving target. Medium priority. There needs to be a stable core of functions that get extended and sometimes that's difficult to agree on. Also, we need to stop declaring victory too soon.

• Technology

• Element Managers using SMI-S -- What kind of changes do we need to be able to allow element managers to get the data they need quickly enough to handle a dynamic real-time customer environment. High priority (we're missing the boat here!). We need to look at mechanisms to provide real-time transfer of data (scatter/gather, push/pull, etc.).

• Embedding vs Proxy -- Seems like embedding makes for better, more stable infrastructures but isn't always possible? High priority. Customers don't want to have to setup servers and configure providers. Our solution should not make the problem space bigger. Provide ratings (consumer reports style) for usability/installability rating. We should participate in install-fest. Suggest a logo-programme specifically identifying embedded (powered by embedded SMI-S?).

• Event Management -- Indications has some problems, we should fix it? Medium-high priority. We need to research what we really want to get out of indications, what they're used for, and determine when they should be used. For example, an indication telling clients a minor change and an indication telling the client that the box is on fire is treated the same within the cim protocol.

• Client software coded for SMI-S vs client software coded for specific device CIM model CTP needs to have a reference implementation of providers for client testing. This would ensure that the client software at least supports base SMI-S functions. More draconian measures would require a specific MOF to be used by both providers and clients -- e.g., no specialisation of classes; vendor extensions must be provided in seperate namespace, or perhaps just separate classes...

• Multi-tennant CIMOM Go embedded! :-)

• CIMOM Coexistence on Server Platform specific, not really SMI-S solution -- relates to the distribution, platform, and implementation.

• Implementation/Adoption

• Scalability and Performance -- like the stability item, this becomes important when we try to get customers to really use this stuff. This is pretty important, recent data from ScaleFest indicate that the best providers delivered about 50 instances/sec which is clearly not fast enough to support 30,000 to 60,000 volumes. We should create benchmarking clients to evaluate the performance and publish the results.

• Stress Testing -- how to we ensure that we've met stability? Recommend leverage/require Olocity.com for independent third-party review -- kind of like UL approved.

• Configuration and Setup -- Setting up and configuring the CIM software. How do we make it easier for customers to deploy the software? Should be embedded with no special configuration required; but we will need to tackle it anyway because not everyone can get there right away. Things we can do: Marketting/messaging -- "Aperi works better with embedded providers", or list a set of tier-1 providers (embedded ones). There are some open-source storage arrays, and we can work with them to have embedded CIM Agents and reference them from Aperi. Create/update an Aperi best-practises page to include embedded providers/agents.

• Host profiles have been lagging adoption. Lots of OSs are shipping host profiles, but we're missing client exploitation of them. Tonnes of work Aperi can do to advance the host profile adoption. Maybe Aperi can drop host agent support and use SNIA host profiles instead. Core Profiles to implement: HDR and HBA (shipping on a bunch of OSs). AIX server running in tech centre today.

• Aperi has no support for SMI-S enabled host based discovered resources; but might be able to extend coverage through work items. Doing this might help gain momentum in space. -- merge with bullet above.

• SNIA starting up SMI-S developers group where engineers (open to all) can ask questions, and get FAQ. -- skip.

• Installation checklist -- similar to the Configuration and Setup, we need to define/express clearly the requirements to install the software. -- skip

• Bet the farm on SMI-S? When to use SMI-S and when not to; what needs to happen to make SMI-S the primary and obvious choice? Make Aperi successful will create competitive pressure to motivate vendors to do more in SMI-S.

• Promote Element Managers to use SMI-S. Aperi delegates to the element manager's specialised functionality using launch in context. Aperi has no stake in whether those element managers use SMI-S or not.

• Need more client software to support SMI-S -- Like the bet the farm idea, what do we do to increase adoption. New Aperi services/functions will be created as components that can be reused, however existing components have not been componetised and would require work to break it apart. Perhaps we should create a workgroup within Aperi to determine which components should be pulled out and drive the execution. These components can be reconsumed by other projects.

• Reliability, Robustness and Stability -- overall problems that need to be addressed in order for SMI-S based management to supersede proprietary implementations. It is not acceptable to customers to have unstable management infrastructures -- skipped, covered in stress test, etc.