Not to confuse with stateful vs stateless API....
As we know, EC2 has no state for the instances. If you power-off and terminate a machine, it's gone. You can't start up the exact same VM again. You *can* start up another copy of the same image, but it'll lack any changes you made, of course.
And I consider that to be a Good Thing, when doing cloud computing. If some virtualization fabric provides stateful machines (ie, RHEV-M, VMware), I think it's still best to ignore that if you're truly wanting to deploy using "the cloud methodology".
My view of the cloud is based upon homogeneity, particularly if you're wanting to scale up/down over time, or have instances simply fail. For example, in our JBoss demo, we start with a cluster of 2 AS nodes. As demand increases, we want to add 2 more node *just like* the existing 2 nodes. As demand falls, we want to be able to kill off any 2 of the now 4 nodes, to conserve resources.
If we assume statefulness of the VMs, it seems we're no longer thinking in terms of commodity/utility computing.
I do like EC2's EBS, though, for maintaining data, which should not be ephemeral. Glue that to your DB node. If the DB node fails, mount the storage partition on another copy of the DB node. Or mount it on an updated version of the DB node.
Ultimately, if you develop your images (or portfolio of cooperating images) to behave well in a stateless environment, I think you'll end up follow more "best practices" in terms of fail-over, scalability and management.
If you develop assuming your nodes are stateful, you're also more apt to "park" them somewhere "just in case". Or end up being too reliant upon a very particular instance as it's evolved over time.
Assuming statelessness helps ensure you separate compute resources from storage resources, and have something you can spin up multiple times in a meaningful way. Makes it more cloudy above and beyond just virtualizationy.
But that's just me, feel free to disagree.
-Bob
Bob McWhirter wrote:
Not to confuse with stateful vs stateless API....
As we know, EC2 has no state for the instances. If you power-off and terminate a machine, it's gone. You can't start up the exact same VM again. You *can* start up another copy of the same image, but it'll lack any changes you made, of course.
And I consider that to be a Good Thing, when doing cloud computing. If some virtualization fabric provides stateful machines (ie, RHEV-M, VMware), I think it's still best to ignore that if you're truly wanting to deploy using "the cloud methodology".
My view of the cloud is based upon homogeneity, particularly if you're wanting to scale up/down over time, or have instances simply fail. For example, in our JBoss demo, we start with a cluster of 2 AS nodes. As demand increases, we want to add 2 more node *just like* the existing 2 nodes. As demand falls, we want to be able to kill off any 2 of the now 4 nodes, to conserve resources.
If we assume statefulness of the VMs, it seems we're no longer thinking in terms of commodity/utility computing.
I do like EC2's EBS, though, for maintaining data, which should not be ephemeral. Glue that to your DB node. If the DB node fails, mount the storage partition on another copy of the DB node. Or mount it on an updated version of the DB node.
Ultimately, if you develop your images (or portfolio of cooperating images) to behave well in a stateless environment, I think you'll end up follow more "best practices" in terms of fail-over, scalability and management.
If you develop assuming your nodes are stateful, you're also more apt to "park" them somewhere "just in case". Or end up being too reliant upon a very particular instance as it's evolved over time.
Assuming statelessness helps ensure you separate compute resources from storage resources, and have something you can spin up multiple times in a meaningful way. Makes it more cloudy above and beyond just virtualizationy.
But that's just me, feel free to disagree.
Can we assume a verb such as "persist" which in the case of EC2 will rebundle? It may be wierd since the default behaviour for RHEV-M may be persist-on.
Dunno.
-- bk
I think that'd make sense.
Would it make sense (or be possible) to make RHEV-M non-persist until/ unless someone triggers a 'persist' operation?
And for RHEV-M, would persist not just save the image, but blow it into the template library, similar to how bundling puts it into the image library in EC2?
-Bob
On Jul 9, 2009, at 8:46 AM, Bryan Kearney wrote:
Bob McWhirter wrote:
Not to confuse with stateful vs stateless API.... As we know, EC2 has no state for the instances. If you power-off and terminate a machine, it's gone. You can't start up the exact same VM again. You *can* start up another copy of the same image, but it'll lack any changes you made, of course. And I consider that to be a Good Thing, when doing cloud computing. If some virtualization fabric provides stateful machines (ie, RHEV-M, VMware), I think it's still best to ignore that if you're truly wanting to deploy using "the cloud methodology". My view of the cloud is based upon homogeneity, particularly if you're wanting to scale up/down over time, or have instances simply fail. For example, in our JBoss demo, we start with a cluster of 2 AS nodes. As demand increases, we want to add 2 more node *just like* the existing 2 nodes. As demand falls, we want to be able to kill off any 2 of the now 4 nodes, to conserve resources. If we assume statefulness of the VMs, it seems we're no longer thinking in terms of commodity/utility computing. I do like EC2's EBS, though, for maintaining data, which should not be ephemeral. Glue that to your DB node. If the DB node fails, mount the storage partition on another copy of the DB node. Or mount it on an updated version of the DB node. Ultimately, if you develop your images (or portfolio of cooperating images) to behave well in a stateless environment, I think you'll end up follow more "best practices" in terms of fail-over, scalability and management. If you develop assuming your nodes are stateful, you're also more apt to "park" them somewhere "just in case". Or end up being too reliant upon a very particular instance as it's evolved over time. Assuming statelessness helps ensure you separate compute resources from storage resources, and have something you can spin up multiple times in a meaningful way. Makes it more cloudy above and beyond just virtualizationy. But that's just me, feel free to disagree.
Can we assume a verb such as "persist" which in the case of EC2 will rebundle? It may be wierd since the default behaviour for RHEV-M may be persist-on.
Dunno.
-- bk
another approach, if persistence were a parameter of deploy.. then implementations could throw a "Homey Dont Play That" exception.
-- bk
Bob McWhirter wrote:
I think that'd make sense.
Would it make sense (or be possible) to make RHEV-M non-persist until/unless someone triggers a 'persist' operation?
And for RHEV-M, would persist not just save the image, but blow it into the template library, similar to how bundling puts it into the image library in EC2?
-Bob
On Jul 9, 2009, at 8:46 AM, Bryan Kearney wrote:
Bob McWhirter wrote:
Not to confuse with stateful vs stateless API.... As we know, EC2 has no state for the instances. If you power-off and terminate a machine, it's gone. You can't start up the exact same VM again. You *can* start up another copy of the same image, but it'll lack any changes you made, of course. And I consider that to be a Good Thing, when doing cloud computing. If some virtualization fabric provides stateful machines (ie, RHEV-M, VMware), I think it's still best to ignore that if you're truly wanting to deploy using "the cloud methodology". My view of the cloud is based upon homogeneity, particularly if you're wanting to scale up/down over time, or have instances simply fail. For example, in our JBoss demo, we start with a cluster of 2 AS nodes. As demand increases, we want to add 2 more node *just like* the existing 2 nodes. As demand falls, we want to be able to kill off any 2 of the now 4 nodes, to conserve resources. If we assume statefulness of the VMs, it seems we're no longer thinking in terms of commodity/utility computing. I do like EC2's EBS, though, for maintaining data, which should not be ephemeral. Glue that to your DB node. If the DB node fails, mount the storage partition on another copy of the DB node. Or mount it on an updated version of the DB node. Ultimately, if you develop your images (or portfolio of cooperating images) to behave well in a stateless environment, I think you'll end up follow more "best practices" in terms of fail-over, scalability and management. If you develop assuming your nodes are stateful, you're also more apt to "park" them somewhere "just in case". Or end up being too reliant upon a very particular instance as it's evolved over time. Assuming statelessness helps ensure you separate compute resources from storage resources, and have something you can spin up multiple times in a meaningful way. Makes it more cloudy above and beyond just virtualizationy. But that's just me, feel free to disagree.
Can we assume a verb such as "persist" which in the case of EC2 will rebundle? It may be wierd since the default behaviour for RHEV-M may be persist-on.
Dunno.
-- bk
From: libcloud-list-bounces@redhat.com [mailto:libcloud-list- bounces@redhat.com] On Behalf Of Bob McWhirter I think that'd make sense.
Would it make sense (or be possible) to make RHEV-M non-persist until/ unless someone triggers a 'persist' operation?
[IH] it does today.
And for RHEV-M, would persist not just save the image, but blow it into the template library, similar to how bundling puts it into the image library in EC2?
[IH] RHEV-M supports both modes. But even for stateless VMs, it still creates an instance for them (COW from the template), since you are not supposed to launch same VM multiple times with exact same parameters. For Linux, you can configure this as pxe/parameters/etc. For windows, it is a bit harder, since for domain membership, you need to "initialize" each VM and join it to the domain, exchange passwords for the computer account, etc. We can abstract this differentiation in an external API, but for "regular" virtualization use cases, it is needed. (and don't forget all "regular" virtualization use cases are also called "cloud" today, since it is the current buzz)
From: libcloud-list-bounces@redhat.com [mailto:libcloud-list- bounces@redhat.com] On Behalf Of Bryan Kearney
...
Can we assume a verb such as "persist" which in the case of EC2 will rebundle? It may be wierd since the default behaviour for RHEV-M may be persist-on.
[IH] RHEV-M support setting a node as 'stateless', which means it will not save changes. BUT, since we don't support live snapshots for now, user has to specify before launching the VM this run is not stateless so changes will be saved. Once we have live snapshots, we can go either way.
On the general discussion - yes, stateless is great. Yet there aren't a lot of stateless projects/organization out there. This requires educating the market, and is viewed more as a deficiency of ec2 that a philosophy. There are various use cases of cloud, if we are discussing self provisioning, we can't expect any user will know to configure everything in stateless, configure shared/network storage for files/db/etc. As for use cases, If we take lab management for example, they almost always have to save state, since they want to save the snapshot with the bug that was reproduced, and associate that snapshot to BZ for a developer to be able to investigate further, etc.
On Thu, 2009-07-09 at 16:21 -0400, Itamar Heim wrote:
On the general discussion - yes, stateless is great. Yet there aren't a lot of stateless projects/organization out there.
That's a very important lesson we learned with the stateless project[1] - for some applications and some users it's a perfect fit and exactly what they want, but for many others it's not.
This requires educating the market, and is viewed more as a deficiency of ec2 that a philosophy. There are various use cases of cloud, if we are discussing self provisioning, we can't expect any user will know to configure everything in stateless, configure shared/network storage for files/db/etc.
In the general case, it takes a serious amount of work to make a stateless deployment work; in my mind the issue of stateless/stateful VM's is orthogonal to cloud, I don't see it as directly related to cloud as Bob does. (Don't get me wrong, I would love if the world consisted of stateless machines all with properly managed setups and configurations)
We should keep in mind that libcloud will have to follow what users want and use, and we should not design something like 'all VM's are stateless' into the API.
To get the API started, it's perfectly fine to only support the EC2 stateless model, but we need to keep an open mind as we encounter other clouds.
David
David Lutterkort wrote:
On Thu, 2009-07-09 at 16:21 -0400, Itamar Heim wrote:
On the general discussion - yes, stateless is great. Yet there aren't a lot of stateless projects/organization out there.
That's a very important lesson we learned with the stateless project[1]
- for some applications and some users it's a perfect fit and exactly
what they want, but for many others it's not.
This requires educating the market, and is viewed more as a deficiency of ec2 that a philosophy. There are various use cases of cloud, if we are discussing self provisioning, we can't expect any user will know to configure everything in stateless, configure shared/network storage for files/db/etc.
In the general case, it takes a serious amount of work to make a stateless deployment work; in my mind the issue of stateless/stateful VM's is orthogonal to cloud, I don't see it as directly related to cloud as Bob does. (Don't get me wrong, I would love if the world consisted of stateless machines all with properly managed setups and configurations)
We should keep in mind that libcloud will have to follow what users want and use, and we should not design something like 'all VM's are stateless' into the API.
To get the API started, it's perfectly fine to only support the EC2 stateless model, but we need to keep an open mind as we encounter other clouds.
I say make it a parameter at creation, and let impls throw exceptions.
-- bk
deltacloud-devel@lists.fedorahosted.org