update mechanism: tasks to be executed always

[Magnolia - Dev mailing list]

Hi,
one of the missing bits in the update mechanism is still the ability
of executing a list of tasks independently of the installed version.
Running update tasks based on a version number is fine, but having the
ability of automatically running a list of consistency check (and fix)
tasks is sometime better and more robust.

Taking as an example the cache module, it recently needed the
addiction of cache voters configuration in jcr. At this moment if the
cache voters configuration is missing it will ungracefully die with a
NPE.
Now: when to add cache voter configuration? Using the current API I
should do it in basic install tasks and, implementing
ModuleVersionHandler, also return this task based on version passed to
 getDeltas().

This pretty work but handling a previous version number could be not
so easy (from which version should I add this configuration?) and
doesn't handle the fact that if this configuration is removed from an
existing repository, nobody will ever set it back and the manager will
keep throwing its NPE.

This kind of operations could be probably handled better by a Task
that is always called and that bases its execution of the conditional
presence of an existing configuration. For this example I would like
to simply have a task that automatically adds the voters configuration
ONLY IF a voters configuration is missing. This will handle install,
update, and check/restore of any invalid configuration.
Differently from what happens with standard update tasks this kind of
tasks should not require manual intervention (they will be run at each
restart) and should be silently executed after update and before
starting the module.

Coming to the point:
I would like to add support in ModuleVersionHandler for tasks that
will always be executed AFTER install/update, BEFORE start and WITHOUT
user intervention. This would mean adding a method like:
List getUnconditionalTasks(InstallContext installContext);
to ModuleVersionHandler and make it called it in ModuleManagerImpl

WDYT? Is there any objection on this?
fabrizio

----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

> I would like to add support in ModuleVersionHandler for tasks that
> will always be executed AFTER install/update, BEFORE start and WITHOUT
> user intervention. This would mean adding a method like:
> List getUnconditionalTasks(InstallContext installContext);
> to ModuleVersionHandler and make it called it in ModuleManagerImpl

I agree to that kind of sanity checks and auto healing. But can we  
find a better name for that?

getSanityTasks(), getStartupTasks, ....

Philipp Bracher

>
> WDYT? Is there any objection on this?
> fabrizio
>
> ----------------------------------------------------------------
> for list details see
> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
> ----------------------------------------------------------------


----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:

> Hi,
> one of the missing bits in the update mechanism is still the ability
> of executing a list of tasks independently of the installed version.
> Running update tasks based on a version number is fine, but having the
> ability of automatically running a list of consistency check (and fix)
> tasks is sometime better and more robust.

The getDeltas() method can be reimplemented by each and every module  
if it needs to.
(which is where you could potentially always return certain deltas if  
you want to systematically run certain tasks at startup - and I see  
you coming with the "i don't want a gui for this" argument, but you  
fixed that already ;) )

>
> Taking as an example the cache module, it recently needed the
> addiction of cache voters configuration in jcr. At this moment if the
> cache voters configuration is missing it will ungracefully die with a
> NPE.
> Now: when to add cache voter configuration? Using the current API I
> should do it in basic install tasks and, implementing
> ModuleVersionHandler, also return this task based on version passed to
>  getDeltas().
>
> This pretty work but handling a previous version number could be not
> so easy (from which version should I add this configuration?)

This is a config that's new in 3.1, so in the constructor of  
CacheModuleVersionHandler extends DefaultModuleVersionHandler, you do
           register("3.1", delta);

> and
> doesn't handle the fact that if this configuration is removed from an
> existing repository, nobody will ever set it back and the manager will
> keep throwing its NPE.

This will be the case for each and every piece of configuration  
that's expected to be there by any kind of "manager", right ?
I'm in favor of sanity checks, but if users mess up their  
configuration, I'd just expect the Magnolia instance to die  
peacefully, not try to resuscitate itself.

> This kind of operations could be probably handled better by a Task
> that is always called and that bases its execution of the conditional
> presence of an existing configuration. For this example I would like
> to simply have a task that automatically adds the voters configuration
> ONLY IF a voters configuration is missing. This will handle install,
> update, and check/restore of any invalid configuration.
> Differently from what happens with standard update tasks this kind of
> tasks should not require manual intervention (they will be run at each
> restart) and should be silently executed after update and before
> starting the module.

ModuleLifecycle.start() ?

> Coming to the point:
> I would like to add support in ModuleVersionHandler for tasks that
> will always be executed AFTER install/update, BEFORE start and WITHOUT
> user intervention. This would mean adding a method like:
> List getUnconditionalTasks(InstallContext installContext);
> to ModuleVersionHandler and make it called it in ModuleManagerImpl
>
> WDYT? Is there any objection on this?

Well, given my comments above. I don't really see the point, since  
this seems to duplicate what is/can be done in ModuleLifecycle.start() ?
Now, I agree that it might be awkward to have code dealing with  
config nodes and such in there, while we tried to isolate the module  
objects and make them bean/config like. This would come with the  
price of yet some more complexity, but how about having the  
ModuleLifecycle implementations be a different object than the module  
itself? We'd have a clean versionHandler / lifecycle / config  
separation, then.

g





