On Tuesday, July 08, 2014 10:27:12 AM Larry O'Leary wrote:
On Thu, 2014-07-03 at 10:54 +0200, Libor Zoubek wrote:
> Hello,
>
> Let me remind, how our configuration updates roughly work. From UI or
> remote api comes request to update configuration for particular resource.
> We write this into DB as last known configuration with status IN_PROGRESS
> and send it to agent. Agent (as implemented in most plugins) updates all
> configuration properties, it does not care about requested
> changes - we do not provide such information to plugin (user does not
> likely change all property values). Then, if
> success is returned, server marks given configuration as gold and
> successful.
>
> Recently I was working on a bug, where AS7 reacts inappropriate when we
> update particular attributes. While user changes only 1 config property
> and does not expect any side effects and does not even know we're updating
> all values. I've solved it with
>
https://github.com/rhq-project/rhq/commit/3d0571af3f465c6d47567483ebc0148a
> 514e6851 which is a simplest AS7 only implementation of bellow ..
>
> What would be the "correct" workflow for updating configuration?
>
> Do we care about out of band config changes?
>
> I am thinking of this:
> 1. new (full) config comes from UI/CLI
> 2. server sends full configuration to agent
> 3. agent reads live configuration
> 4. agent creates a configuration diff
> 5. agent sends this diff to plugin to apply changes only
Why can't the server send configuration that represents the changes
only? In other words, instead of sending the whole configuration object,
a new one is built that contains the user's updates. The UI will do this
for the user and in the event a remote API is used, it is up to the
caller to send a configuration object that represents changes only.
In those cases that the plug-in might want the entire configuration
object -- can't really think of a reason why it would -- then perhaps a
configuration definition attribute could be used to identify this.
Otherwise, perhaps the plug-in should be responsible for loading the
live configuration and copying the updated configuration it received
from the server atop of it.
From a user's perspective, when you update a single configuration
element, you would not expect all of the other elements to be modified
or used for the actual configuration update. If the value was unchanged
or not specified, it won't be included in the update unless the plug-in
requires it. In the cases the plug-in requires it, the plug-in is
responsible for getting the value from the resource it is managing.
The reason why we are sending down the whole configuration and not just the
changes is the assumption that the user actually wants the configuration to
look exactly like the one they saved.
This prevents a "race condition" that could have happened with updates-only
and out-of-RHQ change to the configuration of the resource (it, I assume,
could also happen in a rare case of 2 RHQ users simultaneously updating config
on a single resource).
Given config:
A=a
B=b
C=c
The user updates:
B=bb
Out-of-band update of config (happening AFTER the load of the config but
before hitting the save button):
C=cc
With our current approach the resulting config would be:
A=a
B=bb
C=c
With the updates-only approach the resulting config would be:
A=a
B=bb
C=cc
Also notice that our current approach saves 1 load of the config - we just
assume that what left the server will be applied. If we only sent updates, we
would have to follow the update call with another load call to see what has
actually happened.
The VCS user in me says that the updates-only approach is probably the "more
correct" one, with the caveat that we should then enable full conflict
resolution to the concurrent updates - i.e. it should be an error if the user
tries to update a property that has been changed since he last loaded the
config.
But this gets a bit involved when you realize you cannot ensure the atomicity
of the updates (because no matter how fast you process and update the changes
in the plugin code, some outside change can still happen, corrupting the
results).
Lukas