Re: Reliable deployment and operation Re: Installing LSMB 1.3: Spreadsheet::ParseExcel Failed!

[Chris Travers <..hidden..>]

On Sat, Feb 20, 2010 at 3:03 AM, Iserv-appbox <..hidden..> wrote:
> Hi Chris,
>
> I'm not an experienced Perl programmer, but IMHO this issue raises questions
> about the stability of the application.
>
> If on the one hand the application depends on a bunch of Perl modules, and
> on the other hand these modules are constantly evolving, how can a reliable
> deployement and a reliable operation of the application be assured?

On the deployment side, this is a bit of a problem just because
somewhere a bad version can break things.  (There were some bad
versions of Template::latex in the past which caused problems.)

To some extent this is a problem any time there are external
components.  See the delay in getting Perl 5.10 or PostgreSQL 8.3
supported (Pg 8.4 shouldn't be a problem, FWIW).

The 1.3 codebase also tries to support a wide range of DBD::Pg
versions from 1.x to 2.x (though I want to drop 1.x support in 1.4).
This can be a little tricky due to differences in how PostgreSQL
arrays are handled between the two versions.

On the operation side this is less of an issue.  Typically speaking
Perl modules are not updated willy-nilly or automatically and
consequently once everything is working it tends to continue to work.
In general there are only two ways that Perl modules will be updated:
Either by the platform's update features (yum, apt-get etc), or by
installing something else that requires a newer version of a Perl
module.  In general, most distros tend to be sane about allowing
automatic updates.  CPAN may be somewhat less sane.

There is one major protection offered here for 1.3:  Nearly all test
cases are designed to be runnable against a production instance and
database without committing any writes to it.  This allows the test
cases to be used not only for routine "let's make sure everything is
still fine" checks but also for troubleshooting.  We can say "Run a
make test against your database and post the result" and sometimes
that will show what's wrong.

On the whole though, it's a trade off.  On the whole, it is probably
true that pushing as much as is feasible to CPAN reduces the
likelihood of problems compared to managing all code ourselves.  On
the other hand, it is also true that there may be cases where we have
to be more careful and avoid relying on modules that are undergoing
rapid change.

>
> Is it possible to enforce a strict version policy of all required modules
> at installation time?

I am not aware of any way to do this.  I could be wrong.
>
> If not, should the application be distributed with all the required modules
> included (e.g. in a separate package)?

One issue here is that many of the required modules have dependencies.
  I have no idea what would be required to install known good versions
of every dependency all the way down.

The current approach has been to engage with the main modules of
concern (DBD::Pg, TemplateToolkit, etc) and make sure we are involved
in their communities and review changes as soon as possible for
problems.

DBD::Pg in particular has undergone some extremely rapid growth during
the time that 1.3 development was occurring, and most of this will be
very positive in the long-run but has caused some potential for
DBD::Pg version-specific problems.  Currently I build on one version
of DBD::Pg and test on another.

To give you an example here of an actual versioning problem with the API.

In DBD::Pg 1.x, Pg arrays are handled exclusively as strings.  So:

my @array = (1, 2, 3, 4, 5);

$sth = $dbh->prepare('select array_to_string(?, ?)');
$sth->execute(..hidden.., '--');

gives a DBI error.

Similarly:
($val) = $dbh->select_all_array("select string_to_array('1--2--3--4', '--')");

print "$val\n";

will print
{1,2,3,4}


This changes in DBD::Pg 2.x:

my @array = (1, 2, 3, 4, 5);

$sth = $dbh->prepare('select array_to_string(?, ?)');
$sth->execute(..hidden.., '--');
($var) = $sth->fetchrow_array;

print "$var\n";

prints:
1--2--3--4--5

Similarly:
($val) = $dbh->select_all_array("select string_to_array('1--2--3--4', '--')");

print "$val\n";

will out a notice that $val is an ARRAY reference.

Consequently there are possibilities for bugs to be present in either
the earlier versions or the later versions but not the other.

To be honest, this does create a headache, but on the whole it's a
fairly manageable one.

Sometimes there are temporary issues of modules not passing make test
and hence not installing (as with Excel::Template::Plus) but these are
usually fixed pretty quickly and it is usually possible to get an
older version if necessary.

The primary protection though is in good test cases for make test.
This is the best way to ensure versioning problems don't occur and
that the software can run on current configurations.

Hope this helps,
Chris Travers