enable support for creating kvm images for jessie on arm64

[clarktlaugh]

These minor changes allow bootstrap-vz to build a kvm image for jessie on arm64, by updating the schema to accept arm64 as an architecture, no bootloader, and providing an example manifest.

[myhro]

Hi Clark,

I don't have a way to test an arm64 image (maybe on QEMU?) right now. It is nice to know that a new architecture can be bootstrapped with so few changes, but I'm not really sure if we have enough resources (e.g.: manpower, time and hardware) to maintain it.

What are your thoughts on this, Anders?

[clarktlaugh]

Yes - QEMU should work fine for testing an image.

I work with Linaro, which is building an arm64 reference platform based on Debian (https://github.com/96boards/documentation/wiki/ReferenceSoftwareEE) with a big focus on Openstack and docker. Having the standard tooling support creation of proper images will be a priority, so I am sure help with testing/maintenance would not be an issue. But, hopefully, the impact to bootstrap-vz would be minimal?

[andsens]

@myhro

but I'm not really sure if we have enough resources (e.g.: manpower, time and hardware) to maintain it.

It's a valid concern. It seems, however, that most of the legwork is done by Debian itself. bootstrap-vz is quite architecture agnostic really. So in the end, I don't think merging this PR would increase the workload.

@clarktlaugh

Having the standard tooling support creation of proper images will be a priority, so I am sure help with testing/maintenance would not be an issue.

That would be awesome. bootstrap-vz has an entire testing harness to help you do that. A new integration test provider is quite easy to create.

I'm fine with merging this, @myhro? (merge if you agree :-) )

[myhro]

Anders,

So in the end, I don't think merging this PR would increase the workload.

My only concern here are those corner cases where fixing a problem in an architecture would break another one - specially if this isn't easy to test on many releases/providers. Maybe we should state that our goal is to provide support for the current stable release on architectures x, y and z (and some of them only on a subset of providers, e.g.: arm64 only on kvm) and everything else is maintained as a "best effort"?

P.s.: this is something that has been on my head since #122 / #144. :-(

I'm fine with merging this, @myhro? (merge if you agree :-) )

I would like to see those commits squashed/rebased and jessie-virtio.yml to be renamed mentioning its architecture (like jessie-arm64-virtio.yml) to avoid confusion (even with the name arm64 being pretty close to amd64). Could you please do this, @clarktlaugh?

[andsens]

@myhro, you're head is definitely more in the game than mine is right now :-)
Agree with all your points.

Maybe we should state that our goal is to provide support for the current stable release on architectures [...]

Yup. Hmm, sounds like an addition to Supported builds, we should link to that from somewhere in the top of the readme.

[myhro]

Clark,

Sorry for the delay, but GitHub doesn't notify about new commits on a Pull Request - only comments. I'm merging this one. Thanks a lot!

Anders,

Yup. Hmm, sounds like an addition to Supported builds, we should link to that from somewhere in the top of the readme.

I've opened #266 so we can track this separately.