Description of problem:
I'm using 'engine-config -s WebSocketProxy=...' to change a VdcOption for the WebSocketProxy location.
Straight off 'engine-config -g WebSocketProxy' reports the new value.
I'll expect that the web interface suddenly points to the new host trying to open a spice console via websocket proxy but it still uses the old values.
I have to reload the whole engine to use the new value.
Version-Release number of selected component (if applicable):
oVirt 3.5 beta2
Steps to Reproduce:
1. on the engine host, use the command 'engine-config -s WebSocketProxy=<mynewhost>' to have the engine pointing to another host when the user open a VM console via websocket proxy
2. check the result via 'engine-config -g WebSocketProxy'
3. check where the engine points when the user try to open a vm web console via the websocket proxy (it's the value of host parameter on similar link: https://f19t5.localdomain/ovirt-engine/services/spicehtml5-main.html?host=f19t6.localdomain&port=6100)
engine web admin console still try to connect the websocket proxy at the previous address till I restart the whole engine.
the property becomes soon effective and the engine uses the new value.
Note that this isn't specific to this key - see .
Didn't find an existing bug for this feature - if you find one, you can close as duplicate.
Keys can either be set as reloadable, or not.
Once they are set, one needs to issue an API call to /api/reloadConfigurations in order for the reload to occur.
So, the bug shouldn't be on all configuration entries, but only to ones that aren't reloadable.
So, in case of web socket proxy, virt team should determine whether it should be reloadable or not, and whether something needs to be done with it.
Moving back to virt.
currently it's not reloadable, I don't see any reason why it can't be...
WebSocketProxy vdc_option has been set to Reloadable.
To take effect without restarting the engine:
- set: engine-config -s WebSocketProxy=NEW_VALUE
- refresh cache via REST API POST call, i.e.:
curl --silent --insecure --request POST --header "Accept: application/xml" --header "Content-Type: application/xml" --user "admin@internal:PWD" "http://localhost:8080/ovirt-engine/api/reloadconfigurations" --data '<action/>'
- refresh GUI: Ctrl+R
Since the 'reload' action is not recently implemented in the engine-config,
these steps for reloading the configuration are added to the engine-config's man page and the usage() help message to improve user experience.
From the discussion with the infra team: the Reloadable options are recently not supported, maybe in a future release.
Handing the bug over to infra.
We're not gonna make it reloadable.
Closing it as WONTFIX.
current REST API support for config reload is enough, and it works. moving back to virt to get in a simple fix as per comment #2
this is not really an RFE, it should have been like that since beginning and it does not require any real code change
(In reply to Michal Skrivanek from comment #7)
> current REST API support for config reload is enough, and it works. moving
> back to virt to get in a simple fix as per comment #2
> this is not really an RFE, it should have been like that since beginning and
> it does not require any real code change
As specified, we're deprecating it.
You want to rely on it - your call. It won't be there in 4.0 for reasons I've described in the RFE related to reloaded configuration.
I want to fix a wrongly designated parameter
Note that from API point of view you need one release to deprecate, then remove in the next one.
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Closing older BZs, if still happened, please reopen.