the live snapshot has some issue on KVM, and I think it is a problem of KVM hypervisor. For VMware, live snapshot is quite mature, and I think it is a good way to start with VMware live snapshot.
On Tue, Mar 11, 2014 at 1:37 PM, Qin Zhao <chaoc...@gmail.com> wrote: > Hi Jay, > When users move from old tools to new cloud tools, they also hope the new > tool can inherit some good and well-known capabilities. Sometimes, assuming > users can change their habit is dangerous. (Eg. removing Windows Start > button). Live-snapshot is indeed a very useful feature of hypervisors, and > it is widely used for several years (especially for VMware). I think it is > not harmful to existing Nova structure and workflow, and will let more > people to adopt OpenStack easier. > > > On Tue, Mar 11, 2014 at 6:15 AM, Jay Pipes <jaypi...@gmail.com> wrote: > >> On Mon, 2014-03-10 at 15:52 -0600, Chris Friesen wrote: >> > On 03/10/2014 02:58 PM, Jay Pipes wrote: >> > > On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote: >> > >> While I understand the general argument about pets versus cattle. The >> > >> question is, would you be willing to poke a few holes in the strict >> > >> "cattle" abstraction for the sake of pragmatism. Few shops are going >> > >> to make the direct transition in one move. Poking a hole in the >> cattle >> > >> abstraction allowing them to keep a pet VM might be very valuable to >> > >> some shops making a migration. >> > > >> > > Poking holes in cattle aside, my experience with shops that prefer the >> > > pets approach is that they are either: >> > > >> > > * Not managing their servers themselves at all and just relying on >> some >> > > IT operations organization to manage everything for them, including >> all >> > > aspects of backing up their data as well as failing over and balancing >> > > servers, or, >> > > * Hiding behind rationales of "needing to be secure" or "needing >> 100% >> > > uptime" or "needing no customer disruption" in order to avoid any >> change >> > > to the status quo. This is because the incentives inside legacy IT >> > > application development and IT operations groups are typically towards >> > > not rocking the boat in order to satisfy unrealistic expectations and >> > > outdated interface agreements that are forced upon them by management >> > > chains that haven't crawled out of the waterfall project management >> funk >> > > of the 1980s. >> > > >> > > Adding pet-based features to Nova would, IMO, just perpetuate the >> above >> > > scenarios and incentives. >> > >> > What about the cases where it's not a "preference" but rather just the >> > inertia of pre-existing systems and procedures? >> >> You mean what I wrote in the second bullet point above? >> >> > If we can get them in the door with enough support for legacy stuff, >> > then they might be easier to convince to do things the "cloud" way in >> > the future. >> >> Yes, fair point, and that's what Shawn was saying as well. Just noting >> that in my experience, the second part of the above sentence just >> doesn't happen. Once you bring them over and offer them the tools from >> their legacy environment, they aren't interested in changing. :) >> >> > If we stick with the hard-line cattle-only approach we run the risk of >> > alienating them completely since redoing everything at once is generally >> > not feasible. >> >> Yes, I understand that. I'm actually fine with including functionality >> like memory snapshotting, but only if under no circumstances does it >> negatively impact the service of compute to other tenants/users and will >> not negatively impact the scaling factor of Nova either. >> >> I'm just not as optimistic as you are that once legacy IT folks have >> their old tools, they will consider changing their habits. ;) >> >> Best, >> -jay >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Qin Zhao > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
