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 6: | Line 6: | ||
:* Specification/SMI-S Level 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? | + | ::* '''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? |
| − | ::* 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? | + | ::* '''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. |
| − | ::* 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. | + | ::* '''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? |
| − | ::* 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. | + | :: |
| + | ::* '''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. | ||
:*Technology | :*Technology | ||
| − | ::* 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? | + | :: |
| − | ::* Event Management -- Indications has some problems, we should fix it? | + | ::* '''Single standardized CIMOM?''' Do we want to define a single CIMOM that everyone should use? |
| − | ::* Client software coded for SMI-S vs client software coded for specific device CIM model | + | :: |
| − | ::* Multi-tennant CIMOM | + | ::* '''Event Management''' -- Indications has some problems, we should fix it? |
| + | :: | ||
| + | ::* '''Client software coded for SMI-S vs client software coded for specific device CIM model''' | ||
| + | :: | ||
| + | ::* '''Multi-tennant CIMOM''' | ||
| + | :: | ||
::* CIMOM Coexistence on Server | ::* CIMOM Coexistence on Server | ||
:*Implementation/Adoption | :*Implementation/Adoption | ||
| − | ::* Scalability and Performance -- like the stability item, this becomes important when we try to get customers to really use this stuff. | + | ::* '''Scalability and Performance''' -- like the stability item, 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? | + | :: |
| − | ::* Configuration and Setup -- Setting up and configuring the CIM software. How do we make it easier for customers to deploy the software? | + | ::* '''Stress Testing''' -- how to we ensure that we've met stability? |
| − | ::* 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. | + | ::* '''Configuration and Setup''' -- Setting up and configuring the CIM software. How do we make it easier for customers to deploy the software? |
| − | ::* SNIA starting up SMI-S developers group where engineers (open to all) can ask questions, and get FAQ. | + | :: |
| − | ::* Installation checklist -- similar to the Configuration and Setup, we need to define/express clearly the requirements to install the software. | + | ::* '''Host profiles have been lagging adoption'''. |
| − | ::* 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? | + | :: |
| − | ::* Promote Element Managers to use SMI-S. | + | ::* '''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. |
| − | ::* Need more client software to support SMI-S -- Like the bet the farm idea, what do we do to increase adoption. | + | :: |
| − | ::* 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. | + | ::* '''SNIA starting up SMI-S developers group where engineers (open to all) can ask questions, and get FAQ'''. |
| + | :: | ||
| + | ::* '''Installation checklist''' -- similar to the Configuration and Setup, we need to define/express clearly the requirements to install the software. | ||
| + | :: | ||
| + | ::* '''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? | ||
| + | :: | ||
| + | ::* '''Promote Element Managers to use SMI-S'''. | ||
| + | :: | ||
| + | ::* '''Need more client software to support SMI-S''' -- Like the bet the farm idea, what do we do to increase adoption. | ||
| + | :: | ||
| + | ::* '''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. | ||
Revision as of 16:14, 28 March 2008
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?
-
- 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.
- Technology
- 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?
-
- Client software coded for SMI-S vs client software coded for specific device CIM model
-
- Multi-tennant CIMOM
-
- CIMOM Coexistence on Server
- Implementation/Adoption
- Scalability and Performance -- like the stability item, 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?
-
- Configuration and Setup -- Setting up and configuring the CIM software. How do we make it easier for customers to deploy the software?
-
- 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 -- similar to the Configuration and Setup, we need to define/express clearly the requirements to install the software.
-
- 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?
-
- Promote Element Managers to use SMI-S.
-
- Need more client software to support SMI-S -- Like the bet the farm idea, what do we do to increase adoption.
-
- 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.