Open Stack

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
>> 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Qin Zhao
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140311/5f7d76a8/attachment.html>