Re: dieas for the sprint

2017-10-16 Thread Emmanuel Kasper
> --
> 2) how to boot/create the build VM
> 
> Which restrictions do DSA have?
> private network for VMs
> DSA will create tap devices in a bridge, tap devices belong to cduser
> DHCP server in this private network
> 
> Once the network is set up by DSA we are independent of DSA

Hi Thomas

thanks for chiming on the subject. Since you're the MrFaI I am not
surprised to see a FAI based solution :) I had a look at tap devices
assignment and it works well.

For the record
https://www.kernel.org/doc/Documentation/networking/tuntap.txt
has the bit about the permissions and the security implications

For the Step by step setup in this stack overflow question.
https://unix.stackexchange.com/questions/243382/making-dev-net-tun-available-to-qemu

> cduser can start VMs using fai-kvm
>
> - fai-kvm: start VM with a fixed MAC address to get a predefined IP
>   choose boot medium, nographics mode not yet available
> SHOW fai-kvm -h
>
> create a disk image for our building VM using a FAI CD installation,
> master.raw
> then do build process
>  - copy master.raw to build1.raw
>  - start build VM using build1.raw
>  - rm build1.raw after the disk image was created inside VM

as long as I can reproduce the build outside casulana (that was my main
grief with petterson-live) so we can build for Vagrant boxes a CI
toolchain, on top of that I am fine with every technical solution here.





Re: dieas for the sprint

2017-10-16 Thread Ben Howard
Thank you Nathan for setting me straight! Indeed I assumed in correctly.

As an image generator, this does look like a fine tool.

Ben

On Oct 16, 2017 6:08 AM, "Noah Meyerhans"  wrote:

> On Sun, Oct 15, 2017 at 11:14:01PM -0600, Ben Howard wrote:
> >Thank you for the idea, however, after looking at it, I see FAI as
> >technology akin to KickStart, MAAS, AutoYast, etc.
>
> Ben, as you weren't at last year's cloud sprint, you likely missed that
> we settled on using FAI as the cloud image generation tool then. I've
> been using it since then to build the Debian images available in the AWS
> Marketplace. (As far as I know, other clouds haven't yet adopted it, but
> I think this will be an issue to fix during this sprint.) It does not
> attempt to duplicate any of what cloud-init is doing, and in fact still
> runs cloud-init as usual.
>
> Adding support for additional cloud to our FAI configs should be very
> nearly trivial. If they don't require any special configuration or
> packages baked into the image, then there's really no configuration at
> all. If they do require specific configuration (e.g. for EC2 we want to
> bake the aws-cli and boto packages into the image) then that's easy to
> do.
>
> The FAI configs for building vagrant boxes and EC2 AMIs are at
> https://anonscm.debian.org/cgit/cloud/fai-cloud-images.git/tree/
>
> While snapshot-based image customization is, of course, supported, we
> also explicitly wanted to support users who want to construct images
> "from scratch" that derive from our configs. This is straightforward in
> FAI, and I posted a blog giving an example of our one might do it:
>
> https://noah.meyerhans.us/blog/2017/02/10/using-fai-to-
> customize-and-build-your-own-cloud-images/
>
> At last year's sprint, we demoed the various available image generation
> tools. I suspect we'll do something similar again this year, so you'll
> get to see the system in action.
>
> noah
>
>


Re: dieas for the sprint

2017-10-16 Thread Noah Meyerhans
On Sun, Oct 15, 2017 at 11:14:01PM -0600, Ben Howard wrote:
>Thank you for the idea, however, after looking at it, I see FAI as
>technology akin to KickStart, MAAS, AutoYast, etc. 

Ben, as you weren't at last year's cloud sprint, you likely missed that
we settled on using FAI as the cloud image generation tool then. I've
been using it since then to build the Debian images available in the AWS
Marketplace. (As far as I know, other clouds haven't yet adopted it, but
I think this will be an issue to fix during this sprint.) It does not
attempt to duplicate any of what cloud-init is doing, and in fact still
runs cloud-init as usual.

Adding support for additional cloud to our FAI configs should be very
nearly trivial. If they don't require any special configuration or
packages baked into the image, then there's really no configuration at
all. If they do require specific configuration (e.g. for EC2 we want to
bake the aws-cli and boto packages into the image) then that's easy to
do.

The FAI configs for building vagrant boxes and EC2 AMIs are at
https://anonscm.debian.org/cgit/cloud/fai-cloud-images.git/tree/

While snapshot-based image customization is, of course, supported, we
also explicitly wanted to support users who want to construct images
"from scratch" that derive from our configs. This is straightforward in
FAI, and I posted a blog giving an example of our one might do it:

https://noah.meyerhans.us/blog/2017/02/10/using-fai-to-customize-and-build-your-own-cloud-images/

At last year's sprint, we demoed the various available image generation
tools. I suspect we'll do something similar again this year, so you'll
get to see the system in action.

noah



signature.asc
Description: PGP signature