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? 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. | + | ::* '''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? | + | ::* '''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. | + | ::* '''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 | :*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? | ::* '''Embedding vs Proxy''' -- Seems like embedding makes for better, more stable infrastructures but isn't always possible? | ||
:: | :: | ||
| Line 30: | Line 29: | ||
:: | :: | ||
::* CIMOM Coexistence on Server | ::* CIMOM Coexistence on Server | ||
| + | |||
:*Implementation/Adoption | :*Implementation/Adoption | ||
Revision as of 16:46, 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? 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?
-
- 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.