Attention Cloud WG nominees

[Sandro "red" Mathys]

On Mon, Oct 21, 2013 at 12:12 PM, Joe Brockmeier <jzb at redhat.com> wrote:
> On Mon, Oct 21, 2013 at 11:57:57AM +0200, Sandro "red" Mathys wrote:
>> On Mon, Oct 21, 2013 at 11:21 AM, Joe Brockmeier <jzb at redhat.com> wrote:
>> > - server == pet == a system that is running on the bare hardware and may
>> >   run the IaaS or PaaS that is running instances/applications. I care a
>> >   lot if this goes down because it's infrastructure.
>> > - instance/image == cattle == a system that has the libraries/apps I
>> >   need *right now* and is being used as part of scale out applications,
>> >   and if it dies, I don't care as much because I have an automated
>> >   system that can spin up a new image with the application data.
>> >
>> > (Being *very* general here).
>>
>> I very much like this approach to say the Server Product is for pets
>> and the Cloud Product is for cattle. But I do think both pets and
>> cattle can be run both on bare metal or virtualized.
>
> Sure. As I said, I was being *very* general... and we would want to
> provide a cloud image that can be spun up on bare metal, in addition to
> the images for AWS and KVM, Xen and/or the major open source IaaSes.

I don't think we need a different image that can be spun up on bare
metal. We simply provide a cloud image (or several that are tailored
more specifically to the underlying solution) and that's it. But
whether the IaaS solution uses hypervisors, containers or bare metal
shouldn't matter to us. With OpenStack for example, all three are
possible and the image doesn't even need to know. And for the Server
Product, i.e. Pet, it shouldn't matter either. After all, Server
Product kind of OSes have been used for ages both on bare metal and in
hypervisors before Cloud Images came into existence sp nothing needs
to change here.

It should just matter to the sysadmin / devops, as he needs to know
what kind of OS he is running and what kind of OS is right for what
kind of use case.

-- Sandro