It is defined by the expected behaviour of cinder... and changing that is hard. Allowing the driver to give feedback is also hard, since the API returns long before the driver gets called, so there really isn't an easy route to send feedback, and a 'last status' field or similar in the volume/snap/etc object is rather ugly and can get confusing when several operations on a volume are issued at once...
I'm tentatively suggest that a driver that cannot meet the cinder API expectations (including cloned / from snap volumes being allowed after the removal of their parent) is buggy, not that cinder is buggy for not allowing the driver any behaviour it wants. On 19 June 2014 15:55, Scott Devoid <dev...@anl.gov> wrote: > I agree with Amit on this. There needs to be a way for the driver to > indicate that an operation is not currently possible and include some > descriptive message to indicate why. Right now the volume manager assumes > certain behavioral constraints (e.g. that snapshots are completely decoupled > from clones) when this behavior is actually determined by the underlying > driver. > > ~ Scott > > > On Wed, Jun 18, 2014 at 6:29 PM, Mike Perez <thin...@gmail.com> wrote: >> >> On 10:20 Wed 18 Jun , Amit Das wrote: >> > Implementation issues - If Cinder driver throws an Exception the >> > snapshot >> > will have error_deleting status & will not be usable. If Cinder driver >> > logs >> > the error silently then Openstack will probably mark the snapshot as >> > deleted. >> > >> > What is the appropriate procedure that needs to be followed for above >> > usecase. >> >> I'm not sure what "Openstack will probably mark the snapshot as deleted" >> means. >> If a snapshot gets marked with error_deleting, we don't know what state >> the >> snapshot is in because it could've been a delete that partially finished. >> You >> should leave the cinder volume manager to handle this. It's up to the >> driver to >> say the delete finished or failed, that's it. >> >> -- >> Mike Perez >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev