Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Production Ready Task Force Work Page"
(→Known Issues) |
(→Known Issues) |
||
| Line 5: | Line 5: | ||
=== Known Issues === | === Known Issues === | ||
| − | :* | + | :* Configuration and Setup -- Setting up and configuring the CIM software. |
| − | :* Consistency -- Different implementations tend to do things slightly differently even if they don't have to. | + | |
| + | :* Specification/SMI-S Level issues | ||
| + | ::* Consistency -- Different implementations tend to do things slightly differently even if they don't have to. | ||
| + | ::* 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. | ||
| + | ::* 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? | ||
| + | ::* Spec changes too quickly/much -- This makes it difficult for exploiters to code solutions as everything becomes a moving target. | ||
| + | ::* Problem Profiles (e.g., not keeping up with other work) -- For example, Copy Services, Host Based Raid, etc. | ||
| + | ::* 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. | ||
| + | |||
| + | |||
:* 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. | :* 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. | ||
| − | |||
:* Scalability and Performance -- like the stability item above, this becomes important when we try to get customers to really use this stuff. | :* Scalability and Performance -- like the stability item above, this becomes important when we try to get customers to really use this stuff. | ||
:* Stress Testing -- how to we ensure that we've met stability? | :* Stress Testing -- how to we ensure that we've met stability? | ||
:* Embedding vs Proxy -- Seems like embedding makes for better, more stable infrastructures but isn't always possible? | :* Embedding vs Proxy -- Seems like embedding makes for better, more stable infrastructures but isn't always possible? | ||
| − | + | :* Single standardized CIMOM? Do we want to define a single CIMOM that everyone should use? | |
| − | + | ||
| − | :* Single standardized CIMOM? Do we want to define a single CIMOM that everyone should use? | + | |
| − | + | ||
:* Event Management -- Indications has some problems, we should fix it? | :* Event Management -- Indications has some problems, we should fix it? | ||
:* 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? | :* 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? | ||
| − | |||
:* Need more client software to support SMI-S -- Like the bet the farm idea, what do we do to increase adoption. | :* Need more client software to support SMI-S -- Like the bet the farm idea, what do we do to increase adoption. | ||
:* Client software coded for SMI-S vs client software coded for specific device CIM model | :* Client software coded for SMI-S vs client software coded for specific device CIM model | ||
:* Multi-tennant CIMOM | :* Multi-tennant CIMOM | ||
:* CIMOM Coexistence on Server | :* CIMOM Coexistence on Server | ||
| − | :* Host profiles have been lagging adoption. | + | :* Host profiles have been lagging adoption. |
| − | :* Aperi has | + | :* 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. |
| − | :* SNIA starting | + | :* SNIA starting up SMI-S developers group where engineers (open to all) can ask questions, and get FAQ. |
:* Installation checklist | :* Installation checklist | ||
| + | :* | ||
Revision as of 16:39, 14 March 2008
This page is for communicating thoughts and ideas on works in progress to the workgroup.
Known Issues
- Configuration and Setup -- Setting up and configuring the CIM software.
- Specification/SMI-S Level issues
- Consistency -- Different implementations tend to do things slightly differently even if they don't have to.
- 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.
- 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?
- Spec changes too quickly/much -- This makes it difficult for exploiters to code solutions as everything becomes a moving target.
- Problem Profiles (e.g., not keeping up with other work) -- For example, Copy Services, Host Based Raid, etc.
- 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.
- 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.
- Scalability and Performance -- like the stability item above, this becomes important when we try to get customers to really use this stuff.
- Stress Testing -- how to we ensure that we've met stability?
- Embedding vs Proxy -- Seems like embedding makes for better, more stable infrastructures but isn't always possible?
- Single standardized CIMOM? Do we want to define a single CIMOM that everyone should use?
- Event Management -- Indications has some problems, we should fix it?
- 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?
- Need more client software to support SMI-S -- Like the bet the farm idea, what do we do to increase adoption.
- Client software coded for SMI-S vs client software coded for specific device CIM model
- Multi-tennant CIMOM
- CIMOM Coexistence on Server
- Host profiles have been lagging adoption.
- 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.
- SNIA starting up SMI-S developers group where engineers (open to all) can ask questions, and get FAQ.
- Installation checklist