Bug 856512

The name is not "disable_strict_user_checking" but "allow_reconnect":

<parameter required="false" type="xs:boolean">
  <name>vm.display.allow_reconnect</name>
</parameter>

Also for templates:

<parameter required="false" type="xs:boolean">
  <name>template.display.allow_reconnect</name>
</parameter>

Don't you get these parameters in the RDSL document?

according to Oded:

odedr> this feature added to prevent a situation when 2 people are logged in to the same VM

this is does not sounds as allow_reconnect, is it same feature?

Yes, it is the same feature. The flag is named "allow_reconnect" because when it is true it allows any user to connect to the console of the VM regardless of who was connected before and without requiring a reboot of the VM. Then it was renamed in the user interface to "Disable strict ...".

I find this option finally from CLI : "display-allow_reconnect" . 
I found it quite confusing that this feature has 2 names: "disable-strict-user checking" in UI and "display-allow_reconnect" in API. 
Closing this bug for now , but I still recommend to change this field name in API before people will start to use it .

(In reply to comment #4)
> I find this option finally from CLI : "display-allow_reconnect" . 
> I found it quite confusing that this feature has 2 names:
> "disable-strict-user checking" in UI and "display-allow_reconnect" in API. 
> Closing this bug for now , but I still recommend to change this field name
> in API before people will start to use it .

+1 i think allow_reconnect not enough informative, - 'shared' (or similar)
would do the trick,

<vm>
 <display>
   <shared>true|false</shared>

Note that this is already in upstream 3.1, so changing the name could break backwards compatibility there. How do we solve that? Maybe there is no need to solve it as this flag is not that popular.

Also I don't think that "allow_reconnect" is less informative than "shared", but I prefer to abstain from this voting.

Einav, any suggestion or preference for naming?

I'm not sure that shared is accurate.  

When this feature is disabled ( strict-user checking disabled ) two people can try to login to a VM and the latter will override  the connection .

When this feature is enabled one must reboot the machine before other one can login to the VM .  


I would module it as follows , ( or advise with PM regarding shorter term ). 

<vm>
 <display>
   <strict_user_checking><true|false></strict_user_checking>

(In reply to comment #6)
> Note that this is already in upstream 3.1, so changing the name could break
> backwards compatibility there. How do we solve that? 

announcing the change on ML will do the job 

> Maybe there is no need to solve it as this flag is not that popular.

if we won't do it now, then we will be obligated to this name

> 
> Also I don't think that "allow_reconnect" is less informative than "shared",
> but I prefer to abstain from this voting.

in general "allow_reconnect" means that you can connect back after X,
i'm open for other names

> 
> Einav, any suggestion or preference for naming?

(In reply to comment #6)
> ...
> Einav, any suggestion or preference for naming?

I don't see any problem with "allow_reconnect"; maybe "allow_connection_override"?
setting needinfo on PM for final decision.

(In reply to comment #9)
> (In reply to comment #6)
> > ...
> > Einav, any suggestion or preference for naming?
> 
> I don't see any problem with "allow_reconnect"; maybe
> "allow_connection_override"?
> setting needinfo on PM for final decision.

According to this thread "allow_connection_override" is more accurate, since same user reconnect is allowed in any case, right?

Shared is not the right term in any case and it's a different feature still waiting to be implemented, so let's reserve this term.

(In reply to comment #10)
> According to this thread "allow_connection_override" is more accurate

we avoid adding more than two period based properties in api

(In reply to comment #11)
> (In reply to comment #10)
> > According to this thread "allow_connection_override" is more accurate
> 
> we avoid adding more than two period based properties in api
But isn't that going to translate to 


<parameter required="false" type="xs:boolean">
  <name>vm.display.allow_connection_override</name>
</parameter>

Am I missing something?

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > According to this thread "allow_connection_override" is more accurate
> > 
> > we avoid adding more than two period based properties in api
> But isn't that going to translate to 
> 
> 
> <parameter required="false" type="xs:boolean">
>   <name>vm.display.allow_connection_override</name>
> </parameter>

correct, but we do not have in api, any property longer than two periods,
e.g. x_y, what about .allow_override?

> 
> Am I missing something?

(In reply to comment #13)

> correct, but we do not have in api, any property longer than two periods,
> e.g. x_y, what about .allow_override?
> 

Ha, my bad, I call those underscores :).

My problem is that allow_override, is not that meaningful, override what? 
It's more like snatching, but snatching does not sound right. 

Andy, as a native speaker can you help with this?

The change proposed to rename allow_reconnect to allow_override is available here:

http://gerrit.ovirt.org/8325

The change has been merged upstream:

http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=0065da540311212b8a772cb9993ec01a37229d49

[RHEVM shell (connected)]# add vm display- 
display-allow_override  display-monitors        display-type  

Verified si20