Bug 996130

Was it the SPM ?

Must be, might be a race between setting the securable parameter and setting the SPM_ROLE . In any case, this exception is equivalent to NOT SPM exception and engine should treat both in the same way. 

This is not a bug.. unless engine treats it differently, what is the actual behavior here?

Eduardo, after checking again the code, if you recall - we decided to do :

try:                                                                    
 sp = self.pools.values()[0]                                         
except IndexError:                                                      
 raise se.SpmStatusError()                                           
allTasksStatus = sp.getAllTasksStatuses()

The secure error is definitely raised if the host is not set to be SPM. But, we should get to  sp.getAllTasksStatuses() only if we're not running as SPM, and the check we do is reading the first pool.  

The SecureError raises more than once, even a lot more.. is it possible that after host loose its SPM, it doesn't clean the pools dictionary as expected?

This question is in additional to the above question about the engine's behavior when receiving such exception

per comment #3 moving this bug to storage

(In reply to Yaniv Bronhaim from comment #3)
> Eduardo, after checking again the code, if you recall - we decided to do :
> 
> try:                                                                    
>  sp = self.pools.values()[0]                                         
> except IndexError:                                                      
>  raise se.SpmStatusError()                                           
> allTasksStatus = sp.getAllTasksStatuses()
> 
> The secure error is definitely raised if the host is not set to be SPM. But,
> we should get to  sp.getAllTasksStatuses() only if we're not running as SPM,
> and the check we do is reading the first pool.  
> 
> The SecureError raises more than once, even a lot more.. is it possible that
> after host loose its SPM, it doesn't clean the pools dictionary as expected?
> 
> This question is in additional to the above question about the engine's
> behavior when receiving such exception

Lost of the spm condition does not lead an should no lead to pool disconnection.
But the opposite is true: being connected to the pool is a sine equa non condition in order to to be spm. You are affirming the consequent.

In the snippet you provided, the exception is valid, for sure host is not SPM if  there is no pool object. 
But calling sp.getAllTasksStatuses() based in the SP object existence is not sufficient.
All the sp.getAllTasksStatuses() should be revised.

If having valid value in self.pools.values()[0] doesn't mean that the host runs as SPM we should fix the condition and use the validateSPM function as I suggested in the first place.

Please fix that issue, although SECURE_ERROR and NOT_SPM as the same error code, and currently we don't feel it in engine's side, we should not handle them in the same way. 
SECURE_ERROR means something wrong happened because VDSM itself thinks that it runs as SPM and called sp function that was not supposed to be called (bug).

SECURE_ERROR *is* NOT_SPM (it is translated before being sent to engine).
Getting this exception means that the host is simply not the spm.
There is no bug here.(In reply to Yaniv Bronhaim from comment #6)

> If having valid value in self.pools.values()[0] doesn't mean that the host

It doesn't.

> runs as SPM we should fix the condition and use the validateSPM function as
> I suggested in the first place.

No, your conclusion is incorrect.  The operation is an SPM op, any 'if' you perform would be a race.  Engine sends this command under the expectation that the host is the spm, if it is not, it should raise an error (as it does here).
Closing.

I honestly don't agree Ayal, my conclusion is perfectly right.
If your saying is right about "self.pools.values()[0] doesn't mean that the host runs as SPM", the following part of code

try:                                                                    
  sp = self.pools.values()[0]                                         
except IndexError:                                                      
  raise se.SpmStatusError()

Doesn't do anything. Only if the host never ran as SPM.

That sounds odd to me. Please explain why did we pick this solution instead of just forward the request directly to sp.py and get secureError?

I recall your saying that if an host doesn't run as SPM it doesn't hold a storagePool instance in its internal pools list.

If that's not true, please remove this part of code. Moving the getAllTasksList to sp.py was enough

Anyway, the try scope is redundant. please consider http://gerrit.ovirt.org/#/c/18843/

thanks

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days