>>> Lars Marowsky-Bree <[email protected]> schrieb am 27.09.2012 um 16:52 in
>>> Nachricht
<[email protected]>:
> On 2012-09-27T16:36:08, Ulrich Windl <[email protected]>
> wrote:
>
> Hi Ulrich,
>
> we always appreciate your friendly, constructive and non-condescending
> feedback.
Hi Lars!
I know you don't like it if I talk publically about bugs found in SLES, but I
think it's OK to talk about bugs in open source software. The idea is not to
make big secrets about problems, but to address and fix them. Despite of that I
was under severe time-pressure yesterday, but I wanted to report on this issue.
>
> > However if you specify a duration like "P2", the duration is not added to
> the current time; instead the current time is used as lifetime (it seems):
>
> "P2" does not specify a unit for the duration. So I'm not perfectly sure
> what expected behavior would be.
You are right, I was in a hurry, and I missed the trailing "M", e.g. "P2M"
(=two minutes duration).
>
> > Sep 26 13:55:03 o1 cib: [13067]: info: cib:diff: +
> <date_expression id="cli-prefer-lifetime-end-prm_xen_s01" operation="lt"
> end="2013-07-26 11:55:03Z" />
>
> If it's already Jul 26 2013 for you on Sep 26 2012, I'm amazed. ;-)
Oops! You are right, and I overlooked it in that case (despite of that, it
doesn't make the result any better). So I guess I'll have to retry:
crm(live)resource# migrate prm_xen_s03 P5M
Migration will take effect until: 2013-02-28 08:11:38Z
WARNING: Creating rsc_location constraint 'cli-standby-prm_xen_s03' with a
score of -INFINITY for resource prm_xen_s03 on o5.
This will prevent prm_xen_s03 from running on o5 until the constraint
is removed using the 'crm_resource -U' command or manually with cibadmin
This will be the case even if o5 is the last node in the cluster
This message can be disabled with -Q
o2:~ # date
Fri Sep 28 10:11:43 CEST 2012
>
> Admittedly, how "P2" ends up being expanded to 13 months I'm not sure.
It seems it was my fault (due to the remarkable ISO syntax using 'M' for both,
months and minutes): I never thought that somebody could specify months as a
duration for migration, but "P5M" are 5 months, while "PT5M" are 5 minutes.
>
> > So when the change being logged includes up to the second exactly the
> current time, the duration is effectively ignored.
> >
> > Must IT be so complicated? If you insist on ISO syntax on one hand, I
> expect you understand the syntax correctly, so a duration has to be added to
> the current time to make any sense.
>
> In your opinion, what time unit should it default to?
Most of the rest is using seconds, and I guess whenever a admin uses a limited
lifetime for migration, it's in the range of minutes rather than days.
>
> What happens when you specify "P2D", for example?
Two days, I guess.
>
> > To make things worse, why is crm shell displaying the time in UTC (in
> > non-XML mode)? In Perl ist a simple "scalar localtime $time" that will
> > make things easier to read.
>
> We probably should make this optional, yes. Internally we need to store
> it in UTC format.
I knew; for us Europeans it's still quite OK, but those who are away from
Greenwich by more than 6 hours, things may vary (which sysadmin plans his
maintenance in UTC time?).
So what remains from the issue is this: The ISO duration parser seems to have a
problem for invalid input, but it works correctly for valid input.
Regards,
Ulrich
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
