Yeah, that sounds great. I'll see what I can do about adapting our internal tests for some sort of external use - it was already on my to-do list actually - but please don't wait for that to add tests. ;)
PS - I favorably mentioned Jenkins.d.n to a colleague just today. Integration and unit tests are a wonderful thing Debian should do more of.
- Jimmy
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" target="_blank">http://lists.debian.org/[🔎] 20131022035502.GC17906@falafel.plessy.net
>>