[wpkg-users] Behaviour of WPKG

[Johannes.Brix at evidian.com]

Hello Rainer,

I agree to most of your arguments.

But there are some circumstances which cause problems.
Most of my users are road warriors.

Although they have a VPN connection to our company network,
a software update over VPN is impossible (takes too long, blocks the 
line).

So, I added a check if a computer is locally attached to the network.
Which means, a road warrior must be in the office.

But when she comes, she has not much time. 
So any failed software update is anoying.

In this situation, there are always lot of packages to update.
And then, it happens that some installations keep hanging.
I have not yet found a reason.

Waiting for the timeout is also no solution, even I lower the timer value.

In this situation, the update is canceled -> not update of WPKG.xml
---
I agree to your thoughts about performance, but a good compromize
will be a switch which would allow the administrator to decide to
choose performance or to commit each successfull update.

br
Johannes






Rainer Meier <r.meier at wpkg.org>
14.07.2009 18:54

 
        To:     Johannes.Brix at evidian.com
        cc:     wpkg-users at lists.wpkg.org
        Subject:        Re: [wpkg-users] Behaviour of WPKG


Hi Johannes,

Johannes.Brix at evidian.com wrote:
> I have also a topic for the general behaviour:
>
> WPKG loads at start the local WPKG.xml into the memory.
> Then, it executes all pending tasks.
> At the end, it writes back WPKG.xml to the PC.
>
> And here is my problem.
> When the total job fails for any reason, the WPKG.xml is not updated,
> although some tasks have been executed successfully.

In which cases did you experience problems that wpkg.xml is not committed?
In fact this should happen only in the following cases (add more if you 
know
about more):
- WPKG encounters unrecoverable internal error (exception). This case is
supposed not to happen at all.

Well, that's it - I don't know about more cases where wpkg.xml is not 
updated.
The case where a package is not removed/added to wpkg.xml when there is a
pending reboot is intended. WPKG just adds a package after all commands
terminated properly without requesting reboot. Else it would be possible 
that a
command actually left some uninstall entries in the registry, WPKG would 
accept
it as successful but on next reboot the software is not there. But I guess 
we
are not talking about that case.


> A new run will do a lot of senseless actions, because WPKG.xml doesn't
> reflect the real status.

Well, i it crashes (the only case I could think about where wpkg.xml is 
not
written) then it might run through a couple of additional commands. In 
practice
it's unlikely that more than 10 packages are update din one shot. Actually 
on
all my systems it's usually just a single package which is
updated/changed/touched on each run. So this one might be re-run.

The current architecture of WPKG would allow to re-write wpkg.xml each 
time an
entry is added or remove (addSettingsNode() / removeSettingsNode()). 
However
this involves re-writing wpkg.xml as many times as there are packages 
assigned
to the host. Which means if you have 20 packages assigned wpkg.xml would 
be
written 20 times. Actually WPKG 0.9 did this and I removed it because I 
did not
experience problems when it is written just once on proper termination of 
WPKG
so I left this optimization in. My intention was to operate in memory as 
much as
possible because especially during bootup the system is already loaded by 
heavy
disk operations and accessing disk (writing in particular) is always 
something a
programmer should wisely plan. In general WPKG has been designed to be 
able to
start from any state and bring the system to the desired/defined state. So 
even
a crash (no matter in which state) should be recoverable by WPKG.

If it's causing severe problems to lots of you we can change it.


> What do you think about a "Commit" after each successful executed task
> so that WPKG.xml reflects the real status.

See above.


> This could be done automatical or by a flag.

Well, for such an internal thing I would recommend not to use a flag - 
it's more
confusing than helping - and enabling/disabling internal optimizations 
should
not be a flag. Either we decide to go for some optimization or we go for 
some
overhead - both should be reliable. So I would like to hear if and in 
which
cases people have problems with this feature.


br,
Rainer