New to Open Stack - shutdown vs terminate

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Terry.Rankine@csiro.au
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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110701/47601d5e/attachment.html>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Michael Marrotte
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> 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.openstack.org
> 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/20110701/bf3e9e59/attachment.html>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Terry.Rankine@csiro.au
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]
Sent: Friday, 1 July 2011 7:47 PM
To: Rankine, Terry (CESRE, Kensington)
Cc: <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>> 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.openstack.org<mailto:Openstack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Tom Fifield
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]
> Sent: Friday, 1 July 2011 7:47 PM
> To: Rankine, Terry (CESRE, Kensington)
> Cc:<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>>  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.openstack.org<mailto:Openstack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Leandro Reox
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> 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]
>> Sent: Friday, 1 July 2011 7:47 PM
>> To: Rankine, Terry (CESRE, Kensington)
>> Cc:<openstack-operators at 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>**>  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.**openstack.org<Openstack-operators at lists.openstack.org>
>> <mailto: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>
>> ______________________________**_________________
>> 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>
>>
>>  ______________________________**_________________
> 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/c8d4ba1d/attachment.html>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Tom Fifield
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>> 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>]
>         Sent: Friday, 1 July 2011 7:47 PM
>         To: Rankine, Terry (CESRE, Kensington)
>         Cc:<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>>__> 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.__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>
>         _________________________________________________
>         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>
>
>     _________________________________________________
>     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>
>
>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Leandro Reox
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> 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>>> 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
>> >]
>>
>>        Sent: Friday, 1 July 2011 7:47 PM
>>        To: Rankine, Terry (CESRE, Kensington)
>>        Cc:<openstack-operators at 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**>>__> 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@**lists.openstack.org<Openstack-operators at lists.openstack.org>
>> ><mailto:Op**enstack__-operators at lists.**openstack.org<Openstack__-operators at 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>
>> >
>>        ______________________________**___________________
>>        Openstack-operators mailing list
>>        Openstack-operators at lists.__op**enstack.org <http://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>
>> >
>>
>>    ______________________________**___________________
>>    Openstack-operators mailing list
>>    Openstack-operators at lists.__op**enstack.org <http://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>
>> >
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110705/37bdadbb/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Tom Fifield
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>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Michael Marrotte
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-0001.html>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Michael Marrotte
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_poweroffThe content of this element specifies the action to take when the
guest requests a poweroff.on_rebootThe content of this element specifies the
action to take when the guest requests a reboot.on_crashThe content of this
element specifies the action to take when the guest crashes.

Each of these states allow for the same four possible actions.
destroyThe domain will be terminated completely and all resources released
restartThe domain will be terminated, and then restarted with the same
configurationpreserveThe domain will be terminated, and its resource
preserved to allow analysis.rename-restartThe domain will be terminated, and
then restarted with a new name

on_crash supports these additional actions since 0.8.4.
coredump-destroyThe crashed domain's core will be dumped, and then the
domain will be terminated completely and all resources released
coredump-restartThe 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>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>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/928d7a64/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Tom Fifield
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>
>
>
>

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Terry.Rankine@csiro.au
Yes - but I am a bit more 'abstract'

I need an 'INSIDE VM' way to say 'I am all good, shutdown and release everything' without needing EC2 credentials.

I actually don't care how it happens, but there should be a way for:
* the VM to decide that it's ok to do it,
* and it shouldn't need credentials to do it.

If 'shutdown -h' is that way - then so be it!

Regards,
Terry Rankine

-----Original Message-----
From: openstack-operators-bounces at lists.openstack.org [mailto:openstack-operators-bounces at lists.openstack.org] On Behalf Of Tom Fifield
Sent: Wednesday, 6 July 2011 8:27 AM
To: Michael Marrotte
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] New to Open Stack - shutdown vs terminate

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>
>
>
>
_______________________________________________
Openstack-operators mailing list
Openstack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply | Threaded
Open this post in threaded view
|

New to Open Stack - shutdown vs terminate

Terry.Rankine@csiro.au
Hi Guys

I haven't seen any updates on this one.

Did it get resolved? Was there a 'ticket'/issue created I can subscribe to?

Terry Rankine

-----Original Message-----
From: openstack-operators-bounces at lists.openstack.org
[mailto:openstack-operators-bounces at lists.openstack.org] On Behalf Of
Terry.Rankine at csiro.au
Sent: Wednesday, 6 July 2011 9:20 AM
To: fifieldt at unimelb.edu.au; marrotte at gmail.com
Cc: openstack-operators at lists.openstack.org
Subject: [ExternalEmail] Re: [Openstack-operators] New to Open Stack -
shutdown vs terminate

Yes - but I am a bit more 'abstract'

I need an 'INSIDE VM' way to say 'I am all good, shutdown and release
everything' without needing EC2 credentials.

I actually don't care how it happens, but there should be a way for:
* the VM to decide that it's ok to do it,
* and it shouldn't need credentials to do it.

If 'shutdown -h' is that way - then so be it!

Regards,
Terry Rankine

-----Original Message-----
From: openstack-operators-bounces at lists.openstack.org
[mailto:openstack-operators-bounces at lists.openstack.org] On Behalf Of Tom
Fifield
Sent: Wednesday, 6 July 2011 8:27 AM
To: Michael Marrotte
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] New to Open Stack - shutdown vs terminate

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__-op
erators 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-op
erators
>
<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-opera
tors>
>
<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-opera
tors
>
<http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
>>
>
<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-opera
tors
>
<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-op
erators
>
<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-opera
tors>
>
<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-opera
tors
>
<http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
>>
>
<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-opera
tors
>
<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-op
erators
>
<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-opera
tors>
>
<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-opera
tors
>
<http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-operators
>>
>
<http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-opera
tors
>
<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>
>
>
>
_______________________________________________
Openstack-operators mailing list
Openstack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
Openstack-operators mailing list
Openstack-operators at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5001 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20110714/4d41ae14/attachment-0001.bin>