[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Long-overdue slides and notes from the DC13 official Debian images BoF

I think the concept is basically the same for both cases except for details like what packages are installed and how to boot. I don't see what the difference is from the team maintenance perspective. In the VM context, "Cloud" just means "virtual with an API that abstracts away what host you're running on", or your favorite variant of that definition.

Examples: If you target Amazon EC2, you'll probably pull in euca2ools and use pv-grub, set up a default user account, and soon use cloud-init. If you target Google Compute Engine, you'll probably pull in gcutil and gsutil and a few other packages, use our account management by default, temporarily use our injected kernel, in the future use the Debian kernel with a very sane boot method (I'll definitely tell this list when the details are public), and also eventually cloud-init. If you target VirtualBox, it'd be like Compute Engine but with their guest additions instead of gcutil/gsutil (unless Oracle made them non-free), no cloud-init, and account management TBD. Vanilla Qemu/Kvm would be a hybrid of the previous examples.

I really don't see much conceptual difference of virtual vs cloud from the image provider perspective.

- Jimmy


On Mon, Oct 21, 2013 at 3:42 PM, Chris Fordham <chris@fordham-nagy.id.au> wrote:

This comment probably deserves its own thead, but let's start talking about it here.

I think that there should be a debian-virtual team as well as debian-cloud. This would separate and clearly define software in each realm.

An example is the debian images. The virtual team would create virtual machine images that may be specific to hypervisors but not contain any cloud or specific cloud elements. The cloud team can take that image and add on or modify it for specific clouds.

At the moment it seems like virtual and cloud is melded together.

On Oct 22, 2013 7:26 AM, "Jimmy Kaplowitz" <jkaplowitz@google.com> wrote:
Hi,

At DebConf13, we had a great rollicking discussion about public clouds and official Debian image status, prompted by a few slides by me but the discussion was the best part. Here are some notes from the discussion. 

- Zack: might need a cloud release team to decide what goes into cloud
images and bridge release cycle differences
- folks linked to Amazon/OpenStack/Google:
  - Cloud is just a new “architecture” for Debian to support
  - Maybe put tools for all clouds in a unified cloud image
  - Security lockdowns are important for cloud, or possibly everyone
- Some people like “Official Debian” trust
- Lucas: official images should use Debian practices e.g. Alioth not
Github, packages in main, and may not be necessary for Google
- Zack and me: 'main' might not have to mean stable, and could include
e.g. backports from unstable
- almost everyone: “Debian Inspired” images with proprietary code, etc
a “slippery slope", don't do this

Thanks to my colleague David for writing this up a day or two later -
I've adapted these from his. They weren't written during the talk so
I'm sure things got left out.

There's also full video online from the video team. Here's one version:

Lucas gave me some thoughts privately when I sent this to him a while back, but I'll leave it to him to repost his thoughts publicly.

I just published the slides to Penta, but since Penta's attachment export for the anonymous view is broken and they're only ~120K, I'm attaching them to this email as well. If you redistribute the slides, it would make Google happiest if you include a link to the video so that everyone reading then has all the context easily available to them. Please pardon the few visual glitches that occurred during export to PDF format.

- Jimmy

Reply to: