I've been doing some experiments for bz#1283701, supporting running docker at install time to pull down images without rebooting into the system first. At first I thought it would be much harder than it is.
I've added docker and some support libraries to lorax, they only added about 12M and that's before I've even looked at trying to trim them down at all.
I have an experimental %post --nochroot that starts up docker, points to the LVM thin pool (setup by kickstart, not docker-storage-setup), and pulls down a couple simple images. It writes the config to the target system and kills off docker. The only slightly odd part is bind mounting /var/lib/docker to /mnt/sysimage/var/lib/docker so that everything it writes ends up on the target system.
I propose turning the %post hack into some kickstart commands for setting up the storage, pulling images, and doing whatever other normal setup things are needed.
What do you think? Is this worth the extra 12M (or so) to add this?
On Tue, 2015-12-01 at 17:23 -0800, Brian C. Lane wrote:
What do you think? Is this worth the extra 12M (or so) to add this?
Hi, good idea. I think it's nice feature and it should be as kickstart command. I don't know how much pain is 12M for us but IMHO this could be really useful for some users.
Jirka K.
On 12/01/2015 07:23 PM, Brian C. Lane wrote:
I've been doing some experiments for bz#1283701, supporting running docker at install time to pull down images without rebooting into the system first. At first I thought it would be much harder than it is.
I've added docker and some support libraries to lorax, they only added about 12M and that's before I've even looked at trying to trim them down at all.
I have an experimental %post --nochroot that starts up docker, points to the LVM thin pool (setup by kickstart, not docker-storage-setup), and pulls down a couple simple images. It writes the config to the target system and kills off docker. The only slightly odd part is bind mounting /var/lib/docker to /mnt/sysimage/var/lib/docker so that everything it writes ends up on the target system.
I propose turning the %post hack into some kickstart commands for setting up the storage, pulling images, and doing whatever other normal setup things are needed.
What do you think? Is this worth the extra 12M (or so) to add this?
I'll confess this sounds a bit more like orchestration than installation to me.
Any chance for an example use case?
Pat
On Wed, Dec 02, 2015 at 08:39:42AM -0600, Pat Riehecky wrote:
On 12/01/2015 07:23 PM, Brian C. Lane wrote:
I've been doing some experiments for bz#1283701, supporting running docker at install time to pull down images without rebooting into the system first. At first I thought it would be much harder than it is.
I've added docker and some support libraries to lorax, they only added about 12M and that's before I've even looked at trying to trim them down at all.
I have an experimental %post --nochroot that starts up docker, points to the LVM thin pool (setup by kickstart, not docker-storage-setup), and pulls down a couple simple images. It writes the config to the target system and kills off docker. The only slightly odd part is bind mounting /var/lib/docker to /mnt/sysimage/var/lib/docker so that everything it writes ends up on the target system.
I propose turning the %post hack into some kickstart commands for setting up the storage, pulling images, and doing whatever other normal setup things are needed.
What do you think? Is this worth the extra 12M (or so) to add this?
I'll confess this sounds a bit more like orchestration than installation to me.
That was my original thinking as well, I usually like setting up the base system and then use something like ansible to do setup of the services after rebooting. But not everyone works that way.
Any chance for an example use case?
Setup of systems in a single pass instead of having to install, reboot, apply configuration using ansible.
Also remember that anaconda can be used to create disk images, so this can be used to make images with the required docker images already installed and setup, and then those images can be deployed with something like vagrant.
On 12/02/2015 11:01 AM, Brian C. Lane wrote:
On Wed, Dec 02, 2015 at 08:39:42AM -0600, Pat Riehecky wrote:
On 12/01/2015 07:23 PM, Brian C. Lane wrote:
I've been doing some experiments for bz#1283701, supporting running docker at install time to pull down images without rebooting into the system first. At first I thought it would be much harder than it is.
I've added docker and some support libraries to lorax, they only added about 12M and that's before I've even looked at trying to trim them down at all.
I have an experimental %post --nochroot that starts up docker, points to the LVM thin pool (setup by kickstart, not docker-storage-setup), and pulls down a couple simple images. It writes the config to the target system and kills off docker. The only slightly odd part is bind mounting /var/lib/docker to /mnt/sysimage/var/lib/docker so that everything it writes ends up on the target system.
I propose turning the %post hack into some kickstart commands for setting up the storage, pulling images, and doing whatever other normal setup things are needed.
What do you think? Is this worth the extra 12M (or so) to add this?
I'll confess this sounds a bit more like orchestration than installation to me.
That was my original thinking as well, I usually like setting up the base system and then use something like ansible to do setup of the services after rebooting. But not everyone works that way.
I see what you are getting at.
Would an anaconda addon make more sense? Technology changes and best practices go obsolete. Putting this into an addon would (a) help highlight the nifty anaconda addons API, (b) insulate anaconda a bit from one specific container technology, and (c) help keep some level of "orchestration" out of the raw installer.
Plus, in theory the %addon sections could be easily copied from one kickstart file to another (like containers).
Thoughts?
Any chance for an example use case?
Setup of systems in a single pass instead of having to install, reboot, apply configuration using ansible.
Also remember that anaconda can be used to create disk images, so this can be used to make images with the required docker images already installed and setup, and then those images can be deployed with something like vagrant.
On Thu, Dec 03, 2015 at 09:22:46AM -0600, Pat Riehecky wrote:
On 12/02/2015 11:01 AM, Brian C. Lane wrote:
On Wed, Dec 02, 2015 at 08:39:42AM -0600, Pat Riehecky wrote:
On 12/01/2015 07:23 PM, Brian C. Lane wrote:
I've been doing some experiments for bz#1283701, supporting running docker at install time to pull down images without rebooting into the system first. At first I thought it would be much harder than it is.
I've added docker and some support libraries to lorax, they only added about 12M and that's before I've even looked at trying to trim them down at all.
I have an experimental %post --nochroot that starts up docker, points to the LVM thin pool (setup by kickstart, not docker-storage-setup), and pulls down a couple simple images. It writes the config to the target system and kills off docker. The only slightly odd part is bind mounting /var/lib/docker to /mnt/sysimage/var/lib/docker so that everything it writes ends up on the target system.
I propose turning the %post hack into some kickstart commands for setting up the storage, pulling images, and doing whatever other normal setup things are needed.
What do you think? Is this worth the extra 12M (or so) to add this?
I'll confess this sounds a bit more like orchestration than installation to me.
That was my original thinking as well, I usually like setting up the base system and then use something like ansible to do setup of the services after rebooting. But not everyone works that way.
I see what you are getting at.
Would an anaconda addon make more sense? Technology changes and best practices go obsolete. Putting this into an addon would (a) help highlight the nifty anaconda addons API, (b) insulate anaconda a bit from one specific container technology, and (c) help keep some level of "orchestration" out of the raw installer.
Plus, in theory the %addon sections could be easily copied from one kickstart file to another (like containers).
Thoughts?
That may work, depending on where we need to insert things into anaconda. It doesn't really insulate anything though, it still needs to be included in the boot.iso
I've added docker and some support libraries to lorax, they only added about 12M and that's before I've even looked at trying to trim them down at all.
I don't know that anyone worries about 12 MB anymore, but if they do... could we break the docker-specific stuff into its own initrd that gets layered on top of the base anaconda one? Could we perhaps do something like this for people that want to run a cmdline-only kickstart-only anaconda too?
I propose turning the %post hack into some kickstart commands for setting up the storage, pulling images, and doing whatever other normal setup things are needed.
If it's a thing that's going to live in the base anaconda and be part of what we officially support, I think it makes sense to create kickstart commands for it. If it's something that is more incidental, I think it makes more sense for it to be an addon. I know those are horribly vague sentences, but hopefully you understand what I am getting at.
- Chris
anaconda-devel@lists.fedoraproject.org