On Sun, Nov 06, 2016 at 11:38:33AM -0800, Noah Meyerhans wrote: > > I pushed to git://git.debian.org/cloud/fai-cloud-images.git. > > I've got a FAI config targeting jessie on EC2. It seems to work well and > at this point I'm at the point of tweaking the packages lists and > configuration to match JEB's images as closely as possible. It shouldn't > be hard to merge my work into Sam's repo, but I haven't done it yet.
Ok, I've just pushed to fai-cloud-images. Because my work started in a
different repo, it was difficult to preserve history, so I ended up
pushing everything in a single commit.
My volume-to-ami script is included at the top level. It's certainly not
the right place for it, but there isn't an obvious right place. Maybe
create a bin directory?
In an effort to reduce repetition, I've introduced an "apt_cdn" variable
that can be set in a cloud-specific class. This lets us generate
sources.list files based on templates that refer to mirrors running in
the local cloud infrastructure, e.g. cloudfront for AWS.
I've modified the class/DEBIAN.var file such that the default behavior
is to generate images for jessie. We can add a STRETCH class in order to
generate images for testing. I'd rather use "stable", but it's
preferable to use the release codename in many places and there's no
easy way to resolve stable to the current codename AFAIK. Maybe there
should be?
I've generated ami-113e9d71 based on the following command line:
fai-diskimage -u cloud3 -S3G
-cDEBIAN,JESSIE,JESSIE64,AMD64,BACKPORTS,GRUB_PC,DEVEL,CLOUD,EC2
That AMI is marked public in case anybody wants to try it as is, though
I may delete it at some point.
cloud-init works, along with root FS resize. Console output is logged to
the serial port and is available via the get-console-output API. The
'admin' user is created with the ssh key given at boot time. pstree
shows:
systemd-+-agetty
|-agetty
|-atd
|-cron
|-dbus-daemon
|-dhclient
|-exim4
|-rsyslogd-+-{in:imklog}
| |-{in:imuxsock}
| `-{rs:main Q:Reg}
|-sshd---sshd---sshd---bash---pstree
|-systemd-journal
|-systemd-logind
`-systemd-udevd
Systemd-analyze critical-chain ssh.service shows that, between kernel
and userspace, it takes 40s before the instance is ready for use, so
it'd be nice to optimize this:
ssh.service @36.153s
└─cloud-init.service @27.088s +9.040s
└─cloud-init-local.service @12.938s +14.136s
└─basic.target @12.938s
└─timers.target @12.938s
└─systemd-tmpfiles-clean.timer @12.938s
└─sysinit.target @12.937s
└─networking.service @6.533s +6.403s
└─local-fs.target @6.532s
└─mdadm-raid.service @6.112s +419ms
└─systemd-udevd.service @6.099s +3ms
└─systemd-tmpfiles-setup-dev.service @5.353s +745ms
└─kmod-static-nodes.service @4.642s +710ms
└─system.slice @4.640s
└─-.slice @4.640s
These values compare favorably to our current AWS AMIs, although there
are some notable differences that should be addressed. In particular, my
image runs exim4 and atd, while the marketplace AMI does not. We
probably should stick with the marketplace AMI's behavior for
consistency. My image fixes 785457 by not running extraneous gettys on
tty1-6.
My AMI has 550 packages installed, while the marketplace AMI has only
318. I have not compared image generation when performed without the
DEVEL class being enabled. I suspect it'll still have more packages than
marketplace, but not by as wide a margin.
noah
signature.asc
Description: PGP signature
