Once upon a time, when you needed to "do stuff" to take care of a computer, you had to go there in person. By "do stuff", that means things like: turning it off and on, looking to see if the AC was working, were the tape or disk motors broken, were any of the red warning lights on, had the UPS tripped, and so forth. But, for many and obvious reasons, it was useful to do all this kind of stuff from a distance.
This led to the creation of "IPMI", which was built into most computers that were designed to be used in racks and datacenters. With IMPI, a team of sysadmins could remotely turn computers on and off, check temperature, fans, power, network carrier, installed cards and devices, and read off model numbers, part numbers, and serial numbers.
IPMI is currently being improved/replaced with a thing called "RedFish". RedFish does all the same sort of things, but it is designed in a way that is called "RESTful", which means it works the same way that web applications work, which makes it a lot easier to write tools that speak it. Another cool thing about RedFish is that it accidentally also looks like a complete database of a "computer like thing", and does it in a way that "things" can be inside "things" and connected to other "things" all within how the protocol works.
And then I had an idea...
Write a web application that scans the local network looking for RedFish servers, and then itself acts like a RedFish server that integrates all these other smaller RedFish servers.
You can even stack this, making it so at a higher level, one of these "RedFish aggregators" discovers and integrates the lower level ones, and so on up. Eventually you would have a top level one that would give you all the data and all the control over an entire datacenter or even larger set of data centers.
It wouldn't even be that terribly hard to write a small demonstration implementation. It would be a challenge to make it fast and efficient, and to properly handle caches and avoid accidental recursion loops, but it doesn't look like a really difficult one.
To use something like this for real, the logical place to put it would be in the network switches. But that used to be difficult, because production level network switches have been very closed and proprietary. However, that's changing. There is a new open source project spinning up right now, called "OpenSwitch". If I was to push this RedFish aggregator so that it would be real world useful, I would make it a be a module that runs in the reference OpenSwitch box.
How hard could it be?
This led to the creation of "IPMI", which was built into most computers that were designed to be used in racks and datacenters. With IMPI, a team of sysadmins could remotely turn computers on and off, check temperature, fans, power, network carrier, installed cards and devices, and read off model numbers, part numbers, and serial numbers.
IPMI is currently being improved/replaced with a thing called "RedFish". RedFish does all the same sort of things, but it is designed in a way that is called "RESTful", which means it works the same way that web applications work, which makes it a lot easier to write tools that speak it. Another cool thing about RedFish is that it accidentally also looks like a complete database of a "computer like thing", and does it in a way that "things" can be inside "things" and connected to other "things" all within how the protocol works.
And then I had an idea...
Write a web application that scans the local network looking for RedFish servers, and then itself acts like a RedFish server that integrates all these other smaller RedFish servers.
You can even stack this, making it so at a higher level, one of these "RedFish aggregators" discovers and integrates the lower level ones, and so on up. Eventually you would have a top level one that would give you all the data and all the control over an entire datacenter or even larger set of data centers.
It wouldn't even be that terribly hard to write a small demonstration implementation. It would be a challenge to make it fast and efficient, and to properly handle caches and avoid accidental recursion loops, but it doesn't look like a really difficult one.
To use something like this for real, the logical place to put it would be in the network switches. But that used to be difficult, because production level network switches have been very closed and proprietary. However, that's changing. There is a new open source project spinning up right now, called "OpenSwitch". If I was to push this RedFish aggregator so that it would be real world useful, I would make it a be a module that runs in the reference OpenSwitch box.
How hard could it be?
