Genesis – A tool for data center automation
tumblr.github.io
tumblr.github.io
As a shop that uses collins, we wrote our own replacement for invisible touch called alchemy linux. The key difference here seems to be that genesis uses scripts embedded into the image, where as alchemy gets the scripts dynamically from its PXE server, and is more of a dumb job runner.
Genesis does not use scripts embedded into the image. In fact this was the original design of IT and much of the reason IT was not released and Genesis was created.
The difference is that it uses YAML for configuration instead of Red Hat's Kickstart format that also powers their Anaconda installer, is far more minimal, and seems to be intended for configuration on a lower level than Cobbler is typically used for.
Quickly skimming the modules, they're actually remarkably unsophisticated. Most of it just directly shells out to programs like Dell's firmware tools, or ntpdate (which is officially deprecated, funnily enough).
Genesis tho is intended for much more. It is both a linux image, a framework implementing a DSL which you can use to write tasks utilizing all of ruby.
Ex: Genesis allows you to configure hardware raid based on asset policies/attributes in Collins. Would this fall into "Policy-Based Provisioning?"
On "Open APIs and Plug-in Architecture", it is correct to state that Genesis is built around utilizing functionality from Collins, however there aren't specific limitation in Genesis which cannot be addressed to support other asset management systems, tho, this isn't a priority.
On "Dynamic Image Selection", currently we have an additional internal system that in conjunction with Collins provides support for OS versions, some aspects of this may at a later time be introduced into Genesis.
Along side Genesis we use additional internal tools that "provision" physical hardware using Kickstart specification.
One of the challenges with provisioning machines is bringing visibility to the process of provisioning while the machine is being provisioned. Kickstart and Anaconda installer aren't ideal from a visibility stand point.
Genesis in addition to providing a means to discover hardware at the DC allows for some provisioning automation to be moved into ruby code instead of Kickstart. Internally we are experimenting with additional solutions other than using Kickstart.
On the title itself, I think it is correct, tho requires more nuanced interpretation.