openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2012/1/30 Dan Prince <princepd@xxxxxxxxxxxxxx>:
> On Mon, Jan 30, 2012 at 1:05 PM, Brian Waldon <brian.waldon@xxxxxxxxxxxxx>
> 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/