2012/1/30 Dan Prince <princ...@alumni.jmu.edu>: > On Mon, Jan 30, 2012 at 1:05 PM, Brian Waldon <brian.wal...@rackspace.com> > wrote: >> After implementing a working version of file injection on Libvirt, a >> good question was brought up on the merge prop: how should we handle >> a file injection failure? Injection could fail for several reasons: >> missing necessary libraries, unsupported image formats and bad >> permissions are just a few. There seem to be two clear paths forward: >> >> 1) Log an error, set the instance to ERROR, add an asynchronous fault to >> the instance in the db >> 2) Log a warning, move on with the boot process > My preference would be to log a warning and move on with the boot > process (#2). Or perhaps we could address this with some sort of async > error messages concept?
If getting those files injected isn't critical to getting the machine up and running, you can use one of the many other ways to get data into your instances. If the API calls says to inject a file, and we know that failed, we should bail out. I certainly wouldn't want to pay for something that isn't going to work. Sure, most of the times when I've booted things on EC2 or on the Rackspace cloud, I've done so interactively and have had the chance to see any errors, but that's going to be more and more of a niche use case. I fully expect the majority of consumer of OpenStack in the future to be applications wanting more ressources. If we can't deliver on their requests, we should fail early so that they can take appropriate action ASAP. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp