Open Stack

Thank you for your reply.

This approach has 3 disadvantages that I can think of:

1. An image might have configurations processes that only happen on the
first boot and require user input. This is a probable use-case
2. Not all images support cloud-init
3. This creates an unnecessary load on the compute node.

I believe a create-in-shutoff-state is a more scalable, more robust
approach.

Shoham Peller

On Wed, Jan 27, 2016 at 11:06 AM, Rui Chen <chenrui.momo at gmail.com> wrote:

> Looks like we can use user_data and cloud-init to do this stuff.
>
> Adding the following content into user_data.txt and launch instance like
> this: nova boot --user-data user_data.txt ...,
> the instance will shutdown after boot is finished.
>
> power_state:
>  mode: poweroff
>  message: Bye Bye
>
> You can find more details in cloud-init document[1].
>
> [1]:
> https://github.com/number5/cloud-init/blob/master/doc/examples/cloud-config.txt
>
> 2016-01-22 3:32 GMT+08:00 Fox, Kevin M <Kevin.Fox at pnnl.gov>:
>
>> The nova instance user spec has a use case.
>> https://review.openstack.org/#/c/222293/
>>
>> Thanks,
>> Kevin
>> ________________________________________
>> From: Matt Riedemann [mriedem at linux.vnet.ibm.com]
>> Sent: Thursday, January 21, 2016 7:32 AM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [nova] Feature suggestion - API for creating
>> VM without powering it up
>>
>> On 1/20/2016 10:57 AM, Shoham Peller wrote:
>> > Hi,
>> >
>> > I would like to suggest a feature in nova to allow creating a VM,
>> > without powering it up.
>> >
>> > If the user will be able to create a stopped VM, it will allow for
>> > better flexibility and user automation.
>> >
>> > I can personally say such a feature would greatly improve comfortability
>> > of my work with nova - currently we shutdown each vm manually as we're
>> > creating it.
>> > What do you think?
>> >
>> > Regards,
>> > Shoham Peller
>> >
>> >
>> >
>> __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> What is your use case?
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160127/0a3818a2/attachment.html>