Open Stack

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.

> To be fair, the places where I've heard interest are looking to "walk
> not run" from a pets approach to a cattle approach. This conceit in
> the abstraction might be valuable enough to them to spell the
> difference between cautiously adopting and tacitly rejecting
> OpenStack.
> 
> That's how I would argue *for* the change anyhow, it's not an argument
> based on ideology but on pragmatism.

Yeah, I understand your point, and I do see how it might lead some folks
towards OpenStack.

But then again, I wouldn't port a bunch of Prolog language constructs
and quirks to Python just to lure Prolog and Erlang developers.

In the end, I know I'm probably just over-zealous on this stuff, but I
just can't help it :)

Best,
-jay

> On Mon, Mar 10, 2014 at 3:19 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> > On Mon, 2014-03-10 at 12:13 -0400, Shawn Hartsock wrote:
> >> We have very strong interest in pursing this feature in the VMware
> >> driver as well. I would like to see the revert instance feature
> >> implemented at least.
> >>
> >> When I used to work in multi-discipline roles involving operations it
> >> would be common for us to snapshot a vm, run through an upgrade
> >> process, then revert if something did not upgrade smoothly. This
> >> ability alone can be exceedingly valuable in long-lived virtual
> >> machines.
> >>
> >> I also have some comments from parties interested in refactoring how
> >> the VMware drivers handle snapshots but I'm not certain how much that
> >> plays into this "live snapshot" discussion.
> >
> > I think the reason that there isn't much interest in doing this kind of
> > thing is because the worldview that VMs are pets is antithetical to the
> > worldview that VMs are cattle, and Nova tends to favor the latter (where
> > DRS/DPM on vSphere tends to favor the former).
> >
> > There's nothing about your scenario above of being able to "revert" an
> > instance to a particular state that isn't possible with today's Nova.
> > Snapshotting an instance, doing an upgrade of software on the instance,
> > and then restoring from the snapshot if something went wrong (reverting)
> > is already fully possible to do with the regular Nova snapshot and
> > restore operations. The only difference is that the "live-snapshot"
> > stuff would include saving the memory view of a VM in addition to its
> > disk state. And that, at least in my opinion, is only needed when you
> > are treating VMs like pets and not cattle.
> >
> > Best,
> > -jay
> >
> >> On Mon, Mar 10, 2014 at 12:04 AM, Bohai (ricky) <bohai at huawei.com> wrote:
> >> >> -----Original Message-----
> >> >> From: Alex Xu [mailto:xuhj at linux.vnet.ibm.com]
> >> >> Sent: Sunday, March 09, 2014 10:04 PM
> >> >> To: OpenStack Development Mailing List (not for usage questions)
> >> >> Subject: Re: [openstack-dev] [nova] a question about instance snapshot
> >> >>
> >> >> Hi, Jeremy, the discussion at here
> >> >> http://lists.openstack.org/pipermail/openstack-dev/2013-August/013688.html
> >> >>
> >> >
> >> > I have a great interest in the topic too.
> >> > I read the link you provided, and there is a little confusion for me.
> >> > I agree with the security consideration in the discussion and memory snapshot can't be used for the cloning instance easily.
> >> >
> >> > But I think it's safe for the using for Instance revert.
> >> > And revert the instance to a checkpoint is valuable for the user.
> >> > Why we didn't use it for instance revert in the first step?
> >> >
> >> > Best regards to you.
> >> > Ricky
> >> >
> >> >> Thanks
> >> >> Alex
> >> >> On 2014年03月07日 10:29, Liuji (Jeremy) wrote:
> >> >> > Hi, all
> >> >> >
> >> >> > Current openstack seems not support to snapshot instance with memory and
> >> >> dev states.
> >> >> > I searched the blueprint and found two relational blueprint like below.
> >> >> > But these blueprint failed to get in the branch.
> >> >> >
> >> >> > [1]: https://blueprints.launchpad.net/nova/+spec/live-snapshots
> >> >> > [2]: https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms
> >> >> >
> >> >> > In the blueprint[1], there is a comment,"
> >> >> > We discussed this pretty extensively on the mailing list and in a design
> >> >> summit session.
> >> >> > The consensus is that this is not a feature we would like to have in nova.
> >> >> --russellb "
> >> >> > But I can't find the discuss mail about it. I hope to know why we think so ?
> >> >> > Without memory snapshot, we can't to provide the feature for user to revert
> >> >> a instance to a checkpoint.
> >> >> >
> >> >> > Anyone who knows the history can help me or give me a hint how to find the
> >> >> discuss mail?
> >> >> >
> >> >> > I am a newbie for openstack and I apologize if I am missing something very
> >> >> obvious.
> >> >> >
> >> >> >
> >> >> > Thanks,
> >> >> > Jeremy Liu
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > OpenStack-dev mailing list
> >> >> > OpenStack-dev at lists.openstack.org
> >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> OpenStack-dev mailing list
> >> >> OpenStack-dev at lists.openstack.org
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
>