7:42 a.m.
On 29/03/12 12:13, Itamar Heim wrote:
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?
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).