[openstack-dev] [ironic] Extending python-dracclient to fetch System/iDrac resources

Anish Bhatt anish.bhatt at salesforce.com
Wed Sep 14 18:39:36 UTC 2016


That would be pretty easy to do. I did not pick InstanceId simply because
the code wasn't using it right now. Whatever the choice, the chosen key is
simply used as a key in the results dict so all of this would be
transparent to the users anyways.
-Anish

On Wed, Sep 14, 2016 at 11:33 AM, <Christopher.Dearborn at dell.com> wrote:

> I vote for parsing everything the same way.
>
>
>
> Note that the unique identifier for these attributes is InstanceID.  See
> https://www.vmware.com/support/developer/cim-sdk/
> smash/u2/ga/apirefdoc/CIM_BIOSString.html for example.  I think it’s fine
> to include GroupID and whatever attributes are needed, but InstanceID
> should be used as the key.  We shouldn’t be making up other keys to use
> since we already have a perfectly good one that’s being supplied.
>
>
>
> Chris
>
> -----Original Message-----
> From: Miles Gould [mailto:mgould at redhat.com]
> Sent: Wednesday, September 14, 2016 7:46 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ironic] Extending python-dracclient to fetch
> System/iDrac resources
>
> On 13/09/16 20:30, Anish Bhatt wrote:
> > Is parsing iDrac/System attributes differently from BIOS attributes
> > the correct approach here (this will also make it match racadm
> > output), or should I be changing all Attributes to be parsed the same
> way ?
>
> "Parse everything the same way" sounds like the simpler and less brittle
> option; is there a good reason *not* to consider GroupID for BIOS
> attributes?
>
> Miles
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
One socket to bind them all
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160914/78929c24/attachment.html>


More information about the OpenStack-dev mailing list