Hi Stan,
Good to see you on Open Compute lists ! We will clearly have a look to
Redfish and its associated features even if I am worried that it does
implement far too much things compared to what we really need.
Redfish will provide us, support functions for provisioning but not the
global infrastructure required to bootstrap O/S, run hardware detection,
auto configuration as well as configuration management (aka FRU
management and spare parts). I loved to see also automatic
decomissioning in case of hardware failure detection.
All of this is a huge amount of work, and will take time. We just need
to define on which tool we want to rely as to be sure that OCP upcoming
implementation can be manageable through the same software stack, as
currently OpenRack and OCS are far from being compatible.
vejmarie
Le 09/12/15 12:01, Odinot, Stanislas a écrit :
Hi Jean Marie,
I don’t have your expertise, but personally I would consider to stick
to RedFish for the fixed function/command already implemented in the
1.0 specs and then extend the APIs with your API commands (from you
RuggedPOD you defined here
<http://ruggedpod.qyshare.com/documentation/software/specifications/ruggedpod_firmware.html#current-api-calls>)
like OEM are doing right now.
In SuperMicro document below, see page 13, there is an “OEM Features”
section which describe how they added some dedicate features and
parameters
https://www.supermicro.com/manuals/other/RedfishRefGuide.pdf
/3.5.1 SMTP///
/SMTP is implemented at "redfish/v1/Managers/1" under OEM category.
This feature is identical to IPMI web -> Configuration->SMTP. User can
GET/PATCH the same info for SMTP. Information will be identical in
both places. User can use the [PATCH] HTTP method to modify properties./
//
/3.5.2 FanMode /
/This is a Supermicro OEM feature that is implemented under
/redfish/v1/Chassis. Users can Patch (modify) the Fan Mode using the
following values.///
SuperMicro isn’t the only OEM implementing RedFish as you certainly know.
Dell is using it on G5
(http://www.intel.com/content/dam/www/public/us/en/documents/presentation/idf15-dell-dcs-g5-presentation.pdf)
Hp on Proliant
(http://community.hpe.com/t5/Servers-The-Right-Compute/Redfish-1-0-and-HP-ProLiant-the-perfect-pair-for-a-software/ba-p/6798419#.VmgI8XarT4Y
See HP implementation here:
http://h22208.www2.hpe.com/eginfolib/servers/docs/HPRestfultool/iLo4/data_model_reference.html
Again there is room for adding your own APIs command:
You might have some limitation on PXE boot for example or else, but
that’s where my knowledge is limited.
My 2 cents,
Stan
*Stanislas Odinot**
*Intel Enterprise Pre-sales
*From:*ocp-europe-boun...@lists.opencompute.org
[mailto:ocp-europe-boun...@lists.opencompute.org] *On Behalf Of
*Jean-Marie Verdun
*Sent:* Monday, December 7, 2015 3:21 PM
*To:* ocp-eur...@lists.opencompute.org;
opencompute-openr...@lists.opencompute.org;
opencompute-hardwarem...@lists.opencompute.org;
opencompute-ser...@lists.opencompute.org;
opencompute-networking@lists.opencompute.org
*Subject:* [Ocp-europe] Open Compute system provisioning
Hi,
Open Compute hardware is getting momentum in Europe, and we are
getting more and more request for automatic tools to provision systems.
It happens that it is not that an easy task mostly because we do not
have a unified API per hardware equipement to run provisioning or even
local add on equipment like a small RBpi in the rack to gain control
of the systems.
I started to think about this issue, and needs your feedback before
starting coding anything. I do not know how to call this project, so
if you have some ideas feel free.
Context:
- I am an end user which is receiving a brand new open compute
equipment, which can contains, network switch, jbod, storage server,
network server (proxy), and plenty of other functions. I do not have
physical access to this equipment (it is somewhere else, far away from
me).
- We are currently assuming that the rack is properly cabled with a
remote management network.
- We are assuming that the rack is NOT connected to production network
as long as it is not configured.
Does this hypthesis are closed to real life ?
The issues:
- I need to remotly identify system configuration (I am not supposed
to know it, this is a new rack, and somebody else placed the order for
me), and integrate it into an existing DC.
- I have no way to upload operating systems on the machine and need to
find one.
One of my idea was to work on a RaspberryPI O/S which could be used to
provision systems. The system could be wired by a local operator. It
might be needing 3 network interfaces (in this case we might have to
consider a different board). The setup steps could be:
- Connect the PI on the management switch management port
- Connect the PI on management switch
- Connect the PI on the production network fabric
- PI is providing DHCP service on the management network. DHCP is used
to discover local equipment including switches.
- The system allocate management interface IP address.
- Hardware detection is performed and initial firmware upload to the
network switches are performed (Cumulus or Pica8).
- Then IPMI or remote management systems can perform a DHCP discover
and get an IP address from the PI system, which is also configured as
a TFTP/BOOTP environement and detect automatically hardware and upload
a basic kernel image adapted for the hardware platform aftr having
sent an IPMI turned on command.
- A system configuration check is performed with a configuration dump
(dmidecode/lspci etc ...) and stored into the PI
- An "end-user" baremetal O/S can be automatically uploaded at the
next boot
- A JBOD configuration can be performed after baremetal provisioning
I might be missing a lot of things, but the idea is to have a local
small board which can do all this provisioning tasks based on a
Restfull API. This is roughly what we are trying to do in RuggedPOD,
and we are still far from end results.
Some of you will tell me that MaaS is able to do it, but I am not sure
that it is that easy to do, and that it has been designed to work from 0.
This could be seen as a multinode management issue etc ...
I am just trying to know who is working on such things and who could
be interested. We are trying to formalize a little all of this in
RuggedPOD and use the plateform as a v1, but RuggedPOD is simplier
than OpenRack. We have some demands on Open Rack systems, this is why
I was wondering if some of you could be interested to have a look.
http://ruggedpod.qyshare.com/documentation//software/specifications/ruggedpod_firmware.html
<http://ruggedpod.qyshare.com/documentation/software/specifications/ruggedpod_firmware.html>
We are thinking at switching to Redfish, but we have pressure to move
forward before the global spec got released :(.
vejmarie
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Opencompute-openrack mailing list
Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-openrack
opencompute-openr...@lists.opencompute.org
http://lists.opencompute.org/mailman/listinfo/opencompute-openrack
--
Jean-Marie Verdun
*Splitted-Desktop Systems*
President
Batiment Aristote
Parc des Algorithmes
Route de l'orme des merisiers
91190 Saint Aubin FRANCE
jean-marie.ver...@splitted-desktop.com
Splitted-Desktop Systems is a proud member of the Open Compute
Foundation
and a Gold member till July '16. We can provide you consulting and
engineering
services related to any OCP hardware. We also drive RuggedPOD and Daap Open
Hardware projects
_______________________________________________
opencompute-networking mailing list
Unsubscribe: http://lists.opencompute.org/mailman/options/opencompute-networking
opencompute-networking@lists.opencompute.org
http://lists.opencompute.org/mailman/listinfo/opencompute-networking
