Hi Ulrich, On Fri, Sep 28, 2012 at 10:31:49AM +0200, Ulrich Windl wrote: > >>> Lars Marowsky-Bree <l...@suse.com> schrieb am 27.09.2012 um 16:52 in > >>> Nachricht > <20120927145202.gp4...@suse.de>: > > On 2012-09-27T16:36:08, Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> > > 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.
Well, the shell just passes the arguments to crm_resource. Perhaps we could do better here, but so far nobody complained about it. There's just so much time to be proactive and this seems to be a relatively seldom used feature (constraint lifetime). After all, the ISO format is not that bad, once you get used to it ;-) > > > 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. Right. > > > 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?). The local time could be better here. But the ISO standard requires to specify the UTC offset, so you'd want to do sth like P2M+02 We could append the offset automatically, but that would now be a semantic change thus possibly breaking existing scripts. > 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. As in P2? Yes, that should be fixed. Thanks, Dejan > Regards, > Ulrich > > > _______________________________________________ > Linux-HA mailing list > Linux-HA@lists.linux-ha.org > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
