Difference between revisions of "Aperi Launch in Context Enablement Workgroup"

Upcoming meetings:

Agenda

Key Documents Under Discussion

Work Page

2008/03/20:

• We had a good discussion regarding the overall strategy and reviewed the material posted in the work page. In general, the workgroup feels that this is the right general direction.
• There was a discussion about security, and it was felt from the workgroup that we did not want to manage keys/credentials within the CIM Agent, but will need to expose the authentication mechanisms required by the LIC access point.
• John would like to see more discussion about the kinds of things that can be launched to. E.g., what will it do, and how do we want to represent those services? Martine suggests wrapping that activity with an overall use-case discussion where we can tie it back to user actions (e.g., user wants to set various settings of Brocade switch from Aperi, launches to the control panel via LIC, etc.). Pretty trivial to write out the use cases, but they should help communicate to a larger audience what we're trying to define with the "launch types" or whatnot.

Action Items

Martine -- To post instance diagram of the interaction between the LIC point and services/domains

John -- To post instance diagram around the PRP interactions

2008/03/05:

• We did a quick kickoff at the start (purpose, process discussion, etc.)

Process

Phase 1 -- Education ramp-up and brainstorming.

Phase 2 -- Develop proposal.

Phase 3 -- write whitepaper for final delivery to Aperi and SMI-S.

General Requirements

• Need to support vendor extensions
• Be able to discover element manager capabilities (no a priori knowledge required)
• Need to support general extensibility from general model (not just overrides)
• Single sign-on authentication/authroisation if/when element manager supports it
• Align the LIC enablement with established SMI-S model (whenever possible). This might be through design structure (e.g., how we associate objects in the model) and/or can be achieved by recognizing that this feature bridges the gap between the SMI-S data model and element managers; so we need to stay focussed to use the "language" of SMI-S when appropriate.

Proposed Mechanism

• Leverage the current Access Points Subprofile to establish linkages to the SMI-S data model; perhaps by additional associations to ProfileRegisteredProfile, ComputerSystem, and/or Service instances.

Action Items

Martine -- to create additional Wiki page to contain design ideas/thoughts.

Martine -- to upload some initial thoughts on the SMI-S modelling.

Dave -- to upload an overview / description of the LIC descriptor file.