Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1284409

Summary:	Support for reloadable config options
Product:	[oVirt] ovirt-engine	Reporter:	Marek Libra <mlibra>
Component:	RFEs	Assignee:	Scott Herold <sherold>
Status:	CLOSED WONTFIX	QA Contact:	Gil Klein <gklein>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	future	CC:	bugs, didi, michal.skrivanek, oourfali
Target Milestone:	---	Flags:	rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-11-24 06:47:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1124851

Description Marek Libra 2015-11-23 09:41:22 UTC

Description of problem: 

Add support for reloadable configuration so restart of the engine is not needed to take effect of a change.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Oved Ourfali 2015-11-24 06:47:04 UTC

This was discussed in the past and we decided not to add that support.

Comment 2 Michal Skrivanek 2015-11-25 08:38:26 UTC

I believe the right resolution is NOTABUG, we do have that support in REST API, that would be enough for the purpose of bug 1124851

Comment 3 Oved Ourfali 2015-11-25 08:41:06 UTC

(In reply to Michal Skrivanek from comment #2)
> I believe the right resolution is NOTABUG, we do have that support in REST
> API, that would be enough for the purpose of bug 1124851

The support in rest-api is deprecated and will be removed.
The configuration items aren't handled properly. Some are reloadable (although not marked as such), and some aren't (and they are marked as such).

Comment 4 Michal Skrivanek 2015-11-25 09:11:42 UTC

(In reply to Oved Ourfali from comment #3)
> (In reply to Michal Skrivanek from comment #2)
> > I believe the right resolution is NOTABUG, we do have that support in REST
> > API, that would be enough for the purpose of bug 1124851
> 
> The support in rest-api is deprecated and will be removed.
> The configuration items aren't handled properly. Some are reloadable
> (although not marked as such), and some aren't (and they are marked as such).

I'm fine with it being removed in future and replaced with a different/better solution. But I think the fields' designation should be corrected regardless the reload framework. I.e. whether the code using the parameters in fact deals with dynamic changes or not. (that's the point of the original bug 1124851, which I believe has it's merit regardless the fate of this bug)

When is the REST API part going away? Is it already deprecated or in which release it will be?

Comment 5 Oved Ourfali 2015-11-25 09:16:23 UTC

(In reply to Michal Skrivanek from comment #4)
> (In reply to Oved Ourfali from comment #3)
> > (In reply to Michal Skrivanek from comment #2)
> > > I believe the right resolution is NOTABUG, we do have that support in REST
> > > API, that would be enough for the purpose of bug 1124851
> > 
> > The support in rest-api is deprecated and will be removed.
> > The configuration items aren't handled properly. Some are reloadable
> > (although not marked as such), and some aren't (and they are marked as such).
> 
> I'm fine with it being removed in future and replaced with a
> different/better solution. But I think the fields' designation should be
> corrected regardless the reload framework. I.e. whether the code using the
> parameters in fact deals with dynamic changes or not. (that's the point of
> the original bug 1124851, which I believe has it's merit regardless the fate
> of this bug)

Fixing the fields is part of the different verticals.
However, we didn't revive it as we're heading a use of config file for the configuration.

> 
> When is the REST API part going away? Is it already deprecated or in which
> release it will be?

In 4.0 probably.