Hello all,
I'm looking into the use case around an aborted task within vdsmd. AFAICT both engine and vdsClient are unable to deal with an aborted task at present.
Within engine we call HSMStopTaskVDSCommand, this inturn calls stopTask supplying _only_ the task_guid. vdsClient also calls stopTask with only the task_guid argument.
Why does this matter? Well the only was you can kill an aborted task is by passing the force=True argument to the stop method of the task object itself. Without this the _incref method will throw a TaskAborted exception and we will be unable to stop the task.
Could anyone give me some background on why this is the case before I start looking into exposing the force option up the stack to engine and vdsClient.
Relevant code snippets from task.py below.
Thanks in advance,
Lee
vdsm/storage/task.py
1198 def stop(self, force=False): 1199 self.log.debug("stopping in state %s (force %s)", self.state, force) 1200 self._incref(force) 1201 try: 1202 if self.state.isDone(): 1203 self.log.debug("Task already stopped (%s), ignoring", self.state) 1204 return 1205 elif self.state.isRecovering() and not force and (self.cleanPolicy == TaskCleanType.auto): 1206 self.log.debug("Task (%s) in recovery and force is false, ignoring", self.state) 1207 return 1208 1209 self._aborting = True 1210 self._forceAbort = force 1211 finally: 1212 self._decref(force)
959 def _incref(self, force=False): 960 self.lock.acquire() 961 try: 962 if self.aborting() and (self._forceAbort or not force): 963 raise se.TaskAborted(unicode(self)) 964 965 self.ref += 1 966 ref = self.ref 967 return ref 968 finally: 969 self.lock.release()
On 07/13/2012 02:53 PM, Lee Yarwood wrote:
Hello all,
I'm looking into the use case around an aborted task within vdsmd. AFAICT both engine and vdsClient are unable to deal with an aborted task at present.
Within engine we call HSMStopTaskVDSCommand, this inturn calls stopTask supplying _only_ the task_guid. vdsClient also calls stopTask with only the task_guid argument.
Why does this matter? Well the only was you can kill an aborted task is by passing the force=True argument to the stop method of the task object itself. Without this the _incref method will throw a TaskAborted exception and we will be unable to stop the task.
Could anyone give me some background on why this is the case before I start looking into exposing the force option up the stack to engine and vdsClient.
Relevant code snippets from task.py below.
Thanks in advance,
Lee
vdsm/storage/task.py
1198 def stop(self, force=False): 1199 self.log.debug("stopping in state %s (force %s)", self.state, force) 1200 self._incref(force) 1201 try: 1202 if self.state.isDone(): 1203 self.log.debug("Task already stopped (%s), ignoring", self.state) 1204 return 1205 elif self.state.isRecovering() and not force and (self.cleanPolicy == TaskCleanType.auto): 1206 self.log.debug("Task (%s) in recovery and force is false, ignoring", self.state) 1207 return 1208 1209 self._aborting = True 1210 self._forceAbort = force 1211 finally: 1212 self._decref(force)
959 def _incref(self, force=False): 960 self.lock.acquire() 961 try: 962 if self.aborting() and (self._forceAbort or not force): 963 raise se.TaskAborted(unicode(self)) 964 965 self.ref += 1 966 ref = self.ref 967 return ref 968 finally: 969 self.lock.release()
Bump, any thoughts? Apologies if this is a little ovirt-engine centric for the list.
Lee
We purposefully removed the ability to stop and aborted task from outside VDSM. It is one of the many features VDSM had (and still has) that could corrupt you data center if abused.
On a related note, this is the time that the 1st rule of VDSM didn't apply! This is one hell of a milestone!
----- Original Message -----
From: "Lee Yarwood" lyarwood@redhat.com To: vdsm-devel@lists.fedorahosted.org Sent: Tuesday, July 17, 2012 11:45:46 AM Subject: Re: [vdsm] How should we handle aborted tasks? via engine, vdsClient or both?
On 07/13/2012 02:53 PM, Lee Yarwood wrote:
Hello all,
I'm looking into the use case around an aborted task within vdsmd. AFAICT both engine and vdsClient are unable to deal with an aborted task at present.
Within engine we call HSMStopTaskVDSCommand, this inturn calls stopTask supplying _only_ the task_guid. vdsClient also calls stopTask with only the task_guid argument.
Why does this matter? Well the only was you can kill an aborted task is by passing the force=True argument to the stop method of the task object itself. Without this the _incref method will throw a TaskAborted exception and we will be unable to stop the task.
Could anyone give me some background on why this is the case before I start looking into exposing the force option up the stack to engine and vdsClient.
Relevant code snippets from task.py below.
Thanks in advance,
Lee
vdsm/storage/task.py
1198 def stop(self, force=False): 1199 self.log.debug("stopping in state %s (force %s)", self.state, force) 1200 self._incref(force) 1201 try: 1202 if self.state.isDone(): 1203 self.log.debug("Task already stopped (%s), ignoring", self.state) 1204 return 1205 elif self.state.isRecovering() and not force and (self.cleanPolicy == TaskCleanType.auto): 1206 self.log.debug("Task (%s) in recovery and force is false, ignoring", self.state) 1207 return 1208 1209 self._aborting = True 1210 self._forceAbort = force 1211 finally: 1212 self._decref(force)
959 def _incref(self, force=False): 960 self.lock.acquire() 961 try: 962 if self.aborting() and (self._forceAbort or not force): 963 raise se.TaskAborted(unicode(self)) 964 965 self.ref += 1 966 ref = self.ref 967 return ref 968 finally: 969 self.lock.release()
Bump, any thoughts? Apologies if this is a little ovirt-engine centric for the list.
Lee
--
Lee Yarwood Software Maintenance Engineer Red Hat UK Ltd 200 Fowler Avenue IQ Farnborough, Farnborough, Hants GU14 7JP
Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson(USA), Charlie Peters (USA)
GPG fingerprint : A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
On 07/18/2012 03:13 PM, Saggi Mizrahi wrote:
We purposefully removed the ability to stop and aborted task from outside VDSM. It is one of the many features VDSM had (and still has) that could corrupt you data center if abused.
Understood, however we also lack the ability to manually recover a task so is it just a case of waiting for VDSM to forcibly remove the aborted tasks itself?
On a related note, this is the time that the 1st rule of VDSM didn't apply! This is one hell of a milestone!
I would ask what the 1st rule of VDSM is but I fear I might wake up in a basement.
Lee
----- Original Message -----
From: "Lee Yarwood" lyarwood@redhat.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, July 18, 2012 10:53:45 AM Subject: Re: [vdsm] How should we handle aborted tasks? via engine, vdsClient or both?
On 07/18/2012 03:13 PM, Saggi Mizrahi wrote:
We purposefully removed the ability to stop and aborted task from outside VDSM. It is one of the many features VDSM had (and still has) that could corrupt you data center if abused.
Understood, however we also lack the ability to manually recover a task so is it just a case of waiting for VDSM to forcibly remove the aborted tasks itself?
Yes, Task recovery isn't really that robust. We are working on a different approach for tasks that is more cluster aware.
On a related note, this is the time that the 1st rule of VDSM didn't apply! This is one hell of a milestone!
I would ask what the 1st rule of VDSM is but I fear I might wake up in a basement.
Lee
Lee Yarwood Software Maintenance Engineer Red Hat UK Ltd 200 Fowler Avenue IQ Farnborough, Farnborough, Hants GU14 7JP
Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson(USA), Charlie Peters (USA)
GPG fingerprint : A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
vdsm-devel@lists.fedorahosted.org