On Mon, Dec 7, 2015 at 8:21 AM, Jean-Marie Verdun < jean-marie.ver...@splitted-desktop.com> wrote:
> 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. > Hi Jean-Marie, Is there something we can improve in MaaS to support the above use cases? I'm happy to help. I believe MaaS supports all of the above and/or is target for the next release (storage configuration, etc.). * https://www.youtube.com/watch?v=a4P7lvIUc5M * https://www.youtube.com/watch?v=Av8kd1Gci7s&feature=youtu.be&t=1165 David > 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 > > We are thinking at switching to Redfish, but we have pressure to move > forward before the global spec got released :(. > > > vejmarie > > > _______________________________________________ > Opencompute-hardwaremngt mailing list > Unsubscribe: > http://lists.opencompute.org/mailman/options/opencompute-hardwaremngt > > opencompute-hardwarem...@lists.opencompute.org > http://lists.opencompute.org/mailman/listinfo/opencompute-hardwaremngt > > -- David Duffey +1-512-850-6776 (work), +1-512-287-4289 (work fax)
_______________________________________________ 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
