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.m...@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....@pnnl.gov>: > >> The nova instance user spec has a use case. >> https://review.openstack.org/#/c/222293/ >> >> Thanks, >> Kevin >> ________________________________________ >> From: Matt Riedemann [mrie...@linux.vnet.ibm.com] >> Sent: Thursday, January 21, 2016 7:32 AM >> To: openstack-dev@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
