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

Upcoming meetings:

Agenda

Key Documents Under Discussion

Work Page

2008/07/30

• Participants

• Martine Wedlake
• Duane Baldwin

• Notes

• The scoping document was presented to the SMI-S Core TWG during last week's SNIA meetings and we collected some very useful information from it which we (the authors) will incorporate.
• Given the SNIA IP Policy, the details of the comments may only be disclosed to SNIA members; so we will not discuss details of the Scoping document within the Aperi organisation; however, we can provide status and general information to keep everyone in the loop. Because of this, I will propose returning to our "normal" bi-weekly (fortnightly) meeting schedule for the Aperi workgroup; we will continue to work the other elements (e.g., descriptor file standardisation, SSO, etc.).

2008/07/16

• Participants

• Martine Wedlake
• Duane Baldwin

• Notes

• We went through the scoping document. As part of the review, Martine will add some examples in the use cases.

2008/07/09

• Participants

• Martine Wedlake
• Dave Wolfe
• Duane Baldwin
• John Crandall

• Notes

• We went over the MOF for the SNIA_LICCapabilities class.
• Dave would like to see a means whereby we can generalise the supported actions such that we can maintain some context for the operation, even if the specific task is not in the list of possible actions (as defined by the MOF). We chatted about this for a while; options included:

• Supported Actions could be a two dimensional array. The first dimension would be the category or context of the operation (e.g., volume, storage pool, extent, etc.) and the second dimension would be the specific operation (view, create, modify, delete, etc.). In the operation dimension, we could have "unknown" which would still allow a client to determine the context (e.g., volume), even if it did not know the specific operation.
• Use a parallel array for the context or category that would list the object type manipulated (e.g., volume, storage pool, extent, etc.). We would leave the Supported Action[] array alone.
• Use an association from the LIC point to the profile registration to identify the domain for the launch point. We actually talked about this some time ago, but discarded it as it's too easy to get it confused with the normal associations between profiles and system elements.
• Augment the existing list with a general-purpose entry at the head of each grouping. For example, "volume", "create volume", "delete volume". I'll modify my draft mof to match this proposal.

• We need to add more operations that do not overlap with SMI-S (e.g., power supplies) and emphasise the value in terms of launching to non-SMIS function; otherwise we may get dragged into a discussion of LIC vs SMI-S.
• Martine to arrange time during SNIA Symposium to discuss LIC proposal.
• Martine to set up weekly meetings with different time-slot (to avoid core TWG meeting).

2008/06/25

• Participants

• Martine Wedlake
• Chris King
• Dave Wolfe
• Sunil Bharadwaj
• John Crandall
• Al Heitman
• Duane Baldwin
• Michelle Lowe

• Notes

• SNIA Standardisation

• Process (Scoping Document vs SCR, etc.). We need to work on the scoping document before SCR. Scoping documents are how you propose new content for SMI-S.
• Current Status.

• Scoping document has been drafted and we went over it quickly. Martine will take ownership of the file to make changes to it and propose it through the Core TWG.
• Comments on draft: Make it more mof-like, SNIA_LICDescriptor.Id should be instanceId, SNIA_LICDescriptor.Name and Description should change to something else (maybe propertyName, propertyDescription?), use indexed array qualifiers for arrays, add Client Vendors (Brocade, IBM, aperi), Provider Vendors (Brocade, IBM, LSI -- check w/Jenny?), Update section 2.4 to put Martine in as author.
• Martine to move the LIC meeting to avoid colliding with the SNIA Core meeting.

• Peer-to-Peer LIC Descriptor File

• Current Status
• Where to standardise this work? SNIA doesn't make sense for non-SMI-S stuff...

2008/06/11

• Participants

• Martine Wedlake
• Al Heitman
• Sunil Bharadwaj
• Dave Wolfe

• Notes

• SNIA Standards Writeup (SCR)

• Nothing to report yet; I will work with Duane off-line to see if we can make movement on this item.

• Peer-to-Peer LIC Descriptor File

• Have something ready, but needs to scrub for open source delivery.
• Describes:

• The capabilities of a launch point and mapping for when a capability should be shown in a console application.
• Launch point parameters.
• What way the launch point should be activated; e.g., URL, CLI, Java web start.

• Prototype Work

• Aperi development will begin in September
• We'll try to do some simple quick 'n dirty prototypes before then. E.g., a simple java application that fetches information from the CIM Agent and launches a browser.

2008/05/28

• Participants

• Martine Wedlake
• Dave Wolfe
• Al Heitman

• Status

• LiC Standardisation -- Not much happened as of last meeting; we're still in the process of drafting the profile and SCR documents.

• Notes

• LiC Backdoor -- We need a mechanism to hook in LiC for targets that are not represented by a CIM/SMI-S data model. Model will be released in mid-July.

2008/04/30

• Participants

• Martine Wedlake
• Jenny Monesson
• Dave Wolfe
• Duane Baldwin

• Went through the latest update of the LIC model. Feedback was:

• Create a new InfoFormat for the RemoteServiceAccessPoint instead of using 1 (other).
• Use of named parameters in the URL-template is much better than by index position.
• Consider changing the syntax for named parameters from "${name}" to "<name>" to match standard message format.
• Create LICElementDescriptor (derives from CIM_Dependency) instead of just CIM_Dependency

• Next Steps

• Standards Work

• Martine -- present model to CSSC
• Duane/Martine -- work on SCR

• Prototyping

• Jenny -- Look into prototyping model in DS4k as static instances.
• DaveW/Jenny -- Look into prototyping Aperi SRM.

2008/04/16

• Participants

• Martine Wedlake
• Jenny Monesson
• Al Heitman
• Duane Baldwin
• Al Heitman

• We went over the LIC model again to determine what associations we want to use (where the ??? are now)

• For the LICCapability to RemoteServiceAccessPoint, we determined that ElementCapabilities will work fine.
• For the LICDescriptor to RemoteServiceAccessPoint, we determined that we'd like to use ElementSettingData (which requires LICDescriptor to specialise from SettingData, which makes sense anyway).
• We decided to remove the association between the RemoteServiceAccessPoint and the RegisteredProfile. This link wasn't really adding anything above the capabilities anyway...

• Next Steps:

• Martine to patch up diagram.
• Martine to create concrete examples of LICCapabilities (specialising into separate classes for categories; such as LICVolumeCapabilities, LICPoolCapabilities, LICHostCapabilities, etc.).
• Martine to work on Draft document (following DMTF PUG format; but probably in Word).
• Duane to work on Scoping Document (1 to 2 pages describing the profile and it's benefits, etc.).

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.