Re: Long-overdue slides and notes from the DC13 official Debian images BoF
On Tue, Oct 22, 2013 at 12:18 AM, Jimmy Kaplowitz <jkaplowitz@google.com> wrote:
> Hi Charles,
>
>
> On Oct 21, 2013 8:55 PM, "Charles Plessy" <plessy@debian.org> wrote:
>>
>> Le Mon, Oct 21, 2013 at 06:01:31PM -0700, Jimmy Kaplowitz a écrit :
>> >
>> > I don't see the advantage of a two-part build process for cloud
>> > images,and
>> > have even found it to be a pain to maintain in other, non-Debian
>> > contexts.
>> > As I said, the diff transparency you want is already there.
>>
>> Hello everybody,
>>
>> I think that we should aim at images that are as generic as possible. If
>> it is
>> impossible, we should at least document why.
>>
>> For instance, we could aim to have cloud-init installed by default
>> provided
>> that it runs only where appropriate. Amazon images are booted by PV-GRUB,
>> via
>> a configuration file, /boot/grub/menu.lst, that is not used otherwise if
>> booting the image with GRUB2, used for example when booting with
>> VirtualBox..
>> So if we can pass parameters to activate cloud-init via the PV-GRUB boot
>> process, we
>> can have it running on Amazon but not on a local VirtualBox. If the same
>> idea
>> can be expanded to the other cloud and virtualisation platforms, this
>> removes
>> one of the needs for separate sets of images.
>>
>> Does that look doable ?
>
> That's a neat trick but doesn't generalize. Google Compute Engine will boot
> in a similar way to VirtualBox once we launch the feature to use non-Debian
> kernels, but we too are moving toward cloud-init. Amazon EC2 doesn't work
> nicely with ISC DHCP, according to build-debian-cloud source code comments;
> Google Compute Engine is most tested with / recommends it. User accounts and
> networking are handled quite differently too. This is not a complete list of
> differences.
>
> More generally, someone is going to need to test an image on every platform
> we want to say works well. Aside from a bit of build time and storage space,
> how many images we have is an implementation detail.
I'm wondering if perhaps the long term answer is to leverage the newly
build jenkins.debian.net [1], with jobs that spin up cloud instances
using the cloud APIs tied with some sort of exhaustive common set of
remote "Unit Tests" against spun up images? (Perhaps it won't start
out exhaustive, but I do believe the tests we want to run would
largely be a common set.)
> - Jimmy
Cheers,
Brian
[1] - http://lists.debian.org/debian-devel-announce/2013/08/msg00005.html
>>
>> Cheers,
>>
>> --
>> Charles Plessy
>> Tsurumi, Kanagawa, Japan
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-cloud-request@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmaster@lists.debian.org
>> Archive: [🔎] 20131022035502.GC17906@falafel.plessy.net">http://lists.debian.org/[🔎] 20131022035502.GC17906@falafel.plessy.net
>>
Reply to: