[Engine-devel] Reloadable Configuration - Wiki Page

Doron Fediuck dfediuck at redhat.com
Thu Mar 29 12:42:05 UTC 2012


On 29/03/12 12:13, Itamar Heim wrote:
> On 03/29/2012 11:59 AM, Doron Fediuck wrote:
>> On 29/03/12 10:54, Itamar Heim wrote:
>>> On 03/29/2012 10:05 AM, Muli Salem wrote:
>>>> Thanks for the comments, I updated the wiki page accordingly:
>>>> http://www.ovirt.org/wiki/Features/ReloadableConfiguration
>>>>
>>>> 1. Instead of the new DB column is_reloadable -->   Annotation to ConfigValues.
>>>> 2. Found a way to update the Quartz jobs, at least basic issues such as interval size.
>>>> 3. The values will be reloaded upon admin's decision to do so - with a new command in the engine-config CLI, since that is where admins make the changes.
>>>
>>> just wondering - how will the CLI do this at the technical level (via REST API? signal to service, etc.)?
>>
>> Basically we need a script using the REST sdk to trigger re-configuration
>> This script will need the engine's IP so it'll know where to find it.
>> The thing is, REST also needs the admin's user and password to run...
>>
>> We can get it in 2 options:
>>
>> 1. Store Admin's user+pass in the engine's conf file.
>> 2. Use engine-config to fetch the credentials.
>>
>> Once we have credentials, we can use it with a new script to trigger configuration reload.
>> We can also incorporate this script into engine-config so admin won't need to know another
>> script, and simply use a 'reload' verb.
>>
>> I'm not keen on storing the credentials in a conf' file, but (unfortunately) it wouldn't
>> be a first time. Any better alternative is welcome (just as patches ;-).
> 
> true.
> 
>>
>> A simple alternative to the whole credentials and IP need,
>> is a simple periodic reload, as suggested initially.
> 
> 
Any thoughts on this?

> 
>>
>> /d
> 
> isn't there some way to send a process signal or something like that (not allowing remote access, but i think it uses the db crednetials from a local file anyway, and i don't think running config remotely is a must)
> 
Simply signaling a process such as "kill TRAP PID" is problematic since:
- The engine core is a web-app on top of JBoss, how do we know which pid to trigger?
- What happens if JBoss isn't running / using nohup / ... ?

> other options:
> 1. require user to provide user/password (kind of funny for running manage-domains utility, but possible
This will make service xxx reload pointless, unless we decide to drop it and reduce to a simple
script (embedded or not in the config utility).

> 2. use a way on the host to send a signal (change a file, process signal, etc.)
Great. This means we need to poll a folder or similar (DB)... sounds familiar?
See above the periodic reload. We can do it better if we look for a key in the DB
(enableReconfigure=true), to avoid reloading in the middle of an update process
of several keys. We still need to be careful from concurrency, but I have solutions
for this as well (do not allow updates to vdc_options until the key becomes false again,
also set it to false on initial boot).

> 
3. Write a simple public reload servlet (maybe limit to local host only?), which
we can call using simple curl http://xxx/reload?
 
As I see it now,
I'd go for one of the following (in this order)-
2: periodically poll DB, reload only when allowed.
3: local servlet.

Thoughts?
Better solutions?



More information about the Engine-devel mailing list