module for Redfish

[bwgartner]

Description of Issue/Question

Similar to salt.modules.impi/salt.modules.ilo/salt.modules.drac, it seems reasonable to have a salt.modules.redfish one to eventually cover more BMCs and expose integration with these APIs.

Setup

(Please provide relevant configs and/or SLS files (Be sure to remove sensitive info).)

As background, review http://redfish.dmtf.org/ for context and available APIs for integration. FWIW, there may need to be some level of discovery for compliant BMCs, as the vendor can provide custom namespace APIs (or have some further nested modularity).

Steps to Reproduce Issue

(Include debug logs if possible and relevant.)

Currently not available, so a feature request to have one created/implemented.

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

Missing from trunk set of modules

[cro]

Just some initial thoughts, this might benefit from being implemented as a proxy minion so Salt can target redfish endpoints like minions. I need to write up some ideas I have on a pattern that can be used so modules & states that are written for proxy minions can be re-used outside the proxy for one-off commands (e.g. I just need to pxe boot this one blade, why do I need to setup a whole proxy minion?).

[cro]

Reference implementation of a redfish client in python: https://github.com/devananda/python-redfish

[kevinquinnyo]

I didn't realize there was actually a drac module in salt. I only use the ipmi module currently. I guess the underlying pyghmi python module is able to handle most commands regardless of real IPMI or dell's DRAC system.

From a code design perspective it makes me wonder if there should be a high-level abstraction/wrapper salt module called something like oob.py (out of band) that could take an oob_type or oob_vendor keyword argument and decide which underlying module, ipmi.py, drac.py, redfish.py to use.

Does that make sense? I could definitely help with creating the redfish module soon since I'm going to have some new devices at my disposal that implement the newer Redfish firmware.

[joesusecom]

Is anyone working on this? Seems that Ansible has pretty complete support for Redfish.

[kevinquinnyo]

@joesusecom I'm not. I got sidetracked with other things and never got a hold of devices with Redfish support to test with. But it feels right to me that there should be a higher level abstraction for out-of-band management like I described above. Does anyone have any thoughts on that? Either way, saltstack definitely needs a redfish module, but I think it would be nice to be able to do OOB things to any device, and be able to specify the "driver", be it ipmi, drac (fake/kind-of ipmi), or redfish.

[The-Loeki]

We've recently started looking at it, but the state of the art doesn't seem to be there yet. I strongly believe neither Salt nor anyone will be served well with a Salt-specific RedFish library. Rather, the support should leverage a wider supported library.

That seems to be OpenStack's Python library (https://github.com/openstack/python-redfish).
I started toying with that, but it seems little more than a POC for now and development seems slow.

@joesusecom would you care to elaborate a bit on Ansible's support? I can't seem to find any after a quick Google; perhaps that'll lead to some good library which might be leveraged for this purpose.

I also noted that Dell DRAC's have a REST API based on WS-*, but HP's iLO's REST seems to be RedFish as well; it might be that some well-written library for HP iLO's turns out to be RedFish compliant.

These problems aren't helped by the fact that RedFish is pretty new; docs seem rather scarce and support for it is rare in our machine park, with support trickling in in 2016Q2+ machines/firmwares from the top of my head.

[joesusecom]

I attended a session at Red Hat Summit about this. It turns out that indeed the current Ansible Redfish support has been tested for and developed against Dell iDrac only. And it's not part of upstream Ansible yet.

I'll try to get some help from our hardware partners to get access to actual Redfish hardware. Ideally I want the vendors to own the support for their implementations. At least on the Python library level.

In general, I agree on the more generic "out of band" module approach, but there's a fine line between over-generalizing things and being too implementation-specific. So this needs some thought on the API side.

[joesusecom]

Is there any progress on Redfish integration? I see Redfish integration maturing for Ansible and in OpenStack Ironic. We should make sure Salt isn't left behind.

[Armadill0]

I'm also highly interested in that. Our Supermicro stuff also supports the Redfish API.

This would help us a lot to automate our bare-metal provisioning in a much simpler way via Salt.

[joesusecom]

We've created a research project (https://github.com/openSUSE/salt-redfish) that we'll use for prototyping and collecting ideas. Once there's code that's good enough for pull requests into the main Salt project, we'll do so.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[mchugh19]

Not stale

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[damon-atkins]

Last commit https://github.com/openSUSE/salt-redfish/commits/master/ June 2019