On Oct 22, 2013 9:56 AM, "Jimmy Kaplowitz" <jkaplowitz@google.com> wrote:
>
> 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.
Its not just about concepts and providers but more about definition and scope.
Richard Stallman has some great points about the differentiation on http://lists.debian.org/debian-cloud/2013/04/msg00032.html.
Taking a step back, do we yet build and provide basic virtual machine images or are we providing for cloud only? Can I go to a debian file server online and download a vm image for kvm or xen only and has nothing to do with cloud?
I think its a good idea to cover this space first before branching out to cloud support. Also, do we really want to build and test images from the ground up for every cloud and environment?
>
> - 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:
>>> http://meetings-archive.debian.net/pub/debian-meetings/2013/debconf13/high/1004_Public_clouds_and_official_Debian_image_status.ogv
>>>
>>> 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
>
>