Tom , <br><br>Just thinking out loud, maybe you can pass out your API credentials via metadata in boot time, and then use them to : <br><br><div>- When a user issues "shutdown -h" , is really an alias to post a "Terminate" to the nova API</div>
<div>- Then the instance "suicides" itself and you get what your users are expecting :)</div><div><br>Regards<br><br>Lele</div><div><br></div><div><br><br><div class="gmail_quote">On Tue, Jul 5, 2011 at 9:36 AM, Tom Fifield <span dir="ltr"><<a href="mailto:fifieldt@unimelb.edu.au">fifieldt@unimelb.edu.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
Thanks for your reply!<br>
<br>
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.<br>

<br>
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 ;)<br>
<br>
Regards,<br>
<br>
Tom<div class="im"><br>
<br>
On 07/05/2011 10:29 PM, Leandro Reox wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Tom,<br>
<br>
I dont know if croning the "Terminate" for instances in "shutdown" state<br>
is a good idea, after a Physical node restart the instances running in<br>
that node stays in shutdown mode after the node comes back, you can<br>
"re-awake" them by issuing nova reboot, maybe a cleaner an usefull<br>
script will try to "reboot" the instance and if doest succeed terminate<br>
them, just an idea.<br>
<br>
Regards<br>
Lele<br>
<br>
On Tue, Jul 5, 2011 at 1:50 AM, Tom Fifield <<a href="mailto:fifieldt@unimelb.edu.au" target="_blank">fifieldt@unimelb.edu.au</a><br></div><div class="im">
<mailto:<a href="mailto:fifieldt@unimelb.edu.au" target="_blank">fifieldt@unimelb.edu.<u></u>au</a>>> wrote:<br>
<br>
    Hi,<br>
<br>
    Echoing this request - it's very handy on Amazon EC2 when a shutdown<br>
    -h now command results in instance termination.<br>
<br>
    Is there a reason for the difference in OpenStack, or is this just<br>
    how it was implemented? :)<br>
<br>
<br>
    I'd probably be writing a cron script to look at the database to<br>
    'terminate' instances in 'shutdown' state and thereby freeing their<br>
    resources...<br>
<br>
<br>
    Regards,<br>
<br>
    Tom<br>
<br>
<br>
    On 07/03/2011 11:44 PM, Terry.Rankine@csiro.au wrote:<br>
<br>
        Wont it need my EC2 credentials on the VM then?<br>
<br>
        The credentials used to start the VM are not stored on the VM. I<br>
        guess I can pass them in via the start-up string, but I would<br>
        prefer if there was another way.<br>
<br>
        Any other thoughts?<br>
<br>
        Terry<br>
        ______________________________<u></u>____<br></div>
        From: Mike Marrotte [<a href="mailto:marrotte@gmail.com" target="_blank">marrotte@gmail.com</a> <mailto:<a href="mailto:marrotte@gmail.com" target="_blank">marrotte@gmail.com</a>>]<div class="im"><br>
        Sent: Friday, 1 July 2011 7:47 PM<br>
        To: Rankine, Terry (CESRE, Kensington)<br>
        Cc:<openstack-operators@lists.<u></u>__<a href="http://openstack.org" target="_blank">openstack.org</a><br></div>
        <mailto:<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@<u></u>lists.openstack.org</a>>><div><div></div><div class="h5"><br>
        Subject: Re: [Openstack-operators] New to Open Stack - shutdown<br>
        vs terminate<br>
<br>
        Sure. Just install the euca2ools on the guest and write a script.<br>
<br>
        Sent from my iPhone<br>
<br>
        On Jul 1, 2011, at 1:07<br>
        AM,<Terry.Rankine@csiro.au<__<u></u>mailto:<a href="mailto:Terry.Rankine@csiro.au" target="_blank">Terry.Rankine@csiro.au</a><br>
        <mailto:<a href="mailto:Terry.Rankine@csiro.au" target="_blank">Terry.Rankine@csiro.au</a><u></u>>>__> wrote:<br>
<br>
        Hi Guys<br>
        I am building an ‘worker image’ for an on-demand specific<br>
        ‘compute this’ workflow.<br>
        The image is totally aware of its success or failure of the<br>
        ‘compute this’ task, and uploads its output back to S3 storage.<br>
        Since the VM is the best thing to know about success/failure, I<br>
        figure it should also be the right thing to determine its end of<br>
        life (shutdown-dont destroy on failure for debugging, and<br>
        shutdown-terminate-release on success).<br>
        I would like it to automatically shutdown (and terminate<br>
        releasing all resources it held – public IP etc) on success, and<br>
        I would like the VM itself be able to do this. A ‘shutdown –h<br>
        now’ put the image into shutdown mode, but not terminated and<br>
        never released the held resources.<br>
        Is it possible for the VM to ‘shutdown and terminate’ itself?<br>
        Terry<br>
        ______________________________<u></u>___________________<br>
        Openstack-operators mailing list<br>
        Openstack-operators@lists.__<a href="http://openstack.org" target="_blank">op<u></u>enstack.org</a><br></div></div>
        <mailto:<a href="mailto:Openstack-operators@lists.openstack.org" target="_blank">Openstack-operators@<u></u>lists.openstack.org</a>><mailto:<a href="mailto:Openstack__-operators@lists.openstack.org" target="_blank">Op<u></u>enstack__-operators@lists.<u></u>openstack.org</a><div class="im">
<br>
        <mailto:<a href="mailto:Openstack-operators@lists.openstack.org" target="_blank">Openstack-operators@<u></u>lists.openstack.org</a>>__><br>
        <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-operators</a><br>
        <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a>><br>
        ______________________________<u></u>___________________<br>
        Openstack-operators mailing list<br>
        Openstack-operators@lists.__<a href="http://openstack.org" target="_blank">op<u></u>enstack.org</a><br>
        <mailto:<a href="mailto:Openstack-operators@lists.openstack.org" target="_blank">Openstack-operators@<u></u>lists.openstack.org</a>><br>
        <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-operators</a><br>
        <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a>><br>
<br>
    ______________________________<u></u>___________________<br>
    Openstack-operators mailing list<br>
    Openstack-operators@lists.__<a href="http://openstack.org" target="_blank">op<u></u>enstack.org</a><br>
    <mailto:<a href="mailto:Openstack-operators@lists.openstack.org" target="_blank">Openstack-operators@<u></u>lists.openstack.org</a>><br>
    <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-operators</a><br>
    <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a>><br>
<br>
<br>
</div></blockquote>
</blockquote></div><br></div>