On Tue, Oct 22, 2013 at 12:32 PM, Jimmy Kaplowitz <[email protected]>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. > > - Jimmy > > > On Mon, Oct 21, 2013 at 6:08 PM, Chris Fordham > <[email protected]>wrote: > >> 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 :) >> > >
