oved, I would like to see security infra such as these be infra.

the application side feature is virt, but the infra is... infra.

Hi, VDSM will hard-depend on ovirt-vmconsole (https://gerrit.ovirt.org/#/c/42479/). Where ovirt-vmconsole package will be available (e.g. uploaded on ovirt repo, on standard fedora repo...)

(In reply to Francesco Romani from comment #2)
> Hi, VDSM will hard-depend on ovirt-vmconsole
> (https://gerrit.ovirt.org/#/c/42479/). Where ovirt-vmconsole package will be
> available (e.g. uploaded on ovirt repo, on standard fedora repo...)

this is downstream bug, for errata, nothing more.

vdsm should *NOT* depend on this package the pacakge will be deployed by host-deploy when feature is enabled at engine side, if also needed host-deploy can also configure vdsm to enable feature using configuration, but better to detect existence.

for ovirt repo deployment, please track [1]

[1] https://projects.engineering.redhat.com/browse/RHEVINTEG-1045

the feature support shall not be configurable. We'll assume all 3.6-level hosts support it. Manual redeploy is needed for regular hosts; node should have it present
The actual per-VM use of the feature is a VM property.

Francesco, please make sure redeploy gets into known issues.

(In reply to Michal Skrivanek from comment #4)
> the feature support shall not be configurable. We'll assume all 3.6-level
> hosts support it. Manual redeploy is needed for regular hosts; node should
> have it present
> The actual per-VM use of the feature is a VM property.

This continues the monolithic approach of ovirt, I thought we start to withdraw these old habits.

This feature was designed to be modular, in every sense, there is no reason why it should be enforced in environments that do not use it.

it is still modular. But to guarantee a certain level of features we do provide a certain set of features. Exposing all the different sub-functionalities as separate items, configurable, with reporting, etc is counter-productive

Hence the capability is mandatory in 3.6, the actual feature is not.
advantage of modular approach is still there, and we can take it out anytime, move it around, etc. with the corresponding changes.
But I'm against exposing it as yet another configurable at the host level without a wider discussion whether we want to go this direction at all or not (that is, managing features per host)

Continue this approach will only lead us to bloating even more the hosts.

We should stop assuming 100% of features available and start go modular.

I alerted Itamar, if he cares he will note something.

I think the move should be exactly the opposite, we should start remove optional features from this product into actual optional components.

testable now

This specific bug will be moved to ON_QA when build in errata is assigned. All other bugs of this feature should be verified.

# rpm -q ovirt-vmconsole rhevm
ovirt-vmconsole-1.0.0-1.el6ev.noarch
rhevm-3.6.0.3-0.1.el6.noarch

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0389.html