[ClusterLabs] Antw: Re: Antw: Re: Antw: [EXT] Re: A bug? (SLES15 SP2 with "crm resource refresh")

Klaus Wenninger kwenning at redhat.com
Wed Jan 13 04:11:27 EST 2021


On 1/12/21 8:23 AM, Ulrich Windl wrote:
>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 11.01.2021 um 16:45 in Nachricht
> <3e78312a1c92cde0a1cdd82c2fed33a679f63770.camel at redhat.com>:
>
> ...
>>>> from growing indefinitely). (Plus some timing issues to consider.)
>>> Wouldn't a temporary local status variable do also?
> Hi Ken,
>
> I appreciate your comments.
>  
>> No, the scheduler is stateless. All information that the scheduler
>> needs must be contained within the CIB.
>>
>> The main advantages of that approach are (1) the scheduler can crash
>> and respawn without causing any problems; (2) the DC can be changed to
> I think it's nice when being able to recover smoothly after a crash, but program design should not be biased towards frequent crashes ;-)
>
>> another node at any time without causing any problems; and (3) saved
> Well, if every status update is stored in the CIB (as it seems to be), changing DCs shouln't be a bug problem until there are multiple at the same time.
>
>> CIBs can be replayed for debugging and testing purposes with the
>> identical result as a live cluster.
> Are you talking about the whole CIB, or about the configuration section of the CIB? I can't see any sense of replacing the status section of the CIB unless you want to debug resource recovery and probing.
That is the whole CIB. All the scheduler regression tests are working like
that. Feed the CIB into crm_simulate and see what it does.

Klaus
>
> ...
>
> Regards,
> Ulrich
>
>
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/
>



More information about the Users mailing list