[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Ken Gaillot]

On 12/07/2015 08:44 AM, Digimer wrote:
> On 07/12/15 05:07 AM, Dejan Muhamedagic wrote:
>> Hi,
>>
>> On Thu, Dec 03, 2015 at 11:29:24AM -0600, Ken Gaillot wrote:
>>> On 12/02/2015 05:26 PM, Andrew Beekhof wrote:
>>>>
>>>>> On 3 Dec 2015, at 10:23 AM, Ken Gaillot <kgaillot at redhat.com> wrote:
>>>>>
>>>>> For backward compatibility, the (brand new!) notification-agent and
>>>>> notification-recipient cluster properties would be kept as deprecated
>>>>> shortcuts for a single notify script and recipient.
>>>>
>>>> Actually, that didn't make it into an upstream release.
>>>> So we could just pretend it never happened :)
>>>>
>>>> Sure its in RHEL but we haven’t advertised it yet and it can be our problem to do backwards compatibility for - no need to inflict that on upstream.
>>>
>>> OK, we'll leave notifications as an undocumented/unsupported technology
>>> preview in 1.1.14, with significant interface changes expected in a
>>> later version. Users can play with it if they want, but with the
>>> understanding that their configs/scripts will need changes to work with
>>> future versions.
>>
>> It is overly optimistic to expect this. We have a problem people
>> reading any documentation at all, let alone whether a certain
>> thing is technology preview. I'd be wary of adding new features
>> in a released version for which interface is going to change.

Good point, but it's too thoroughly integrated to back out now. If
backward compatibility isn't too intrusive in the code, we can provide
it upstream. But the feature won't be in the official upstream
documentation, so people will really have to seek it out to use it.

>> Thanks,
>>
>> Dejan
> 
> What about having an 'enable_tech_preview_features="true"' (or
> something) option?

I don't think it's worth the time to implement and maintain. Plus, even
though it's not a good idea to run a cluster with varying versions of
pacemaker, it is possible, so this would be potentially problematic as a
cluster-wide property, and a nightmare as a node property.