<div dir="ltr">Hi Jay,<br>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.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 6:15 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, 2014-03-10 at 15:52 -0600, Chris Friesen wrote:<br>
> On 03/10/2014 02:58 PM, Jay Pipes wrote:<br>
> > On Mon, 2014-03-10 at 16:30 -0400, Shawn Hartsock wrote:<br>
> >> While I understand the general argument about pets versus cattle. The<br>
> >> question is, would you be willing to poke a few holes in the strict<br>
> >> "cattle" abstraction for the sake of pragmatism. Few shops are going<br>
> >> to make the direct transition in one move. Poking a hole in the cattle<br>
> >> abstraction allowing them to keep a pet VM might be very valuable to<br>
> >> some shops making a migration.<br>
> ><br>
> > Poking holes in cattle aside, my experience with shops that prefer the<br>
> > pets approach is that they are either:<br>
> ><br>
> >   * Not managing their servers themselves at all and just relying on some<br>
> > IT operations organization to manage everything for them, including all<br>
> > aspects of backing up their data as well as failing over and balancing<br>
> > servers, or,<br>
> >   * Hiding behind rationales of "needing to be secure" or "needing 100%<br>
> > uptime" or "needing no customer disruption" in order to avoid any change<br>
> > to the status quo. This is because the incentives inside legacy IT<br>
> > application development and IT operations groups are typically towards<br>
> > not rocking the boat in order to satisfy unrealistic expectations and<br>
> > outdated interface agreements that are forced upon them by management<br>
> > chains that haven't crawled out of the waterfall project management funk<br>
> > of the 1980s.<br>
> ><br>
> > Adding pet-based features to Nova would, IMO, just perpetuate the above<br>
> > scenarios and incentives.<br>
><br>
> What about the cases where it's not a "preference" but rather just the<br>
> inertia of pre-existing systems and procedures?<br>
<br>
</div></div>You mean what I wrote in the second bullet point above?<br>
<div class=""><br>
> If we can get them in the door with enough support for legacy stuff,<br>
> then they might be easier to convince to do things the "cloud" way in<br>
> the future.<br>
<br>
</div>Yes, fair point, and that's what Shawn was saying as well. Just noting<br>
that in my experience, the second part of the above sentence just<br>
doesn't happen. Once you bring them over and offer them the tools from<br>
their legacy environment, they aren't interested in changing. :)<br>
<div class=""><br>
> If we stick with the hard-line cattle-only approach we run the risk of<br>
> alienating them completely since redoing everything at once is generally<br>
> not feasible.<br>
<br>
</div>Yes, I understand that. I'm actually fine with including functionality<br>
like memory snapshotting, but only if under no circumstances does it<br>
negatively impact the service of compute to other tenants/users and will<br>
not negatively impact the scaling factor of Nova either.<br>
<br>
I'm just not as optimistic as you are that once legacy IT folks have<br>
their old tools, they will consider changing their habits. ;)<br>
<br>
Best,<br>
-jay<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Qin Zhao<br></div>
</div>