The idea is that very little should be baked into the 10.8 image itself. After deploying an image, scripts launched by the deploy studio workflow should bring the system up from 0 to puppetized. Puppetagain will do the rest. Post image scripts will: * set hostname and fqdn * install puppet prerequisite packages (e.g. puppet and facter) * run puppetize.sh
You'll probably want to set puppetize.sh up to run at first boot, rather than running it in the deploy process? Or is that when the post-scripts run?
not a problem since we can set the post scripts to exec on first boot :-)
Workflow created: * Partition and format /dev/disk0 and /dev/disk1 * restore 10.8 image * install puppet and facter * script - remove hardcoded network routes
The workflow is setup and successfully deploying a bootable 10.8 image. I did run into some problems with the set_hostname and the puppetize.sh script. I'll have to dig deeper into this tomorrow.
The issues with set_hostname and puppetize.sh were caused by the order and stages in which they were being called. Because the network fix-it script was being called in second stage, network was unavailable for dns queries until the next reboot. Firing off the network fix-it script before the first post-imaging reboot allowed for the second stage to have a working network environment. Instead of calling puppetize.sh directly from the finalize scripts during the second stage, it will be added as a LaunchDaemon and enabled during the second stage. This will allow the system to be accessed if the puppetize.sh script falls over otherwise it would hangup the entire second stage.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Component: Server Operations: RelEng → RelOps
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.