Re: [lmi] wx_test_expiry_dates.cpp

[Vadim Zeitlin]

On Fri, 12 Dec 2014 20:45:02 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2014-12-07 14:36, Vadim Zeitlin wrote:
GC> [...]
GC> >  OK, this seems to have been easy -- and didn't even result in any
GC> > questions.
GC> 
GC> Yes, you did exactly what we asked, and, even though we try to think
GC> everything through beforehand, in this case we surprised ourselves.

 This is perfectly par the course, no specification survives first contact
with reality. But I should have run the test both with and without the
secret option and so noticed the problem, sorry for not thinking to do it.
And hopefully I'll remember to do it for all the other tests.

GC> She needs to test the system as end users will run it, but with a
GC> special twist: the January distribution she is now getting ready to
GC> prepare must work in [2015-01-01, 2015-01-31] (the 'expiry' file), but
GC> she has to test it before releasing it. Yet running it today, with that
GC> 'expiry' range, without '--ash_nazg', will prevent lmi (and hence
GC> wx_test) from running at all.

 Yes, I see the problem.

GC> To test this manually, we've altered the computer's clock. That is
GC> effective, but extremely distasteful; and someday the corporation may
GC> withdraw the privilege to do that, so that's not acceptable either.
GC> 
GC> The best solution we see, which we would like to ask you to implement
GC> if you see no better solution,

 I do see something that looks like a better solution to me: changing the
system clock is indeed somewhat unappetizing, but the basic idea is sound,
it's just that using a global solution to a local problem[*] is bad. But
what if instead of changing the date globally for the entire system, we
just changed the date used by lmi in authenticate_system()? AFAICS this
would solve the problem nicely: we'd still run exactly the same code, so no
divergences from the real program behaviour would be possible, and all Kim
would need to do would be to run the test with --distribution=20150101
instead of just --distribution option. What do you think?

 Of course, this would still require some changes to lmi itself, but they
would be pretty minimal and smaller than what would be needed for your
solution.

 Notice that if you really want this functionality to be available at the
level of the main program itself, and not just in the test, then I still
think it would be better to add --check-date=YYYYMMDD option to the main
program rather than specific --warn-about-expiration-but-not-really one you
proposed. But such option wouldn't be without danger, of course.

 Finally, there is also a possibility to be more general and add a way (via
command line option or configurable settings value) to change the value of
"today" in lmi globally. This is more than what's needed just to solve the
problem at hand but it might be useful, e.g. to test whether lmi suffers
from y2038k problem. In this case it should be probably called --run-date
and change the value returned by calendar_date::today() and
iso_8601_datestamp_verbose_xxx() functions (which don't use calendar_date
for some reason, perhaps this should be changed?).

GC> is to add a command-line option to lmi itself that conditionally
GC> demotes the fatal error to a dire warning.

 I dislike this solution because I believe a fatal error should always be
fatal, the code and the behaviour of the program becomes confusing
otherwise. Running the check at a date at which it's really supposed to be
used to avoid the error in the first place is much better IMHO.

 But please let me know what do you think,
VZ

[*] I have no idea who has said this first but for me the statement that
    "using global solutions to local problems always results in troubles"
    is just as profound as the famours Graf von Moltke's quote paraphrased 
    in the first sentence of this message.