Instructions for spooling up an instance
I understand you create a flavor and an image (which can be customized with the properties from https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) which can then be fed to openstack server create thingie. But, where is the script (think something like kickstart to see what I have in mind; if I am off, I am off) that defines how the hard drive will be partitioned and which interfaces (if more than one) will be turned on and which will be left untouched. You know, housekeeping things that are done before you feed the "--user-data" stuff. Where is that defined? Can I customize it?
On Wed, Jul 17, 2019, at 5:51 AM, Mauricio Tavares wrote:
I understand you create a flavor and an image (which can becustomized with the properties from https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) which can then be fed to openstack server create thingie. But, where is the script (think something like kickstart to see what I have in mind; if I am off, I am off) that defines how the hard drive will be partitioned and which interfaces (if more than one) will be turned on and which will be left untouched. You know, housekeeping things that are done before you feed the "--user-data" stuff. Where is that defined? Can I customize it?
The two major ways you manage this is via your image builds (this is pre boot) and via a post boot manager like cloud-init or glean.
With your image build you can preinstall all of the software you need (and configure it too). You can also configure disk partitioning. The tool the OpenDev Infra team uses this for all of our test node images and some of our control plane images is called diskimage-builder [0]. This tool can partition images using both mbr and gpt tables.
For post boot management we use glean [1] which is a very simple post boot manager that can add ssh authorized keys to the root user and configure network interface. Cloud-init [2] is a far more configurable tool but I'm not super familiar with it at this point (due to using glean).
Long story short that means bake what you can into the image then rely on a tool like glean or cloud-init to handle post boot actions that differ from instance to instance (like network interfaces).
[0] https://docs.openstack.org/diskimage-builder/latest/ [1] https://docs.openstack.org/infra/glean/ [2] https://cloudinit.readthedocs.io/en/latest/
Hope this helps, Clark
On 2019-07-17 12:48:53 -0700 (-0700), Clark Boylan wrote: [...]
With your image build you can preinstall all of the software you need (and configure it too). You can also configure disk partitioning. The tool the OpenDev Infra team uses this for all of our test node images and some of our control plane images is called diskimage-builder [0]. This tool can partition images using both mbr and gpt tables.
[...]
I gather there's another popular alternative, which is to boot a server instance with an ISO of an operating system installer image attached, use that to configure the supplied root disk and install software into it, then shut that down and create a snapshot of the resulting instance's rootfs to boot additional instances from. It's a more traditional analog to how you'd do server installation in classic non-cloudy environments, but some folks still seem to prefer it over creating images of fully-working servers and then uploading those. That said, I'd recommend sticking to using/modifying officially provided "cloud" images from the distros you want since they do some useful things like wiping system identifiers and host keys so that they're regenerated independently on each new instance booted from them (if you don't remember to do that on your custom images you can run afoul of support licensing contracts or create unnecessary security risks).
In case it helps, here's what Nova has to say about config drives:
https://docs.openstack.org/nova/latest/admin/config-drive.html
Thanks for all the info. Replying inline
On Wed, Jul 17, 2019 at 4:47 PM Jeremy Stanley fungi@yuggoth.org wrote:
On 2019-07-17 12:48:53 -0700 (-0700), Clark Boylan wrote: [...]
With your image build you can preinstall all of the software you need (and configure it too). You can also configure disk partitioning. The tool the OpenDev Infra team uses this for all of our test node images and some of our control plane images is called diskimage-builder [0]. This tool can partition images using both mbr and gpt tables.
[...]
Thank you for the info on diskimage-builder. From what I understood in https://docs.openstack.org/diskimage-builder/latest/user_guide/building_an_i..., its output is a partitoned disk image configured whatever way you want, which can then be fed to "openstack server create." After that it is a matter of installing the OS as you would in https://docs.openstack.org/image-guide/ubuntu-image.html. Correct me if I am wrong but that means customization done before OS is installed required separate images. Stuff like adding network cards can be customized because even adding the card itself can be done at any time.
I think I now understand that.
I gather there's another popular alternative, which is to boot a server instance with an ISO of an operating system installer image attached, use that to configure the supplied root disk and install software into it, then shut that down and create a snapshot of the resulting instance's rootfs to boot additional instances from. It's a more traditional analog to how you'd do server installation in classic non-cloudy environments, but some folks still seem to prefer it over creating images of fully-working servers and then uploading those. That said, I'd recommend sticking to using/modifying officially provided "cloud" images from the distros you want since they do some useful things like wiping system identifiers and host keys so that they're regenerated independently on each new instance booted from them (if you don't remember to do that on your custom images you can run afoul of support licensing contracts or create unnecessary security risks). -- Jeremy Stanley
I think the merit of having a secure barebones image and then using the usual suspects -- ansible, chef -- to install and configure packages cuts down on how many images you have to keep current on the hard drive. They can force server keys if needed. Having customized images with some software installed and configured will lead to faster deployment, however.
participants (4)
-
Clark Boylan
-
Eric Fried
-
Jeremy Stanley
-
Mauricio Tavares