[openstack-dev] [nova] a question about instance snapshot
laserjetyang at gmail.com
Tue Mar 11 06:30:04 UTC 2014
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 <chaochin at 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 <jaypipes at 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
>> > >> 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
>> > > IT operations organization to manage everything for them, including
>> > > 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
>> > > uptime" or "needing no customer disruption" in order to avoid any
>> > > 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
>> > > of the 1980s.
>> > >
>> > > Adding pet-based features to Nova would, IMO, just perpetuate the
>> > > 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. ;)
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> Qin Zhao
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev