[ClusterLabs] Antw: [EXT] Re: Order constraint with a timeout?

john tillman johnt at panix.com
Tue Mar 29 08:48:17 EDT 2022


>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 29.03.2022 um 01:25 in
> Nachricht
> <864c5d56cb507b2964c72ae0e38eb0c2459ebb2e.camel at redhat.com>:
>> On Mon, 2022‑03‑28 at 17:26 ‑0400, john tillman wrote:
>>> > On Mon, 2022‑03‑28 at 14:03 ‑0400, john tillman wrote:
>>> > > Greetings all,
>>> > >
>>> > > Is it possible to have an order constraint with a timeout?  I
>>> > > can't
>>> > > find
>>> > > one but perhaps I am using the wrong keywords in google.
>>> > >
>>> > > I have several Filesystem resource and one nfs service
>>> > > resource.  If
>>> > > I
>>> > > create 3 order constraints:
>>> > >    pcs constraint order start fsRsc1 then start myNfsServiceRsc
>>> > >    pcs constraint order start fsRsc2 then start myNfsServiceRsc
>>> > >    pcs constraint order start fsRsc3 then start myNfsServiceRsc
>>> > >
>>> > > I would like to make sure that the nfs service will be started
>>> > > even
>>> > > if one
>>> > > of the Filesystem resources fails to start.  Is there a timeout
>>> > > that
>>> > > could
>>> > > be used?
>>> > >
>>> > > There is the "kind=Optional" parameter but that looks like it
>>> > > will
>>> > > immediately start the second resource if the first failed to
>>> > > start.  There
>>> > > is no timeout option.
>>> > >
>>> > > Best regards,
>>> > > ‑John
>>> > >
>>> >
>>> > How do you envision the timeout working?
>>> >
>>> > You can add a timeout for the ordering itself using rules, where
>>> > the
>>> > ordering no longer applies after a certain date/time, but it
>>> > doesn't
>>> > sound like that's what you want.
>>> > ‑‑
>>> > Ken Gaillot <kgaillot at redhat.com>
>>> >
>>>
>>> Thank you for the reply, Ken.
>>>
>>> I was hoping that I could give the Filesystem resource "X" seconds to
>>> start.  If it failed to start after "X" then I would start the nfs
>>> service
>>> anyway.  So Those Filesystems that successfully started could be
>>> accessed,
>>> albeit with a bit of a delay before nfs is started.
>>>
>>> Basically, I want to start the nfs service regardless of whether any
>>> or
>>> all of the Filesystem resources started.  But I want to give them all
>>> a
>>> chance start before starting nfs.
>>>
>>> That said, it doesn't look like the rules suggestion you made is what
>>> I
>>> need.  Any other ideas?
>>>
>>> Best Regards,
>>> ‑John
>>>
>>
>> I don't think there is a way to do that except maybe with customizing
>> the filesystem resource agent.
>
> Hi!
>
> I'm not sure, but isn't there a mechanism like "start a set of resources
> first, then start another one".
> What is probably wanted is to ignore the failure of some of those set
> members.
> So I wonder: What use is HA if the guarantee is "the filesystem might be
> there"?
> Still: what about on-fail=ignore (for start) for those filesystems that
> aren't
> considered essential?
>
> Regards,
> Ulrich
>
>


Ulrich,
Thank you for the suggestion of "on-fail".  I'll review the docs on this.
I tried working with a "set" of resources before with mixed success.  I
will consider it again.
-John

>>
>> If you customized the agent, you could have it set a transient node
>> attribute (like fs‑<RESOURCE ID>) when attempting to start, regardless
>> of whether it succeeded or failed. Then you could configure a location
>> constraint for the nfs server using a rule that allows the nfs server
>> to run only on a node where all three node attributes have been
>> defined.
>> ‑‑
>> Ken Gaillot <kgaillot at redhat.com>
>>
>> _______________________________________________
>> Manage your subscription:
>> https://lists.clusterlabs.org/mailman/listinfo/users
>>
>> ClusterLabs home: https://www.clusterlabs.org/
>
>


Ken,
Thank you for the suggestion but that sounds more complicated than I am
ready to attempt.
-John


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




More information about the Users mailing list