Open Stack

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>> 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>>> 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>>]
>
>         Sent: Friday, 1 July 2011 7:47 PM
>         To: Rankine, Terry (CESRE, Kensington)
>         Cc:<openstack-operators at lists.____openstack.org
>         <http://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>__>>__> 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://openstack.org>
>         <mailto:Openstack-operators at __lists.openstack.org
>         <mailto:Openstack-operators at lists.openstack.org>><mailto:Op__enstack__-operators at lists.__openstack.org
>         <mailto:Openstack__-operators at 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>>
>         ___________________________________________________
>         Openstack-operators mailing list
>         Openstack-operators at lists.__op__enstack.org <http://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>>
>
>         ___________________________________________________
>         Openstack-operators mailing list
>         Openstack-operators at lists.__op__enstack.org <http://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>>
>
>
>