Note: Copying the list, so that others can participate.
On 04/25/2012 12:14 AM, Tony Asleson wrote:
> On 04/24/2012 12:39 PM, Deepak C Shetty wrote:
>> Since the executable name is smispy_lsmplugin, I was thinking the options
>> will be such that it will map to the SMIS terminology. So should there be a
>> place somewhere where people reading SMIS can help map CreateStorage-
>> HardwareID to --create-initiator ? CIM/SMI-S itself is so abstracted
>> that its
>> hard to understand easily, and if we are creating more mappings, its better
>> to document I feel. This also helps users to know which profiles/attr of
>> SMIS map to which options of the smispy, what say ?
> This seems reasonable, where are you suggesting we document these mappings?
I would suggest we start with the libStorageMgmt wiki ?
Other option would be to have a mappings file as part of the src git,
but on the wiki its easier for developers and users both to search
> The way the code is architected, the command line arguments/help are
> implemented in one spot. Thus any plug-in written in python gets the
> command line functionality automatically. We cannot change the command
> line/help without it showing up for all plug-ins unless we break it out
> and duplicate. Something I would like to avoid :-) We could possibly
> add some extension mechanism to allow for plug-in specific additional help.
I agree, not looking at changing the option names itself, but
looking at how a user can map what SMIS functionality map
to which lsm options.
> Note: Normally users will be invoking lsmcli, not smispy_lsmplugin
Did you mean lsmclipy ? From VDSM - lsm integration perspective,
it would have to use lsmclipy or smispy_lsmplugin, right ? How are they
One another naive question... I was looking at libStorageMgmt as
having a generic part (which is where SMIS fits in) and plugin part
(which is where vendor specific code fits in).
smispy_lsmplugin fits in the generic part of vendor specific part ?
Name is confusing, since it has smis and plugin both :)