A provider for publishing Management Controller (Service Processor) information
Jan Safranek
jsafrane at redhat.com
Mon May 5 12:17:21 UTC 2014
Hello Praveen,
Find my comments inline, they are mostly related to style, to make the
MOF look more CIM-ish.
On 05/02/2014 12:12 AM, Praveen_Paladugu at Dell.com wrote:
> Based on the comments from the past threads, updated the MOF as follows
> and added some of my comments below, please take a look.
>
> [Description("Model an Out of Band Management Controller and capture its
> features and capabilities")]
>
> class LMI_BMC : CIM_ManagementController
>
> {
>
>
>
> [Description("This variable, should always capture the latest ipv4
> IP/s addresses of BMC.")]
>
> string IP4Addresses[];
>
>
>
> [Description("This variable, should always capture the latest ipv6
> IP/s addresses of BMC.")]
>
> string IP6Addresses[];
>
>
>
> [Description("The VLAN setting on the BMC NIC port.")]
>
> string VLAN;
>
>
>
> [Description("This variable will capture MAC address of the BMC.”)]
>
> string PermanentMACAddresses;
If the address is just one, then just 'PermanentMACAddress', without
'-es' suffix.
>
>
> [Description(“If BMC provides any user friendly interfaces like http,
> ftp etc, this variable will capture the related URL/s to interact with
> BMC.”)]
>
> string BMC_URL[];
Now the other way around... if there can be multiple URLs, then I would
add '-s' suffix to be consistent with IP4Addresses.
>
>
>
> /* COMMENT: If the following properties are rolledup into
> CIM_LogicalDevice, would a user enumerating LMI_BMC not be able to see
> these properties? Or is it just a matter of how the Enumeration function
> is defined for this class? */
>
>
>
> /*
>
> #Capture this information in IdentifyingDescriptions inherited from
> CIM_LogicalDevice
>
> #string Manufacturer_ID;
>
> #string Manufacturer;
>
> #string Model;
>
> */
What do you mean "rolledup into CIM_LogicalDevice"? There are no such
properties in CIM_LogicalDevices.
>
>
>
> [Description(“This variable will capture the version of the firmware
> installed on the BMC”)]
>
> string FirmwareVersion;
>
>
>
> [Description(“This Array will capture the list of protocols supported
> by the BMC”)]
>
> string SupportedProtos[];
>
>
>
> [Description(“This Array will capture the version of the supported
> protocol listed in the corresponding index of SupportedProtos ”)]
>
> string SupportedProtoVersion[];
If two arrays must have items at the same positions, they should have
'ArrayType("Indexed")' qualifier to describe that items in the array are
_not_ in arbitrary order:
[ArrayType("Indexed"), Description(...)]
string SupportedProtos[];
[ArrayType("Indexed"), Description(...)]
string SupportedProtoVersion[];
See DSP0004 for details.
>
>
>
>
> /*COMMENT: Should the below function assign a new virtual ip address to
> those already on the BMC? Or should the user be able to pass a list of
> IP addresses to overwrite the existing ones? Am leaning towards the
> latter option*/
>From the model perspective, both are possible. I would suggest to choose
the one that is the easiest to implement or is already implemented
somewhere else.
Just make sure it's functionally complete, so if there is a method to
add an IP address, there should be also method to remove it.
Out of curiositym is is possible for BMC to have multiple IPv4 addresses
at all? I have a feeling that IPMI does not support that, I am not sure
though.
>
> [Description("Function to add a new IPv4 address to BMC."
>
> "If the operation of setting the IP Address succeeds, return 0"
>
> "If command fails, return 1"
>
> "If the provided input is not a valid IP address, return 2"
>
> )]
We use ValueMap in CIM to describe return codes instead of free-form text:
[ Description(...),
ValueMap("0", "1", "2"),
Values("Success", "Failed", "Invalid argument")]
uint32 set_IP4Address
>
> uint32 set_IP4Address(
Also matter of taste/style: CIM uses CamelCase and very little
underscores, i.e. SetIP4Address(...) looks somewhat nicer.
>
> [IN, Description ("Set the IP address of the BMC, to the
> input value")]
>
> string Input_IP,
>
> [IN, Description ("Set the netmask to this input value")]
>
> string Input_Netmask,
>
> [IN, Description ("Set the gateway this input value")]
>
> string Input_Gateway);
I don't think it's necessary to use 'Input_' prefix, there already is
'IN' qualifier to tell if it is input/output argument. It's just matter
of style though.
>
>
>
>
>
> [Description("Function to assign a new IPv6 address to BMC."
>
> "If the operation of setting the IP Address succeeds, return 0"
>
> "If IPMI command fails, return 1"
>
> "If the provided input is not a valid IP address, return 2"
>
> )]
>
> uint32 set_IP6Address(
>
> [IN, Description ("Set the IP address of the BMC, to the
> input value")]
>
> string Input_IP6Address,
>
> [IN, Description ("Set the netmask to this input value")]
>
> string Input_Netmask,
>
> [IN, Description ("Set the gateway on BMC to this input
> value")]
>
> string Input_Gateway);
>
>
>
>
>
>
>
> [Description("Function to assign a VLAN ID to BMC."
>
> "If the operation of setting the VLAN ID succeeds, return 0"
>
> "If command fails, return 1"
>
> "If the provided input is not a valid VLAN ID, return 2"
>
> )]
>
> uint32 set_VLAN(
>
> [IN, Description("Set the VLAN ID of BMC NIC to this
> input value")]
>
> string Input_Vlan
>
> );
>
>
>
>
>
> [Description("Some servers have dedicated NIC attached to BMC, some
> share a LOM used for host n/w communications. This function will let the
> user determine which the case is."
>
> "dedicated: will let the user know that BMC is using a dedicated NIC"
>
> "A response like LOM1 will let the user know that BMC is sharing
> LOM1 of the server with the OS."
Again, returning uint32 with defined ValueMap is nicer that just passing
strings.
>
> )]
>
> string get_active_nic();
>
>
>
>
>
> };
Jan
More information about the openlmi-devel
mailing list