Re: Please let's not talk about "clouds"
On 04/23/2013 04:00 AM, Richard Stallman wrote:
> > But if the idea is that the user
> > uses his own servers, please don't use the term "cloud" to describe
> > it.
>
> I think it's fine to use the world "cloud" if we explicitly tell that it
> refers
> to IaaS (Infrastructure As A Service) in this case.
>
> I can't remember what "Infrastructure As A Service" means, but it's
> more specific than "cloud" -- so why not say that instead?
Let me try to make it more clear then. I hope I will succeed. I believe
it is really important that you understand it fully, so that you can
discuss "freedom in the cloud" in general, and be able to explain to
others what different clouds we are dealing with.
Cloud IaaS means you get a bunch of physical computers, pool them into a
unique entity, then you can start virtual servers on this IaaS cloud
without carrying where your virtual machine really runs, and where the
resource (storage, network, CPU) has been allocated. The goal of the
orchestration software which provides IaaS is to abstract all of the
resources with schedulers, load balancers, redundant storage and son on.
You can then start as many VMs as you want at once and "scale" in and out.
Note that this is independent to the type of virtualization in use. In
some cases, you could run without any virtualization at all (there is
for example a "baremetal" driver for Openstack compute).
Is there anything I need to explain further?
> > These two activities are entirely separate.
>
> Though for both of them, we need a Debian Cloud Image,
>
> I don't see why. Can you explain?
For AWS (Amazon Web Service), Azure, and probably any other proprietary
IaaS, you have the same specific need as with the free software version
of IaaS currently available in Debian using Eucalyptus or OpenStack (and
probably with CloudStack as well, which I don't know).
On all of these IaaS, when a virtual machine starts, you need to grab
some more information about how to configure things like hostnames, and
so on. These are called the "metadata". When the VM boots, it queries
the metadata server for these information, which are provided somehow by
the final user of the infrastructure, through the IaaS API.
The "cloud-init" thing is that part which runs at boot time inside the
virtual machines which queries the metadata server for this information,
and initialize the virtual machine with what it receives. I'm keeping
this vague, because it could be quite a lot of things and it is my
understanding that it is highly user-customizable. Maybe others who have
more experience with this than I could add some comments (I would be
very happy to read about it myself).
Also, since the virtual machine images are most of the time set with a
pre-defined as small as possible HDD size (to minimize storage and boot
time), you may want to run a script which will resize the local
temporary HDD at boot time. cloud-initramfs-growroot does that work. See
the source package cloud-initramfs-tools in Debian (which contains a bit
more than just that).
On OpenStack, this metadata thing materialized with nova-api being able
to run a "metadata server" which is activated either through Debconf or
by editing the nova.conf file. Typically, you would run this service on
each and every "compute node" (but there are also other types of setups
which also work with a single metadata server, AFAIK). Sorry, I'm
talking about what I know, Eucalyptus may explain how it works for them
(and I'd be happy to read about it too...).
Then, with XCP (Xen Cloud Platform), which btw can be only the
hypervisor for OpenStack, you may want to run an "agent" inside each
virtual machine (domU, in the Xen notation). This is, IMO, a bad thing,
because the owner of the host shouldn't trust what runs on the guests.
But this is how it is right now.
So, for both commercial cloud IaaS offering images, and for the images
which will fit into the cloud IaaS software offer available in Debian,
we have the same needs for the images:
- ssh without host keys
- cloud-init and friends (growroot and so on)
- a boot loader (it seems after all, extlinux could work)
- a minimalistic install of Debian
Lucky, cloud-init is compatible with all (Eucalyptus, OpenStack, AWS and
Azure).
> Support for virtual servers requires an image, but there is no need to
> call that image "a cloud image". You can call it "an image for Amazon
> virtual servers", or whichever.
Well, since we can make it so that these images could work on nearly any
IaaS cloud, yes, calling them "an IaaS cloud image" does make sense. But
I think it would be wise to list all the IaaS which it could support.
Best also, would be to be able to generate these images directly in
Debian, without requiring any cloud infrastructure running. And I
believe this is possible with a simple script.
> Using programs such as Eucalyptus or others does not require a special
> image. They just need to be packages.
>
> with
> cloud-init installed and so on.
>
> What is "cloud-init", what does it do?
See above.
> And why does it have a name using the confusing word "cloud"?
>
> I was even
> more disappointed to see such "official" Debian images being available
> only on these private companies cloud,
>
> If we're talking about virtual servers for rent, please don't call
> them "clouds". Using that term spreads confusion every time.
Thanks for the reminder. I know you care about wording, I agree it is
important, and I will try to follow your guideline. Though, see, when I
say "IaaS", you didn't understand. So probably, best would be to always
write "Cloud IaaS", not just cloud, and not just IaaS. Your thoughts?
Thomas Goirand (zigo)
Reply to: