So after taking a closer look, this appears to be a PXE installation and server provisioning tool not unlike Cobbler.
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).
On the modules, those included in the public repo by nature of not having specific to Tumblr's DC are unsophisticated.
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.
Looking through the bulleted list on Razor. One use case for Genesis that drove its development is "Auto-Discovered Real-Time Inventory Data".
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.
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.
You are correct in that Tumblr did not release Invisible Touch. Genesis is the outcome of lesson learned from IT.
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.
You are correct in that one use case for Genesis is hardware inventory taking, however Genesis is intended for use with Collins and shares aspects of automation with Collins and Phil (internal tool not currently Open Sourced).
On the title itself, I think it is correct, tho requires more nuanced interpretation.
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).