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
