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
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@redhat.com To: cloud@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud
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.
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
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
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
The images that run the guests, the hypervisor, or node.
Cloud management, They manage not only the underlying nodes but also
the guest on the nodes.
- 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
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.
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
The images that run the guests, the hypervisor, or node.
Cloud management, They manage not only the underlying nodes but also
the guest on the nodes.
- 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.
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
On Wed, Jan 20, 2010 at 4:56 PM, Greg DeKoenigsberg gdk@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
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.
-
Chad Tindel -
David Huff -
Greg DeKoenigsberg -
Jeremy Katz -
Jesse Keating -
Mike McGrath -
Peter Robinson