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
This is what I'd prefer. > 2) Log a warning, move on with the boot process But... I do understand Dan's point about prior art here, and not changing the existing behaviour (or at least, the similar scenario of changing admin passwords...) > It's not obvious which of these is the best route to take from a user's > point of view. I'm currently leaning towards option 1 as I wouldn't want to > have an instance come up (and be billed for it) while it wasn't what I > explicitly requested. Right. This is exactly my point of view. > I would love to get some help with this problem. You can either reply > directly to this email, or head over to the merge > prop: https://review.openstack.org/#change,3526 > > > Brian Waldon > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
