[ClusterLabs] Antw: Re: Q: status section of CIB: "last_0" IDs and "queue-time"

[Ulrich Windl]

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 01.06.2016 um 16:14 in Nachricht
<574EEDE2.1090307 at redhat.com>:
> On 06/01/2016 06:14 AM, Ulrich Windl wrote:
>> Hello!
>> 
>> I have a question:
>> Inspecting the XML of our cluster, I noticed that there are several IDs 
> ending with "last_0". So I wondered:
>> It seems those IDs are generated for start and stop operations, and I 
> discovered one case where an ID is duplicate (the status is for different 
> nodes, and one is a start operation, while the other is a stop 
> operationhowever).
> 
> The "*_last_*" IDs simply refer to the last (= most recently executed)
> operation :)
> 
> Those IDs are not directly used by the cluster; they're just used to
> store the most recent operation in the CIB.
> 
>> Background: I wrote some program that extarcts the runtimes of operations 
> from the CIB, like this:
>> prm_r00_fs_last_0 13464 stop
>> prm_r00_fs_last_0 61 start
>> prm_r00_fs_monitor_300000 34 monitor
>> prm_r00_fs_monitor_300000 43 monitor
>> 
>> The first word is the "id" attribute, the second is the "exec-time" 
> attribute, and the last one (added to help myself out of confusion) is the 
> "operation" attribute. Values are converted to milliseconds.
>> 
>> Is the name of the id intentional, or is it some mistake?
>> 
>> And another question: For an operation with "start-delay" it seems the start 
> delay is simple added to the queue time (as if the operation was waiting that 
> long). Is that intentional?
> 
> Yes. The operation is queued when it is received, and if it has a start
> delay, a timer is set to execute it at a later time. So the delay
> happens while the operation is queued.

Ken,

thanks for the answers. Is there a way to distinguish "intentional" from "non intentional" queueing? One would look deeper into non-intentional queueing.

Regards,
Ulrich

> 
>> Another program tried to extract queue and execution times for operations, 
> and the sorted result looks like this then:
>> 
>> 1 27 prm_nfs_home_exp_last_0 monitor
>> 1 39 prm_q10_ip_2_monitor_60000 monitor
>> 1 42 prm_e10_ip_2_monitor_60000 monitor
>> 1 58 prm_s01_ip_last_0 stop
>> 1 74 prm_nfs_cbw_trans_exp_last_0 start
>> 30001 1180 prm_stonith_sbd_monitor_180000 monitor
>> 30001 178 prm_c11_ascs_ers_monitor_60000 monitor
>> 30002 165 prm_c11_ascs_ers_monitor_45000 monitor
>> 
>> Regards,
>> Ulrich
> 
> _______________________________________________
> Users mailing list: Users at clusterlabs.org 
> http://clusterlabs.org/mailman/listinfo/users 
> 
> Project Home: http://www.clusterlabs.org 
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf 
> Bugs: http://bugs.clusterlabs.org