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

Chris Friesen chris.friesen at windriver.com
Mon Mar 10 21:52:43 UTC 2014


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?

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.

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.

Chris







More information about the OpenStack-dev mailing list