----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>
> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
> The getDeltas() method can be reimplemented by each and every module
> if it needs to.
> (which is where you could potentially always return certain deltas if
> you want to systematically run certain tasks at startup - and I see
> you coming with the "i don't want a gui for this" argument, but you
> fixed that already ;) )

the difference is that normal update task MAY have a gui, sometimes
that's desired and sometimes not so I added a way to turn it off. Task
that should be executed always must not require a user confirmation.
If we say that everything is controlled by the same configuration
parameter this means that if we adds tasks that should always be
executed we are forced to disable the gui for everything, which is not
want we want.

> > and
> > doesn't handle the fact that if this configuration is removed from an
> > existing repository, nobody will ever set it back and the manager will
> > keep throwing its NPE.
>
> This will be the case for each and every piece of configuration
> that's expected to be there by any kind of "manager", right ?
> I'm in favor of sanity checks, but if users mess up their
> configuration, I'd just expect the Magnolia instance to die
> peacefully, not try to resuscitate itself.

mh... sorry, but I think that keeping magnolia alive is better: we
don't touch anything existing, but if a standard configuration has
been deleted readding it back would not hurt. The only way for
recovering from a similar situation at this moment is re-bootstrapping
the whole config repository (if you are unable to load admininterface)
and that's absolutely worst

> Well, given my comments above. I don't really see the point, since
> this seems to duplicate what is/can be done in ModuleLifecycle.start() ?

a couple of valid reason:
- modulemanager already handles "transactional" update, loading all
the tasks and applying changes only if everything went ok. There is a
lot of boilerplate code for doing this, what's the point of
replicating this bunch of code in every single module?
- doing that in module manager means also that startup tasks are
executed for all the modules and only after that each module is
started. Doing that in ModuleLifecycle.start() means that you will run
task/start for each single module: if you have to check a
configuration that is used by another module too (i.e. filters) that's
not optimal at all.

please have a look at the current implementation in svn, IMHO it looks
easy and clean. It's easy for user to add tasks if they want and
nothing changes if you don't need them. The code in module manager is
clean and there is no added complexity.

fabrizio
         
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

[Magnolia - Dev mailing list]

Without going into details I do agree to Fabrizio:

- a startup task is not an install and not an update task, even if  
you could use the same mechanism (was not obvious to me ether)

- the lifecycle (or phases) for calling start method of the module  
and startup tasks are not exactly the same because the startup tasks  
are execute before any of the module is started.

I'm sure that other phases will be introduced in future and I can see  
no harm in that.

Philipp Bracher


On 22.08.2007, at 20:31, Fabrizio Giustina wrote:

> On 8/22/07, Grégory Joseph <dev-list@...> wrote:
>>
>> On Aug 20, 2007, at 22:42 , Fabrizio Giustina wrote:
>> The getDeltas() method can be reimplemented by each and every module
>> if it needs to.
>> (which is where you could potentially always return certain deltas if
>> you want to systematically run certain tasks at startup - and I see
>> you coming with the "i don't want a gui for this" argument, but you
>> fixed that already ;) )
>
> the difference is that normal update task MAY have a gui, sometimes
> that's desired and sometimes not so I added a way to turn it off. Task
> that should be executed always must not require a user confirmation.
> If we say that everything is controlled by the same configuration
> parameter this means that if we adds tasks that should always be
> executed we are forced to disable the gui for everything, which is not
> want we want.
>
>>> and
>>> doesn't handle the fact that if this configuration is removed  
>>> from an
>>> existing repository, nobody will ever set it back and the manager  
>>> will
>>> keep throwing its NPE.
>>
>> This will be the case for each and every piece of configuration
>> that's expected to be there by any kind of "manager", right ?
>> I'm in favor of sanity checks, but if users mess up their
>> configuration, I'd just expect the Magnolia instance to die
>> peacefully, not try to resuscitate itself.
>
> mh... sorry, but I think that keeping magnolia alive is better: we
> don't touch anything existing, but if a standard configuration has
> been deleted readding it back would not hurt. The only way for
> recovering from a similar situation at this moment is re-bootstrapping
> the whole config repository (if you are unable to load admininterface)
> and that's absolutely worst
>
>> Well, given my comments above. I don't really see the point, since
>> this seems to duplicate what is/can be done in  
>> ModuleLifecycle.start() ?
>
> a couple of valid reason:
> - modulemanager already handles "transactional" update, loading all
> the tasks and applying changes only if everything went ok. There is a
> lot of boilerplate code for doing this, what's the point of
> replicating this bunch of code in every single module?
> - doing that in module manager means also that startup tasks are
> executed for all the modules and only after that each module is
> started. Doing that in ModuleLifecycle.start() means that you will run
> task/start for each single module: if you have to check a
> configuration that is used by another module too (i.e. filters) that's
> not optimal at all.
>
> please have a look at the current implementation in svn, IMHO it looks
> easy and clean. It's easy for user to add tasks if they want and
> nothing changes if you don't need them. The code in module manager is
> clean and there is no added complexity.
>
> fabrizio
>
> ----------------------------------------------------------------
> for list details see
> http://documentation.magnolia.info/docs/en/editor/stayupdated.html
> ----------------------------------------------------------------

----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------