[Openstack-operators] New to Open Stack - shutdown vs terminate

Tom Fifield fifieldt at unimelb.edu.au
Wed Jul 6 00:27:08 UTC 2011


Thanks for your support Michael!

I'll take a look at the OpenStack code - that seems like a relatively 
straightforward change to make in nova/virt/libvirt_conn.py :D

Terry - do you think this is something you could use too? Sorry for 
hijacking your thread!

Regards,

Tom

On 07/06/2011 01:02 AM, Michael Marrotte wrote:
>
> http://libvirt.org/formatdomain.html
>
>
>       Lifecycle control
>
> It is sometimes necessary to override the default actions taken when a
> guest OS triggers a lifecycle operation. The following collections of
> elements allow the actions to be specified. A common use case is to
> force a reboot to be treated as a poweroff when doing the initial OS
> installation. This allows the VM to be re-configured for the first
> post-install bootup.
>
>    ...
>    <on_poweroff>destroy</on_poweroff>
>    <on_reboot>restart</on_reboot>
>    <on_crash>restart</on_crash>
>    ...
>
> |on_poweroff|
>     The content of this element specifies the action to take when the
>     guest requests a poweroff.
> |on_reboot|
>     The content of this element specifies the action to take when the
>     guest requests a reboot.
> |on_crash|
>     The content of this element specifies the action to take when the
>     guest crashes.
>
> Each of these states allow for the same four possible actions.
>
> |destroy|
>     The domain will be terminated completely and all resources released
> |restart|
>     The domain will be terminated, and then restarted with the same
>     configuration
> |preserve|
>     The domain will be terminated, and its resource preserved to allow
>     analysis.
> |rename-restart|
>     The domain will be terminated, and then restarted with a new name
>
> on_crash supports these additional actions since 0.8.4.
>
> |coredump-destroy|
>     The crashed domain's core will be dumped, and then the domain will
>     be terminated completely and all resources released
> |coredump-restart|
>     The crashed domain's core will be dumped, and then the domain will
>     be restarted with the same configuration
>
>
>
> On Tue, Jul 5, 2011 at 10:52 AM, Michael Marrotte <marrotte at gmail.com
> <mailto:marrotte at gmail.com>> wrote:
>
>     At least for KVM, I think you can add something like
>     <on_poweroff>destroy</on_poweroff> to VM definsiont file...
>
>
>     On Tue, Jul 5, 2011 at 8:48 AM, Tom Fifield <fifieldt at unimelb.edu.au
>     <mailto:fifieldt at unimelb.edu.au>> wrote:
>
>         Hi,
>
>         Thanks again - unfortunately this is similar to what Mike
>         Marrotte wrote in a previous email.
>
>         Neither Terry (the original author) or myself appear to be in a
>         situation where we want to, or have the ability to modify things
>         happening inside the guest VM :)
>
>         Regards,
>
>         Tom
>
>
>         On 07/05/2011 10:45 PM, Leandro Reox wrote:
>
>             Tom ,
>
>             Just thinking out loud, maybe you can pass out your API
>             credentials via
>             metadata in boot time, and then use them to :
>
>             - When a user issues "shutdown -h" , is really an alias to
>             post a
>             "Terminate" to the nova API
>             - Then the instance "suicides" itself and you get what your
>             users are
>             expecting :)
>
>             Regards
>
>             Lele
>
>
>
>             On Tue, Jul 5, 2011 at 9:36 AM, Tom Fifield
>             <fifieldt at unimelb.edu.au <mailto:fifieldt at unimelb.edu.au>
>             <mailto:fifieldt at unimelb.edu.__au
>             <mailto:fifieldt at unimelb.edu.au>>> wrote:
>
>             Hi,
>
>             Thanks for your reply!
>
>             I'm dealing with a lot of users who expect the same style as
>             Amazon,
>             which as I mentioned below is that within a guest VM
>             'shutdown -h
>             now' is like saying "I don't want this instance anymore".
>             This is
>             the 'terminate' state for guest VMs, hence the cron to clean
>             it up.
>
>             Good point about recovery from nova-compute host issues
>             though. We
>             only want to terminate instances that have been taken down
>             by the
>             user, rather than ourselves ;)
>
>             Regards,
>
>             Tom
>
>
>             On 07/05/2011 10:29 PM, Leandro Reox wrote:
>
>             Tom,
>
>             I dont know if croning the "Terminate" for instances in
>             "shutdown" state
>             is a good idea, after a Physical node restart the instances
>             running in
>             that node stays in shutdown mode after the node comes back,
>             you can
>             "re-awake" them by issuing nova reboot, maybe a cleaner an
>             usefull
>             script will try to "reboot" the instance and if doest succeed
>             terminate
>             them, just an idea.
>
>             Regards
>             Lele
>
>             On Tue, Jul 5, 2011 at 1:50 AM, Tom Fifield
>             <fifieldt at unimelb.edu.au <mailto:fifieldt at unimelb.edu.au>
>             <mailto:fifieldt at unimelb.edu.__au
>             <mailto:fifieldt at unimelb.edu.au>>
>             <mailto:fifieldt at unimelb.edu.
>             <mailto:fifieldt at unimelb.edu.>____au
>             <mailto:fifieldt at unimelb.edu.__au
>             <mailto:fifieldt at unimelb.edu.au>>>> wrote:
>
>             Hi,
>
>             Echoing this request - it's very handy on Amazon EC2 when a
>             shutdown
>             -h now command results in instance termination.
>
>             Is there a reason for the difference in OpenStack, or is
>             this just
>             how it was implemented? :)
>
>
>             I'd probably be writing a cron script to look at the database to
>             'terminate' instances in 'shutdown' state and thereby
>             freeing their
>             resources...
>
>
>             Regards,
>
>             Tom
>
>
>             On 07/03/2011 11:44 PM, Terry.Rankine at csiro.au wrote:
>
>             Wont it need my EC2 credentials on the VM then?
>
>             The credentials used to start the VM are not stored on the VM. I
>             guess I can pass them in via the start-up string, but I would
>             prefer if there was another way.
>
>             Any other thoughts?
>
>             Terry
>             ______________________________________
>             From: Mike Marrotte [marrotte at gmail.com
>             <mailto:marrotte at gmail.com>
>             <mailto:marrotte at gmail.com <mailto:marrotte at gmail.com>>
>             <mailto:marrotte at gmail.com <mailto:marrotte at gmail.com>
>
>             <mailto:marrotte at gmail.com <mailto:marrotte at gmail.com>>>]
>
>             Sent: Friday, 1 July 2011 7:47 PM
>             To: Rankine, Terry (CESRE, Kensington)
>             Cc:<openstack-operators at lists.______openstack.org
>             <http://openstack.org>
>             <http://openstack.org>
>
>             <mailto:openstack-operators@
>             <mailto:openstack-operators@>____lists.openstack.org
>             <http://lists.openstack.org>
>             <mailto:openstack-operators at __lists.openstack.org
>             <mailto:openstack-operators at lists.openstack.org>>>>
>
>             Subject: Re: [Openstack-operators] New to Open Stack - shutdown
>             vs terminate
>
>             Sure. Just install the euca2ools on the guest and write a
>             script.
>
>             Sent from my iPhone
>
>             On Jul 1, 2011, at 1:07
>             AM,<Terry.Rankine at csiro.au<______mailto:Terry.Rankine at csiro.au
>             <mailto:Terry.Rankine at csiro.au>
>             <mailto:Terry.Rankine at csiro.au
>             <mailto:Terry.Rankine at csiro.au>__>
>             <mailto:Terry.Rankine at csiro.au <mailto:Terry.Rankine at csiro.au>
>             <mailto:Terry.Rankine at csiro.au
>             <mailto:Terry.Rankine at csiro.au>__>__>>__> wrote:
>
>             Hi Guys
>             I am building an ‘worker image’ for an on-demand specific
>             ‘compute this’ workflow.
>             The image is totally aware of its success or failure of the
>             ‘compute this’ task, and uploads its output back to S3 storage.
>             Since the VM is the best thing to know about success/failure, I
>             figure it should also be the right thing to determine its end of
>             life (shutdown-dont destroy on failure for debugging, and
>             shutdown-terminate-release on success).
>             I would like it to automatically shutdown (and terminate
>             releasing all resources it held – public IP etc) on success, and
>             I would like the VM itself be able to do this. A ‘shutdown –h
>             now’ put the image into shutdown mode, but not terminated and
>             never released the held resources.
>             Is it possible for the VM to ‘shutdown and terminate’ itself?
>             Terry
>             _____________________________________________________
>             Openstack-operators mailing list
>             Openstack-operators at lists.__op____enstack.org
>             <http://op__enstack.org> <http://openstack.org>
>
>             <mailto:Openstack-operators@
>             <mailto:Openstack-operators@>____lists.openstack.org
>             <http://lists.openstack.org>
>             <mailto:Openstack-operators at __lists.openstack.org
>             <mailto:Openstack-operators at lists.openstack.org>>><mailto:O__p__enstack__-operators at lists.
>             <mailto:Op__enstack__-operators at lists.>____openstack.org
>             <http://openstack.org>
>
>             <mailto:Openstack__-operators at __lists.openstack.org
>             <mailto:Openstack__-operators at lists.openstack.org>>
>
>             <mailto:Openstack-operators@
>             <mailto:Openstack-operators@>____lists.openstack.org
>             <http://lists.openstack.org>
>             <mailto:Openstack-operators at __lists.openstack.org
>             <mailto:Openstack-operators at lists.openstack.org>>>__>
>             http://lists.openstack.org/______cgi-bin/mailman/listinfo/______openstack-operators
>             <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators>
>             <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators
>             <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>>
>             <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators
>             <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>
>             <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
>             <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>>>
>             _____________________________________________________
>             Openstack-operators mailing list
>             Openstack-operators at lists.__op____enstack.org
>             <http://op__enstack.org> <http://openstack.org>
>
>             <mailto:Openstack-operators@
>             <mailto:Openstack-operators@>____lists.openstack.org
>             <http://lists.openstack.org>
>             <mailto:Openstack-operators at __lists.openstack.org
>             <mailto:Openstack-operators at lists.openstack.org>>>
>             http://lists.openstack.org/______cgi-bin/mailman/listinfo/______openstack-operators
>             <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators>
>             <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators
>             <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>>
>             <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators
>             <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>
>             <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
>             <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>>>
>
>             _____________________________________________________
>             Openstack-operators mailing list
>             Openstack-operators at lists.__op____enstack.org
>             <http://op__enstack.org> <http://openstack.org>
>
>             <mailto:Openstack-operators@
>             <mailto:Openstack-operators@>____lists.openstack.org
>             <http://lists.openstack.org>
>             <mailto:Openstack-operators at __lists.openstack.org
>             <mailto:Openstack-operators at lists.openstack.org>>>
>             http://lists.openstack.org/______cgi-bin/mailman/listinfo/______openstack-operators
>             <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators>
>             <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators
>             <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>>
>             <http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-operators
>             <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators>
>             <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
>             <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>>>
>
>
>
>         _________________________________________________
>         Openstack-operators mailing list
>         Openstack-operators at lists.__openstack.org
>         <mailto:Openstack-operators at lists.openstack.org>
>         http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>
>
>



More information about the Openstack-operators mailing list