On 2016-11-06 11:38:33, Noah Meyerhans wrote:
> On Fri, Nov 04, 2016 at 09:03:39PM -0400, Sam Hartman 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.
>
> I've introduced two classes:
>
> EC2: Contains EC2-specific packages, debconf settings, etc
>
> DEVEL: Installs a number of packages useful in a full-featured Debian
> environment, such as git, devscripts, build-essential, etc. The
> motivation is that we could generate "minimal" images simply by leaving
> omitting this class.
+1
> My workflow has largely involved local development with testing taking
> place in EC2. In reality there's only a single step that needs to be
> performed on an actual instance, though. ('dd' of the generated image to
> an attached EBS volume) A possible "production" workflow might be:
>
> 1. Run 'fai-diskimage' locally on a Debian-managed host.
> 2. Perform automated analysis of FAI logs for sanity tests.
> 3. Mount generated image locally and perform filesystem-level tests.
> 4. Launch an EC2 instance and attach an EBS volume to it as sdb.
> 5. scp the generated image to the EC2 instance and 'dd' to sdb.
> 6. snapshot the EBS volume and register it as an AMI
> 7. Perform any desired AMI tests, such as launching it with different
> user-data configuration, etc.
> 8. Migrate the AMI to different regions, mark public, register with
> marketplace, etc.
>
> The 'dd' component of step 5 is the only one that actually needs to run
> on an EC2 instance.
That's true but there is a bit which makes me quite uncomfortable to be
precise it's that to do all this stuff from within Debian infra we need to keep
AWS IAM keys on it with permissions for spinning up and down instances etc.
From my conversation with JEB kind of vision emerged that we could have
combination of api gateway and lambda listening on the api point and those
would spin up instance with Pettersson ssh key (public part ofc) and specific
IAM role on it to allow to do DD and all AWS related dance. Once whole process
is done it'll just destroy AWS instance and wait for the next build.
Clean and neat use of "the cloud" I'd say.
> I'm sure JEB already has infrastructure for most of these steps, and we
> should continue using that where appropriate.
From what I know we (me and JEB) have 2 independent build nodes and we're
planning to converge into the above at least that's how I'm understanding
conclusions of our conversations.
But looking at what you wrote as a high level overview matches exactly what we
(most of us in Seattle I think) agreed upon including me.
So thx for your work on AWS part and pls push it to the git, hopefully Mrfai
will fix fai to work on LVM based hosts so I can try it :-)
--
|_|0|_| |
|_|_|0| "Panta rei" |
|0|0|0| -------- kuLa -------- |
gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3
Attachment:
signature.asc
Description: PGP signature