(It seems I only just sent the message below to Joe instead of the
list 18 minutes ago. So here it is and I hope Joe doesn't mind to
re-send his reply, which also missed to hit the list, too. Apologies
for the mistake and the extra-noise.)
On Tue, Dec 10, 2013 at 3:57 PM, Joe Brockmeier <jzb(a)redhat.com> wrote:
On 12/10/2013 08:45 AM, Sandro "red" Mathys wrote:
> On Tue, Dec 10, 2013 at 3:21 PM, Joe Brockmeier <jzb(a)redhat.com> wrote:
>> On 12/10/2013 04:45 AM, Matthias Runge wrote:
>>> Two short thoughts about this:
>>> - do we really need to distinguish between public, private and hybrid
>>> cloud? IMHO that shouldn't really matter for the image.
>> It matters for the image format (AMI vs. qcow2, etc.) and may matter for
>> packages that are included in the image as well.
> Why would it matter for the format? AMI or qcow2 both work in public,
> private and hybrid clouds. Or am I missing something?
AMI is preferred on Amazon. Don't think it's a supported format for
CloudStack, not sure about OpenStack. I don't think you can directly
import qcow2 to EC2.
OpenStack can import AMI but will probably convert it (automagically)
before using it. I'd guess Eucalyptus can make use of AMI too, since
they strive for AWS compatibility.
Now while AWS is exclusively a public cloud, OpenStack, Eucalyptus and
I'd guess also CloudStack and OpenNebula can make up a public, private
or hybrid cloud. Particularly OpenStack is used in all three ways.
So if at all, it should probably not be distinguished by
public/private/hybrid but rather by AWS/others (or split "others"
further, if there's any reason to do so).
Also: we're already producing these images. I'm guessing we
didn't do so
> Any examples what should be different in terms of packages? I can't
> think of anything that is public/private/hybrid specific.
EC2 has its own tools that, IIRC, are bundled with the AMI. (ec2-utils)
Not sure whether we can ship that package or not, I don't see it currently.
Which I think are <1MB in size, hardly a reason to distinguish
anything. Also, that'd still be AWS-specific, not public-specific.