Bug 1264391

we plan to use UserVmManager role with a new action group to be able to access/allow the user with a configured ssh key to access the VM

 Omer Frenkel 2015-09-20 13:55:54 EDT
Target Release: 3.6.0 → 3.6.1
Target Milestone: ovirt-3.6.0-rc → ovirt-3.6.1

there is enough time until 3.6.0, it should be trivial change, no reason to defer and modify product behaviour, documentation and existing settings, require migration.

(In reply to Alon Bar-Lev from comment #2)
>  Omer Frenkel 2015-09-20 13:55:54 EDT
> Target Release: 3.6.0 → 3.6.1
> Target Milestone: ovirt-3.6.0-rc → ovirt-3.6.1
> 
> there is enough time until 3.6.0, it should be trivial change, no reason to
> defer and modify product behaviour, documentation and existing settings,
> require migration.


We will not rush this change in between RC and GA. The patch is far from trivial. Retargeting to 3.6.1

(In reply to Michal Skrivanek from comment #3)
> (In reply to Alon Bar-Lev from comment #2)
> >  Omer Frenkel 2015-09-20 13:55:54 EDT
> > Target Release: 3.6.0 → 3.6.1
> > Target Milestone: ovirt-3.6.0-rc → ovirt-3.6.1
> > 
> > there is enough time until 3.6.0, it should be trivial change, no reason to
> > defer and modify product behaviour, documentation and existing settings,
> > require migration.
> 
> 
> We will not rush this change in between RC and GA. The patch is far from
> trivial. Retargeting to 3.6.1

I do not think you understand what z-stream is - it is not a play ground, although there are people who things that ovirt release is yet another beta given the users in "GA" name.

When this patch will be applied users that used vmconsole will have to modify settings to make it work, this is not something you do in z-stream.

We invested great effort to make it happen for the user sake.

Please remember that this feature has NEVER tested by QA before this so called "RC", in this case it should have been deferred to 4.0, but if not, it should begin QA cycle only from RC including all fixes required, especially these that are user visible.

The only QA that was done was by me and I am not QA.

Please retarget to 3.6.0 as it should.

We would need a feedback from QE, they did finish testing some parts...but I don't know the exact status.
It may have been invalidated too by the recent changes. We need to stop rewriting stuff to give QE a chance to actually test something

If a change is not ready it should not be backported to RC and I'd rather push it out to the next release.
If it gets in before that then good, but it's not a change/feature which should block 3.6
 
Note there there are several big things planned to be introduced in zstream, e.g. EL 7.2, ppc64le support, spm removal.

Fixed bug tickets must have version flags set prior to fixing them. Please set the correct version flags and move the bugs back to the previous status after this is corrected.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Please provide reproduction steps for this bug, so QA could verify.

1. Create a User with SUPER_USER / VM_OPERATOR or INSTANCE_OPERATOR permissions on DC or Cluster

2. Create a VM in the Cluster

3. Start the VM

4. List the user accessible running VMs using command
   
   ovirt-vmconsole-list.py consoles --entityid @USER_INTERNAL_ID@
   
   Where USER_INTERNAL_ID is the id of the user from database table users (can be admin user)

Works for me on these components:
rhevm-3.6.1.1-0.1.el6.noarch
ovirt-host-deploy-java-1.4.1-1.el6ev.noarch
ovirt-vmconsole-1.0.0-1.el6ev.noarch
ovirt-host-deploy-1.4.1-1.el6ev.noarch
ovirt-vmconsole-proxy-1.0.0-1.el6ev.noarch
ovirt-engine-extension-aaa-jdbc-1.0.4-1.el6ev.noarch

# ovirt-aaa-jdbc-tool user add black \
> --attribute=firstName=Black \
> --attribute=lastName=Blackovich \
> --attribute=email=black
adding user black...
user added successfully

# ovirt-aaa-jdbc-tool user show black
-- User black(2fbb2bae-e9b1-450e-ac45-c53e74b388f8) --
Namespace: *
Name: black
ID: 2fbb2bae-e9b1-450e-ac45-c53e74b388f8
Display Name: 
Email: black
First Name: Black
Last Name: Blackovich
Department: 
Title: 
Description: 
Account Disabled: false
Account Unlocked At: 1970-01-01 00:00:00Z
Account Valid From: 2015-12-07 15:40:50Z
Account Valid To: 2215-12-07 15:40:50Z
Account Without Password: false
Last successful Login At: 1970-01-01 00:00:00Z
Last unsuccessful Login At: 1970-01-01 00:00:00Z
Password Valid To: 1970-01-01 00:00:00Z

# ovirt-aaa-jdbc-tool user password-reset black
Password:
updating user black...
user updated successfully



# cat /etc/ovirt-engine/engine.conf.d/10-setup-database.conf
ENGINE_DB_HOST="localhost"
ENGINE_DB_PORT="5432"
ENGINE_DB_USER="engine"
ENGINE_DB_PASSWORD="8HVeFa9uGGn4CGg7LlOJqe"
ENGINE_DB_DATABASE="engine"
ENGINE_DB_SECURED="False"
ENGINE_DB_SECURED_VALIDATION="False"
ENGINE_DB_DRIVER="org.postgresql.Driver"
ENGINE_DB_URL="jdbc:postgresql://localhost:5432/engine?sslfactory=org.postgresql.ssl.NonValidatingFactory"

# su - postgres 
-bash-4.1$  psql -d engine
psql (8.4.20)
engine-# select * from users;
ERROR:  syntax error at or near "select"
LINE 2: select * from users;
        ^
engine=# select * from users;
               user_id                | name  |  surname   |     domain     | username | department |       email        | note | last_admin_check
_status |             external_id              |         _create_date          |         _update_date          | namespace 
--------------------------------------+-------+------------+----------------+----------+------------+--------------------+------+-----------------
--------+--------------------------------------+-------------------------------+-------------------------------+-----------
 00000018-0018-0018-0018-000000000279 | admin |            | internal-authz | admin    |            |                    |      | t               
        | 8cd95752-63a8-4738-a87d-89fc2617c5af | 2015-11-29 18:33:20.609721+02 | 2015-12-07 16:45:53.442793+02 | *
 973131f6-ba7e-4a37-974f-bf7139ee626a | Black | Blackovich | internal-authz | black    |            | black |      | t               
        | 2fbb2bae-e9b1-450e-ac45-c53e74b388f8 | 2015-12-07 17:42:17.968475+02 | 2015-12-07 17:44:37.365973+02 | *
(2 rows)

engine=# \q
-bash-4.1$ exit


# /usr/libexec/ovirt-vmconsole-proxy-helper/ovirt-vmconsole-list.py consoles --entityid 00000018-0018-0018-0018-000000000279
{"content": "console_list", "consoles": [{"vmname": "vm1", "vmid": "2feb7c67-0875-4407-a64e-bd3d7a2120bd", "host": "alma04.qa.lab.tlv.redhat.com", "console": "2feb7c67-0875-4407-a64e-bd3d7a2120bd.sock", "vm": "vm1"}], "version": 1}
[root@nsednev-he-1 ~]# /usr/libexec/ovirt-vmconsole-proxy-helper/ovirt-vmconsole-list.py consoles --entityid 973131f6-ba7e-4a37-974f-bf7139ee626a
{"content": "console_list", "consoles": [{"vmname": "vm1", "vmid": "2feb7c67-0875-4407-a64e-bd3d7a2120bd", "host": "alma04.qa.lab.tlv.redhat.com", "console": "2feb7c67-0875-4407-a64e-bd3d7a2120bd.sock", "vm": "vm1"}], "version": 1}

According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.