[openstack-dev] [nova] a question about instance snapshot

Qin Zhao chaochin at gmail.com
Tue Mar 11 05:37:04 UTC 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140311/37be6b80/attachment.html>


More information about the OpenStack-dev mailing list