Bug 1057232

Setting target release to current version for consideration and review. please
do not push non-RFE bugs to an undefined target release to make sure bugs are
reviewed for relevancy, fix, closure, etc.

Changing cluster CPU family when all hosts are in Maintenance is IMO problematic. The only case where it's useful is the one in reproducing steps (select wrong CPU family when creating cluster and find this out when 1st host is installed). In all other cases (you have running cluster, put all hosts to Maintenance and try to change CPU family) I don't see how this can be needed in production.

And all these changing CPU family cases can be solved using this: create new cluster, move hosts to new cluster, delete old cluster.

So I close this as WONTFIX, but if some more reasons are found to implement this, please feel free to reopen.

I am not sure why this limitation has been added or why changing a cpu family is suddenly problematic. 
if a host is inconsistent with the cpu selected it will become non-operational - this has always been the flow and it's still the flow now.  
I don't see a reason why a user has to create a new cluster in case they made a mistake in the cpu family. not very user friendly in my eyes and I assure you it can happen.

(In reply to Dafna Ron from comment #3)
> I am not sure why this limitation has been added or why changing a cpu
> family is suddenly problematic. 

It's not problematic to implement this. But except case provided in reproducing steps, I don't see any other production cases where this would be beneficial.

> if a host is inconsistent with the cpu selected it will become
> non-operational - this has always been the flow and it's still the flow now.

That's true

> 
> I don't see a reason why a user has to create a new cluster in case they
> made a mistake in the cpu family. not very user friendly in my eyes and I
> assure you it can happen.

IMO case provided in reproducing steps is corner case. In all other cases IMO allowing to change CPU family can cause more harm then good ...

(In reply to Martin Perina from comment #4)
> (In reply to Dafna Ron from comment #3)
> > I am not sure why this limitation has been added or why changing a cpu
> > family is suddenly problematic. 
> 
> It's not problematic to implement this. But except case provided in
> reproducing steps, I don't see any other production cases where this would
> be beneficial.
> 
> > if a host is inconsistent with the cpu selected it will become
> > non-operational - this has always been the flow and it's still the flow now.
> 
> That's true
> 
> > 
> > I don't see a reason why a user has to create a new cluster in case they
> > made a mistake in the cpu family. not very user friendly in my eyes and I
> > assure you it can happen.

not true... making a mistake in selecting the family is not a corner case. 
> 
> IMO case provided in reproducing steps is corner case. In all other cases
> IMO allowing to change CPU family can cause more harm then good ...

Please elaborate? do we have any bugs for other more destructive cases?

(In reply to Dafna Ron from comment #5)
> (In reply to Martin Perina from comment #4)
> > (In reply to Dafna Ron from comment #3)
> > > I am not sure why this limitation has been added or why changing a cpu
> > > family is suddenly problematic. 
> > 
> > It's not problematic to implement this. But except case provided in
> > reproducing steps, I don't see any other production cases where this would
> > be beneficial.
> > 
> > > if a host is inconsistent with the cpu selected it will become
> > > non-operational - this has always been the flow and it's still the flow now.
> > 
> > That's true
> > 
> > > 
> > > I don't see a reason why a user has to create a new cluster in case they
> > > made a mistake in the cpu family. not very user friendly in my eyes and I
> > > assure you it can happen.
> 
> not true... making a mistake in selecting the family is not a corner case. 

For me it's corner case if you count numbers of correct and incorrect CPU family settings once defining cluster. Please ask yourself, how many times did you make such a mistake when creating cluster?

> > 
> > IMO case provided in reproducing steps is corner case. In all other cases
> > IMO allowing to change CPU family can cause more harm then good ...
> 
> Please elaborate? do we have any bugs for other more destructive cases?

If I omit case described in reproducing steps, I can see these cases:

1) Cluster is empty (no hosts) -> you can change any values you want (that's true even for current code)

2) Cluster has some hosts. Now I would make an assumption that some hosts are Up so this won't be the same case as in reproducing steps. Agreed? So I will move all my hosts to Maintenance, change CPU family and Activate them again. Result: all hosts became Non responsive due to incompatible CPU family. So why would I want to allow this change?

(In reply to Martin Perina from comment #6)
> (In reply to Dafna Ron from comment #5)
> > (In reply to Martin Perina from comment #4)
> > > (In reply to Dafna Ron from comment #3)
> > > > I am not sure why this limitation has been added or why changing a cpu
> > > > family is suddenly problematic. 
> > > 
> > > It's not problematic to implement this. But except case provided in
> > > reproducing steps, I don't see any other production cases where this would
> > > be beneficial.
> > > 
> > > > if a host is inconsistent with the cpu selected it will become
> > > > non-operational - this has always been the flow and it's still the flow now.
> > > 
> > > That's true
> > > 
> > > > 
> > > > I don't see a reason why a user has to create a new cluster in case they
> > > > made a mistake in the cpu family. not very user friendly in my eyes and I
> > > > assure you it can happen.
> > 
> > not true... making a mistake in selecting the family is not a corner case. 
> 
> For me it's corner case if you count numbers of correct and incorrect CPU
> family settings once defining cluster. Please ask yourself, how many times
> did you make such a mistake when creating cluster?

lots of times actually :) user error happens a lot which is why we have a very nice error in the webadmin for host moved to not operational state because of wrong cpu type after installation. 
> 
> > > 
> > > IMO case provided in reproducing steps is corner case. In all other cases
> > > IMO allowing to change CPU family can cause more harm then good ...
> > 
> > Please elaborate? do we have any bugs for other more destructive cases?
> 
> If I omit case described in reproducing steps, I can see these cases:
> 
> 1) Cluster is empty (no hosts) -> you can change any values you want (that's
> true even for current code)

not sure what you mean in this... this is not a destructive case. I know we can change the cluster family if there are no hosts in the cluster - not really related to this case. 
> 
> 2) Cluster has some hosts. Now I would make an assumption that some hosts
> are Up so this won't be the same case as in reproducing steps. Agreed? So I
> will move all my hosts to Maintenance, change CPU family and Activate them
> again. Result: all hosts became Non responsive due to incompatible CPU
> family. So why would I want to allow this change?

1. wrong cpu moves hosts to 'non-operational' and not to 'not-responsive' and it has a very clear error in the webadmin. 
2. again, not really sure what is destructive about this case? if the user changed the cpu type while the hosts were in maintenance and gets an error on wrong cput type once he starts the hosts it's easily fixed and we have a very clear error message in the UI. however, not allowing a user to change a family without creating a new cluster is not user friendly at all...

michal - please review

(In reply to Dafna Ron from comment #7)
> (In reply to Martin Perina from comment #6)
> > (In reply to Dafna Ron from comment #5)
> > > (In reply to Martin Perina from comment #4)
> > > > (In reply to Dafna Ron from comment #3)
> > > > > I am not sure why this limitation has been added or why changing a cpu
> > > > > family is suddenly problematic. 
> > > > 
> > > > It's not problematic to implement this. But except case provided in
> > > > reproducing steps, I don't see any other production cases where this would
> > > > be beneficial.
> > > > 
> > > > > if a host is inconsistent with the cpu selected it will become
> > > > > non-operational - this has always been the flow and it's still the flow now.
> > > > 
> > > > That's true
> > > > 
> > > > > 
> > > > > I don't see a reason why a user has to create a new cluster in case they
> > > > > made a mistake in the cpu family. not very user friendly in my eyes and I
> > > > > assure you it can happen.
> > > 
> > > not true... making a mistake in selecting the family is not a corner case. 
> > 
> > For me it's corner case if you count numbers of correct and incorrect CPU
> > family settings once defining cluster. Please ask yourself, how many times
> > did you make such a mistake when creating cluster?
> 
> lots of times actually :) user error happens a lot which is why we have a
> very nice error in the webadmin for host moved to not operational state
> because of wrong cpu type after installation. 

OK, I tested on myself and it never occurred to me ...

> > 
> > > > 
> > > > IMO case provided in reproducing steps is corner case. In all other cases
> > > > IMO allowing to change CPU family can cause more harm then good ...
> > > 
> > > Please elaborate? do we have any bugs for other more destructive cases?
> > 
> > If I omit case described in reproducing steps, I can see these cases:
> > 
> > 1) Cluster is empty (no hosts) -> you can change any values you want (that's
> > true even for current code)
> 
> not sure what you mean in this... this is not a destructive case. I know we
> can change the cluster family if there are no hosts in the cluster - not
> really related to this case. 

I just stated cases that can happen, 'destructive' term is irrelevant here ...

> > 
> > 2) Cluster has some hosts. Now I would make an assumption that some hosts
> > are Up so this won't be the same case as in reproducing steps. Agreed? So I
> > will move all my hosts to Maintenance, change CPU family and Activate them
> > again. Result: all hosts became Non responsive due to incompatible CPU
> > family. So why would I want to allow this change?
> 
> 1. wrong cpu moves hosts to 'non-operational' and not to 'not-responsive'
> and it has a very clear error in the webadmin. 

Correct, but it's not important here. User has to move them Maintenance and change CPU back in order to reactivate them again

> 2. again, not really sure what is destructive about this case? if the user
> changed the cpu type while the hosts were in maintenance and gets an error
> on wrong cput type once he starts the hosts it's easily fixed and we have a
> very clear error message in the UI. however, not allowing a user to change a
> family without creating a new cluster is not user friendly at all...

I didn't said anything about destructive. All I wanted to express: is this kind of error happening so many times that it will be beneficial to allow this change considering that there's an easy workaround?

Martin, I still cannot understand why we need this CanDoAction. 
if the user selects the wrong cpu family and tries to activate the host - they cannot with a very clear error message. 
if the user tries to change cpu family while the hosts are active - they cannot with a very clear error message. 
this limitation, which was recently added, creates a complication for the user so why not remove it?

(In reply to Dafna Ron from comment #10)
> Martin, I still cannot understand why we need this CanDoAction. 
> if the user selects the wrong cpu family and tries to activate the host -
> they cannot with a very clear error message. 
> if the user tries to change cpu family while the hosts are active - they
> cannot with a very clear error message. 
> this limitation, which was recently added, creates a complication for the
> user so why not remove it?

I looked at code history and this limitation (cannot change CPU family while there are hosts in cluster) exists from the beginning.

As I said before, I can do the change (allow change CPU family while all hosts in cluster are in Maintenance), I'm just not sure if we should allow it.

Please wait for Michal's opinion on this case

if the patch is small/simple i don't see a problem allowing it. Once we opened the gates of hell for hosted engine we can as well allow this:)

Too much automation, merged only to master

Included in oVirt 3.4 RC2

verified in av3

this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released