> On 8 Dec 2015, at 2:55 AM, Ken Gaillot <kgail...@redhat.com> wrote: > > 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 <kgail...@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.
not at all. we only need to pull out the config option (and keep the inverse patch for rhel) > 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. > > _______________________________________________ > Developers mailing list > Developers@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/developers _______________________________________________ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers
