Open Stack

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> 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 <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<fifieldt at unimelb.edu.au>
>> >
>>        <mailto:fifieldt at unimelb.edu._**_au
>>        <mailto:fifieldt at unimelb.edu.**au <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<http://lists.openstack.org>
>>        <mailto:openstack-operators@**lists.openstack.org<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://op__enstack.org><
>> http://openstack.org>
>>
>>        <mailto:Openstack-operators at __**lists.openstack.org<http://lists.openstack.org>
>>        <mailto:Openstack-operators@**lists.openstack.org<Openstack-operators at lists.openstack.org>
>> >><mailto:O**p__enstack__-operators at lists.<Op__enstack__-operators at lists.>
>> _**_openstack.org
>>
>>        <mailto:Openstack__-operators@**lists.openstack.org<Openstack__-operators at lists.openstack.org>
>> >
>>
>>        <mailto:Openstack-operators at __**lists.openstack.org<http://lists.openstack.org>
>>        <mailto:Openstack-operators@**lists.openstack.org<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 at __**lists.openstack.org<http://lists.openstack.org>
>>        <mailto:Openstack-operators@**lists.openstack.org<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 at __**lists.openstack.org<http://lists.openstack.org>
>>        <mailto:Openstack-operators@**lists.openstack.org<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<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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110705/1fbcc9b0/attachment-0002.html>