2:54 p.m.
I'll start this thread. I'm firmly in the "a cloud is an operations
model" camp. It's important because when people say "I want a cloud"
and
we say "You want ovirt" or "you want eucalyptus." I think that's
wrong.
-Mike
2:57 p.m.
It depends on whether your talking to cloud vendors or people who want to use
RHEL/JBoss/Pre-packaged Apps in the cloud.
Chad Tindel
Red Hat Solutions Architect
917.445.8463 - Mobile
----- Original Message -----
From: "Mike McGrath" <mmcgrath(a)redhat.com>
To: cloud(a)lists.fedoraproject.org
Sent: Wednesday, January 20, 2010 3:54:30 PM GMT -05:00 US/Canada Eastern
Subject: Cloud: Technology or Operations Model?
I'll start this thread. I'm firmly in the "a cloud is an operations
model" camp. It's important because when people say "I want a cloud"
and
we say "You want ovirt" or "you want eucalyptus." I think that's
wrong.
-Mike
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
3:10 p.m.
On Wed, 20 Jan 2010, Mike McGrath wrote:
I'll start this thread. I'm firmly in the "a cloud is
an operations
model" camp. It's important because when people say "I want a cloud"
and
we say "You want ovirt" or "you want eucalyptus." I think that's
wrong.
OK, fair enough. But there are also tools that are well suited to support
that operations model, and tools that are poorly suited.
If you build good enough tools, they become Technology with a capital T.
That's what can happen when the open source model works. Too many folks
are trying to start on the Product end, instead of starting on the tools
end (and by extension, the users end). My $0.02.
I'm interested in tools approaches that help our users. I think that's
the advantage that Fedora can provide -- a group of knowledgeable folks
who share and refine the best tools. Red Hat benefits if those tools,
over time, emerge into a Product for which Red Hat can sell support.
--g
--
Computer Science professors should be teaching open source.
Help make it happen. Visit http://teachingopensource.org.
3:23 p.m.
On Wed, 20 Jan 2010, Greg DeKoenigsberg wrote:
On Wed, 20 Jan 2010, Mike McGrath wrote:
> I'll start this thread. I'm firmly in the "a cloud is an operations
> model" camp. It's important because when people say "I want a
cloud" and
> we say "You want ovirt" or "you want eucalyptus." I think
that's wrong.
OK, fair enough. But there are also tools that are well suited to support
that operations model, and tools that are poorly suited.
If you build good enough tools, they become Technology with a capital T.
That's what can happen when the open source model works. Too many folks
are trying to start on the Product end, instead of starting on the tools
end (and by extension, the users end). My $0.02.
I'm interested in tools approaches that help our users. I think that's
the advantage that Fedora can provide -- a group of knowledgeable folks
who share and refine the best tools. Red Hat benefits if those tools,
over time, emerge into a Product for which Red Hat can sell support.
Tools that help our users do what? It can't be cloud stuff because at
that point it's circular reasoning.
-Mike
3:26 p.m.
On 01/20/2010 04:23 PM, Mike McGrath wrote:
On Wed, 20 Jan 2010, Greg DeKoenigsberg wrote:
> On Wed, 20 Jan 2010, Mike McGrath wrote:
>
>> I'll start this thread. I'm firmly in the "a cloud is an
operations
>> model" camp. It's important because when people say "I want a
cloud" and
>> we say "You want ovirt" or "you want eucalyptus." I think
that's wrong.
>
> OK, fair enough. But there are also tools that are well suited to support
> that operations model, and tools that are poorly suited.
>
> If you build good enough tools, they become Technology with a capital T.
> That's what can happen when the open source model works. Too many folks
> are trying to start on the Product end, instead of starting on the tools
> end (and by extension, the users end). My $0.02.
>
> I'm interested in tools approaches that help our users. I think that's
> the advantage that Fedora can provide -- a group of knowledgeable folks
> who share and refine the best tools. Red Hat benefits if those tools,
> over time, emerge into a Product for which Red Hat can sell support.
>
Tools that help our users do what? It can't be cloud stuff because at
that point it's circular reasoning.
-Mike
Well there are three components of cloud stuff
1) The images that run the guests, the hypervisor, or node.
2) Cloud management, They manage not only the underlying nodes but also
the guest on the nodes.
3) The guests
The problem is that Fedora fits into all of these places. For the EC2
users we are focused on #3, for Ovirt, RHEV-H, and other cloud
deployments #1, and for Fedora infrastructure we are focused on all
three but mainly #2?
So how do we approach this?
-D
3:44 p.m.
On Wed, 20 Jan 2010, David Huff wrote:
On 01/20/2010 04:23 PM, Mike McGrath wrote:
> On Wed, 20 Jan 2010, Greg DeKoenigsberg wrote:
>
>> On Wed, 20 Jan 2010, Mike McGrath wrote:
>>
>>> I'll start this thread. I'm firmly in the "a cloud is an
operations
>>> model" camp. It's important because when people say "I want a
cloud" and
>>> we say "You want ovirt" or "you want eucalyptus." I
think that's wrong.
>>
>> OK, fair enough. But there are also tools that are well suited to support
>> that operations model, and tools that are poorly suited.
>>
>> If you build good enough tools, they become Technology with a capital T.
>> That's what can happen when the open source model works. Too many folks
>> are trying to start on the Product end, instead of starting on the tools
>> end (and by extension, the users end). My $0.02.
>>
>> I'm interested in tools approaches that help our users. I think that's
>> the advantage that Fedora can provide -- a group of knowledgeable folks
>> who share and refine the best tools. Red Hat benefits if those tools,
>> over time, emerge into a Product for which Red Hat can sell support.
>>
>
> Tools that help our users do what? It can't be cloud stuff because at
> that point it's circular reasoning.
>
> -Mike
Well there are three components of cloud stuff
1) The images that run the guests, the hypervisor, or node.
2) Cloud management, They manage not only the underlying nodes but also
the guest on the nodes.
3) The guests
There are three components of virtualization:
1) The hosts that run the guests
2) A way to manage the guests.
3) The guests.
I hope I don't become that cranky guy. But as someone that's been using
virtualization for a long time and get the difference between clouds and
virtualization... I see the majority of the planet doesn't see the
difference and it bugs me to no end because it causes decisions, planning,
resource commitments to be completely misplaced.
-Mike
3:55 p.m.
On Wed, 2010-01-20 at 15:44 -0600, Mike McGrath wrote:
I hope I don't become that cranky guy. But as someone that's
been using
virtualization for a long time and get the difference between clouds and
virtualization... I see the majority of the planet doesn't see the
difference and it bugs me to no end because it causes decisions, planning,
resource commitments to be completely misplaced.
It would then make sense for one of the first things this SIG should do
is define 'What is a Cloud' vs 'What is a virtualized guest', or some
other comparison, so that we in the SIG and those outside the SIG know
what it is exactly we're focused on.
I admit, the distinction is very fuzzy to me.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:56 p.m.
On Wed, 20 Jan 2010, David Huff wrote:
> Tools that help our users do what? It can't be cloud stuff
because at
> that point it's circular reasoning.
>
> -Mike
Well there are three components of cloud stuff
1) The images that run the guests, the hypervisor, or node.
2) Cloud management, They manage not only the underlying nodes but also
the guest on the nodes.
3) The guests
The problem is that Fedora fits into all of these places. For the EC2
users we are focused on #3, for Ovirt, RHEV-H, and other cloud
deployments #1, and for Fedora infrastructure we are focused on all
three but mainly #2?
So how do we approach this?
By bounding the handful of problems that we *know* we need to solve that
pertain to "cloud".
There can be no doubt that "getting Fedora images to work on EC2" falls
under "cloud".
There can be little doubt that "getting Fedora images to work on other
public clouds" also falls under cloud, and one hopes that the processes
bear some resemblance to one another.
There can be little doubt that "moving a workload from this public cloud
to that public cloud" falls under cloud, since that's largely the
point of Deltacloud -- although there is some doubt about how many people
will be keen on that particular use case.
There's all kinds of doubt about "private cloud", and where that separates
from plain ol' "managing a bunch of VMs" -- which is why, I think, we
start with the public cloud cases. Because (a) we really *need* to get
those squared away so that Fedora doesn't end up with lots of crappy
images floating around the public cloud providers, and (b) getting those
use cases straightened out will give us some insights (I hope) about how
private clouds work, and the differences between "private cloud" and
"plain ol' VM management". Which may be vanishingly few, and dependent
largely upon context.
Here's a use case I hear described all the time:
* Developer has hot idea.
* Developer asks for IT resources from Big Bastard Company to implement
idea.
* IT staff at BBC says "fill out these fifty forms and we'll get back to
you a fortnight after never ever."
* Developer plunks down credit card for EC2 instance and expenses it as
"lunch for client", since the monthly cost is roughly equivalent.
* Developer gets cool proof-of-concept working on cloud! While
inadvertently ending up dependent on lots of particular "cloud-isms",
like, say, Amazon's Elastic Block Storage.
* Boss says "WANT".
* IT staff says "oh crap, now how do we move this thing in-house?"
One day this discussion may have more meat. One day Deltacloud may be
more relevant. One day the relationships between public and private
clouds will be crystal clear. In the meantime, I just wanna see people I
know using the *public cloud* as it exists today to solve actual problems,
so we can be speaking from a position of understanding, rather than
talking hypotheticals.
--g
--
Computer Science professors should be teaching open source.
Help make it happen. Visit http://teachingopensource.org.
4:24 p.m.
There can be little doubt that "getting Fedora images to work on
other
public clouds" also falls under cloud, and one hopes that the processes
bear some resemblance to one another.
There can be little doubt that "moving a workload from this public cloud
to that public cloud" falls under cloud, since that's largely the
point of Deltacloud -- although there is some doubt about how many people
will be keen on that particular use case.
There's all kinds of doubt about "private cloud", and where that separates
from plain ol' "managing a bunch of VMs" -- which is why, I think, we
start with the public cloud cases. Because (a) we really *need* to get
those squared away so that Fedora doesn't end up with lots of crappy
images floating around the public cloud providers, and (b) getting those
use cases straightened out will give us some insights (I hope) about how
private clouds work, and the differences between "private cloud" and
"plain ol' VM management". Which may be vanishingly few, and dependent
largely upon context.
The definitions of "cloud" is very fuzzy. At work (enterprise hosting)
there's constant debate and no consensus! The way I see it and the way cloud
services differ from "managing a bunch of VMs" (and hell I do a LOT of that)
is predominately to do with the management of the VM. Things like automatic
provisioning (creation, configuration and tear down). Most of cloud style
things are designed to be for short term style stuff whether it be for a
short period to cover a peak period or medium term for the developer to
create the "cool app". The idea is that either through a web interface or an
automated deployment system something requests a "App server" and then gets
provided an IP of the service, it generally doesn't matter where it is etc
it just is. The Managed VMs are much more specific, generally permanent and
are managed in terms of location, access, QoS etc.
The other component of "cloud" is obviously storage, probably needs to be
added to the discussion list too.
Cheers,
Peter
10:17 p.m.
On Wed, Jan 20, 2010 at 4:56 PM, Greg DeKoenigsberg <gdk(a)redhat.com> wrote:
On Wed, 20 Jan 2010, David Huff wrote:
>> Tools that help our users do what? It can't be cloud stuff because at
>> that point it's circular reasoning.
>
> Well there are three components of cloud stuff
[snip]
> The problem is that Fedora fits into all of these places. For
the EC2
> users we are focused on #3, for Ovirt, RHEV-H, and other cloud
> deployments #1, and for Fedora infrastructure we are focused on all
> three but mainly #2?
>
> So how do we approach this?
By bounding the handful of problems that we *know* we need to solve that
pertain to "cloud".
Which is *exactly* why I think that trying to propose some general
purpose "cloud" group is an effort that's just going to be filled with
hot air. Which is exactly what happens on *every single cloud group
that exists today on the internet*. And it happens because of a lack
of consensus around what the term means. I have one meaning, you have
another, dhuff has a third, and so on.
There can be no doubt that "getting Fedora images to work on
EC2" falls
under "cloud".
If we're saying this is the purpose of the group, then let's say it.
Don't tip toe around it or try to make it out to be some general
overarching, incredible effort. Doing this and *just this alone* is
more than enough reason for existence. And by constraining the scope,
yes, it means some people feel like "their need" isn't being covered.
But that's okay. They can coordinate the people interested in their
need. The nice thing is that then there's some way that we can say
that a group is successful.
There can be little doubt that "getting Fedora images to work on
other
public clouds" also falls under cloud, and one hopes that the processes
bear some resemblance to one another.
bwahaha. bwahahaha. bwahahahahahahahha. :-)
One cloud != another cloud. There are pretty fundamental differences
in their operating models that aren't something you just abstract
away. And those differences are actually kind of important and part
of why people will choose one cloud provider over another. The
differences end up having a distinct impact on everything from systems
management to how you want to build out apps on top of them. Those
differences become even more pronounced at the level of "running the
OS under the constraints imposed by the provider's environment".
[snip]
One day this discussion may have more meat. One day Deltacloud may
be
more relevant. One day the relationships between public and private
clouds will be crystal clear. In the meantime, I just wanna see people I
know using the *public cloud* as it exists today to solve actual problems,
so we can be speaking from a position of understanding, rather than
talking hypotheticals.
I'd actually change this statement a little bit. I want to see people
I know using EC2 to solve actual problems able to in good conscience
use Fedora without having to worry about it being several year old
versions of Fedora. The sort of second level on top of that would
then to being able to use Fedora in Fedora-y ways rather than the
bastardized ways that you end up having to do some stuff with EC2
today. Which the encompasses a huge amount of stuff including have
kernels/ramdisks that can be used, Fedora images actually being
available, it being possible to build one's own Fedora-based image for
your own problems, etc.
Stating it like this means that we have a _real_ concrete thing to
target. Not some ephemeral, undefined "cloud" to argue about what is
constituted by it.
- Jeremy
1:04 a.m.
On Wed, 20 Jan 2010, Jeremy Katz wrote:
> By bounding the handful of problems that we *know* we need to
solve that
> pertain to "cloud".
Which is *exactly* why I think that trying to propose some general
purpose "cloud" group is an effort that's just going to be filled with
hot air. Which is exactly what happens on *every single cloud group
that exists today on the internet*. And it happens because of a lack
of consensus around what the term means. I have one meaning, you have
another, dhuff has a third, and so on.
Except, of course, that we've actually got an initial set of tasks
defined. Whodathunkit?
> There can be no doubt that "getting Fedora images to work on
EC2" falls
> under "cloud".
If we're saying this is the purpose of the group, then let's say it.
Actually, that's not what I'm saying at all, Jeremy. I'm saying that this
is a great initial goal that we can all agree on, while we also have a
place to discuss other efforts that may (or may not) have commonalities to
this effort.
Don't tip toe around it or try to make it out to be some general
overarching, incredible effort. Doing this and *just this alone* is
more than enough reason for existence. And by constraining the scope,
yes, it means some people feel like "their need" isn't being covered.
But that's okay. They can coordinate the people interested in their
need. The nice thing is that then there's some way that we can say that
a group is successful.
> There can be little doubt that "getting Fedora images to work on other
> public clouds" also falls under cloud, and one hopes that the processes
> bear some resemblance to one another.
bwahaha. bwahahaha. bwahahahahahahahha. :-)
One cloud != another cloud. There are pretty fundamental differences
in their operating models that aren't something you just abstract
away. And those differences are actually kind of important and part
of why people will choose one cloud provider over another. The
differences end up having a distinct impact on everything from systems
management to how you want to build out apps on top of them. Those
differences become even more pronounced at the level of "running the
OS under the constraints imposed by the provider's environment".
You may be right. But guess what? You may also *not* be right! And I'd
rather actually *explore* this idea, instead of making an a priori
assumption that IT WON'T WORK!!!
I'd actually change this statement a little bit. I want to see
people
I know using EC2 to solve actual problems able to in good conscience
use Fedora without having to worry about it being several year old
versions of Fedora. The sort of second level on top of that would
then to being able to use Fedora in Fedora-y ways rather than the
bastardized ways that you end up having to do some stuff with EC2
today. Which the encompasses a huge amount of stuff including have
kernels/ramdisks that can be used, Fedora images actually being
available, it being possible to build one's own Fedora-based image for
your own problems, etc.
Stating it like this means that we have a _real_ concrete thing to
target. Not some ephemeral, undefined "cloud" to argue about what is
constituted by it.
See, this is why this conversation is moving along IN TWO DIFFERENT
THREADS. It's possible to focus on one set of tasks, while having other
conversations that are not directly related.
--g
--
Computer Science professors should be teaching open source.
Help make it happen. Visit http://teachingopensource.org.
5202
days inactive
5203
days old
10 comments
7 participants
participants (7)
-
Chad Tindel -
David Huff -
Greg DeKoenigsberg -
Jeremy Katz -
Jesse Keating -
Mike McGrath -
Peter Robinson