On Oct 21, 2013 5:25 PM, "Chris Fordham" <chris@fordham-nagy.id.au> wrote:
>
>
> On Oct 22, 2013 10:27 AM, "Jimmy Kaplowitz" <jkaplowitz@google.com> wrote:
> >
> > On Mon, Oct 21, 2013 at 4:08 PM, Chris Fordham <chris@fordham-nagy.id.au> wrote:
> >>
> >> 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.
> >
> > Other participants in that thread were disagreeing with him. For one thing, even though Amazon and Google are controlled by single companies, cloud includes private and hybrid models that run partly or fully inside a company's own premises. You can also host virtual in other providers' clouds, like Linode. Cloud instances are just a streamlined version of virtual, nothing more.
>
> I am not sure there is an appropriate point here but it actually seems to back up my argument. A cloud is an extension or consumer of virtual, so that is actually secondary to plain virtual computing.I think we agree that cloud images are virtual plus more.
>
> >>
> >> 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.
> >
> > You might want to look at the latest pull request I submitted to build-debian-cloud. Now that I think about it, that reveals how Google Compute Engine's booting will work, so I don't have to beat around the bush. That image boots via normal execute-code-in-MBR methods (not pv-grub), and I've even booted it locally in qemu/kvm. You can probably combine what I have there with the Amazon Debian images' model of a default user account and have a very simple patch to add the image you'd like. It's not as much of a separate task to warrant a distinct team.
>
> So why don't we build and distribute plain images which can then be patched in loopback mount for anything cloud specific. Also build-debian-cloud doesn't build a debian cloud and I still don't think the name should have 'cloud' in it if its not cloud specific.
> It 'builds a Debian virtual machine image'.I'm not going to bikeshed over the name of the tool. I have no strong feelings besides not wanting too frequent renames. The main author (not me) picked the name quite recently when we generalized the scope from Amazon to Amazon+Google, but even then he intended to broaden support to non-cloud environments like VirtualBox. I view the name as not perfect but good enough.
>
> >>
> >> Also, do we really want to build and test images from the ground up for every cloud and environment?
> >
> > I think that's the kind of thing where each cloud the team decides to support would need someone to be paying attention to it, and other team members would help by working on common bits where possible. As an example, James is primarily responsible for Amazon EC2 images, and I and others at Google are currently responsible for Google Compute Engine images*, but many of us are converging on cloud-init, and Thomas Goirand and Vincent Bernat have been very helpful toward getting Google's tools properly packaged in Debian. In the case of Debian images, Google does have a test suite we run before I publish the images, though further manual testing is always useful.
> >
> > * Note: We'd love more Debian people to get involved with the Google Compute Engine Debian images, and Google's covering the associated bills, so there's no payment involved. Let me know and we can broaden the Debian side of the team beyond just me! At some point I will send out a separate call for volunteers in case it gets lost in this thread.
>
> Looks like this is quite suited to taking a base vm image and simply applying changes. This would help in separating testing and easily seeing the diff between a base image and the cloud images.We basically have that, it's just in the source tree rather than in binary form. Especially true in the Python version where things are even more modular than in shell.
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.
We agree it would be good for bare Qemu/KVM/Xen/etc images to be built. Guess what? Someone already contributed a KVM provider to the Python branch of build-debian-cloud, and I think some attempt at one for VirtualBox too. Sally forth! :-)
>
> > - Jimmy