On Tue, Oct 22, 2013 at 12:32 PM, Jimmy Kaplowitz <jkaplowitz@google.com> wrote:
My view on the rename is that I prefer less churn and would rather not rename just for the sake of the ideal name, since it breaks a lot of mental habits, workflows, checkout and git remote names, etc. If there's another reason to rename it, I have no problem with a more generic name, though finding the right name is hard (see later in this email).Better to do sooner than later imho :)
Still the name cloud is also an advantage as well as a disadvantage. Anyone who avoids trendy buzzwords with lots of corporate involvement will naturally be suspicious of the word cloud, but it also helps to attract new attention and show that Debian is "keeping with the times" to address newer use cases while still respecting its principles of freedom and meeting user needs. Google Compute Engine now recommends and documents Debian by default. I am certainly happy to be able to point to Debian's overall cloud effort when talking to people about this part of Google's offerings. A "virtual" team would not have the same effect.You can still keep with the times. I'm not suggesting rename the debian cloud team, I'm suggesting that debian-virtual covers non-cloud virtualization, debian-cloud covers cloud virtualization. debian-cloud can use and extend what debian-virtual provides e.g. transform a base virtual image into one for a specific cloud. This provides a better SDLC structure and testing separation.
Personally I view the cloud naming of this team as a good thing, not to exclude single-host virtualization but because it's the part Debian wasn't already handling well. People didn't have an "image" of this type, but people have been installing Debian in virtualized environments, automatically and manually, for most or all of the 12 years I've been involved in Debian. I posted a headless VMWare Workstation howto to VMware's NNTP server back in 2002, with Debian as my personal use case. :-) It's the more automated pre-customized flow, or really the many variants of that flow, which is the focus of this team.In fact, the case of automated pre-customized virtual images on a single host machine for the host owner's private use is effectively the simplest possible cloud IaaS environment, as compared to the other way of "go through the installation process anew for each individual VM, maybe based on d-i preseeding or fai, maybe not". That's another reason I'm okay with cloud as a differentiating term, despite the marketing-y connotations.Do you really want to rename us "debian-preinstalled-virtual-images"? Because that's the only way you'll get a completely buzzword-free name that reflects the precise focus, and that's ugly. :-) [Yes, it could be cleaned up, but debian-virtual is misleadingly broad even if debian-cloud is a bit buzzwordy.]See above, separate teams not renaming of debian-cloud. debian-virtual is not just images, its anything virtual that is non cloud such as packaging virtual software.Primarily, I hope we can focus on technical word and non-technical work related to principles, and minimize terminological email threads except as necessary to accomplish our technical and principled goals.Accuracy of terms is quite important, at least a lot of engineers think so. Sometimes its important to re-structure and do it early before it gets out of control.- JimmyOn Mon, Oct 21, 2013 at 6:08 PM, Chris Fordham <chris@fordham-nagy.id.au> wrote:
Quite true we agreeing on things here. Image building was one example and yes the name of the debian-build-cloud should be renamed.On Tue, Oct 22, 2013 at 12:01 PM, Jimmy Kaplowitz <jkaplowitz@google.com> wrote:
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! :-)
>
> > - JimmyAnother 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 :)