On Tue, Oct 22, 2013 at 12:01 PM, Jimmy Kaplowitz <[email protected]>wrote:
> On Oct 21, 2013 5:25 PM, "Chris Fordham" <[email protected]> wrote: > > > > > > On Oct 22, 2013 10:27 AM, "Jimmy Kaplowitz" <[email protected]> > wrote: > > > > > > On Mon, Oct 21, 2013 at 4:08 PM, Chris Fordham < > [email protected]> 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 > Quite true we agreeing on things here. Image building was one example and yes the name of the debian-build-cloud should be renamed. Another example is packaging. A lot of packaging that I observe in this project are for packages which are virtual and not cloud. I guess what I want to see is some accuracy in terms of what falls under virtual and what falls under cloud instead of blanketting it all into 'debian-cloud'. A lot of people probably won't share the same point of view and be happy with the generic nature of cloud, but personally I think we end up being a victim of cloud washing which Debian purists generally like to aviod that type of thing :)
