I was thinking about the pain around configuring genesis images, and it struck me that we could completely remove any configuration necessary to make a live image by moving genesis-specific setup into an at-runtime configuration like cloud-init. Instead of running scripts to install ruby/genesis gems, configure specific things about the bootable image, we could just distribute a cloud-init yaml that sets up genesis at boot.
That way, users could just boot any live image they want (lets say centos7) and tweak the cloud-init config as they see fit (perhaps they want ruby 1.9, or some extra packages installed). This would provide a very clean method for downstreams to configure genesis to do whatever they want, like adding ssh authorized keys, changing root pw, installing extra software, fetching configs, adding users, etc without needing to rebuild and deploy a new image.
I was thinking about the pain around configuring genesis images, and it struck me that we could completely remove any configuration necessary to make a live image by moving genesis-specific setup into an at-runtime configuration like
cloud-init. Instead of running scripts to install ruby/genesis gems, configure specific things about the bootable image, we could just distribute a cloud-init yaml that sets up genesis at boot.That way, users could just boot any live image they want (lets say centos7) and tweak the cloud-init config as they see fit (perhaps they want ruby 1.9, or some extra packages installed). This would provide a very clean method for downstreams to configure genesis to do whatever they want, like adding ssh authorized keys, changing root pw, installing extra software, fetching configs, adding users, etc without needing to rebuild and deploy a new image.