Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings

2017-09-20 Thread Ken Gaillot 
On Wed, 2017-09-20 at 11:48 +0200, Ferenc Wágner wrote:
> Ken Gaillot  writes:
> 
> > * undocumented LRMD_MAX_CHILDREN environment variable
> > (PCMK_node_action_limit is the current syntax)
> 
> By the way, is the current syntax documented somewhere?  Looking at

Unfortunately not in its entirety (on the to-do list)

The crmd man page documents load-threshold and node-action-limit

> crmd/throttle.c, throttle_update_job_max() is only ever invoked with
> a
> NULL argument, so "Global preference from the CIB" isn't implemented
> either.  Or do I overlook something?

See crmd/control.c:config_query_callback() -- it calls
throttle_update_job_max() with the value of node-action-limit (a
cluster property that applies to all nodes, as opposed to
PCMK_node_action_limit which is an environment variable that applies
only to the local node)
-- 
Ken Gaillot 




___
Users mailing list: Users@clusterlabs.org
http://lists.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

Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings

2017-09-20 Thread Ferenc Wágner 
Ken Gaillot  writes:

> * undocumented LRMD_MAX_CHILDREN environment variable
> (PCMK_node_action_limit is the current syntax)

By the way, is the current syntax documented somewhere?  Looking at
crmd/throttle.c, throttle_update_job_max() is only ever invoked with a
NULL argument, so "Global preference from the CIB" isn't implemented
either.  Or do I overlook something?
-- 
Thanks,
Feri

___
Users mailing list: Users@clusterlabs.org
http://lists.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

Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings

2017-09-19 Thread Ken Gaillot 
On Tue, 2017-09-19 at 10:18 +0300, Klechomir wrote:
> Hi Ken,
> Any plans that there will be "lost monitoring request" handling (an
> added 
> syntax) in 2.0?
> 
> Regards,
> Klecho

2.0 will be about removing legacy syntax rather than adding new
features. The X.Y.Z version numbering policy will become:

X (major): changes that prevent at least some rolling upgrades

Y (minor): changes that don't break any rolling upgrades but require
closer user attention (changes in configuration defaults, tool
behavior, and/or public C API)

Z (minor-minor): backward-compatible changes (features and bug fixes)

So, we can add new (backward-compatible) features in any release.

Specifically to your question, what do you mean by "lost monitoring
request"? If you mean the ability to ignore a certain number of failed
monitors before recovering, there are plans for that, but it will be
later than 2.0.

> On 18.9.2017 12:48:38 Ken Gaillot wrote:
> > As discussed at the recent ClusterLabs Summit, I plan to start the
> > release cycle for Pacemaker 1.1.18 soon.
> > 
> > There will be the usual bug fixes and a few small new features, but
> the
> > main goal will be to provide a final 1.1 release that Pacemaker 2.0
> can
> > branch from.
> > 
> > As such, 1.1.18 will start to log deprecation warnings for syntax
> that
> > is planned to be removed in 2.0. So, we need to decide fairly
> quickly
> > what we intend to remove.
> > 
> > Below is what I'm proposing. If anyone feels strongly about keeping
> > support for any of these, speak now or forever hold your peace!
> > 
> > * support for legacy cluster stacks (heartbeat, corosync 1 + CMAN,
> and
> > corosync 1 + pacemaker plugin). Pacemaker 2.0 will initially
> support
> > only corosync 2, though future support is planned for the new knet
> > stack.
> > 
> > * compile-time option to directly support SNMP and ESMTP in crm_mon
> > (i.e. the --snmp-* and --mail-* options) (alerts are the current
> > syntax)
> > 
> > * pcmk_*_cmd stonith attributes (pcmk_*_action is the current
> syntax)
> > 
> > * pcmk_poweroff_action (pcmk_off_action is the current syntax)
> > 
> > * "requires" operation meta-attribute ("requires" resource meta-
> > attribute is the current syntax)
> > 
> > * undocumented "resource isolation" feature (bundles are current
> > syntax)
> > 
> > * undocumented LRMD_MAX_CHILDREN environment variable
> > (PCMK_node_action_limit is the current syntax)
> > 
> > * cluster properties that have been obsoleted by the rsc_defaults
> and
> > op_defaults sections
> > ** stonith-enabled or stonith_enabled (now "requires" in
> rsc_defaults)
> > ** default-resource-stickiness, default_resource_stickiness (now
> > "resource-stickiness" in rsc_defaults)
> > ** is-managed-default or is_managed_default (now "is-managed" in
> > rsc_defaults)
> > ** default-action-timeout or default_action_timeout (now "timeout"
> in
> > op_defaults)
> > 
> > * undocumented old names of cluster properties
> > ** no_quorum_policy (now no-quorum-policy)
> > ** symmetric_cluster (now symmetric-cluster)
> > ** stonith_action (now stonith-action)
> > ** startup_fencing (now startup-fencing)
> > ** transition_idle_timeout (now cluster-delay)
> > ** default_action_timeout (now default-action-timeout)
> > ** stop_orphan_resources (now stop-orphan-resources)
> > ** stop_orphan_actions (now stop-orphan-actions)
> > ** remote_after_stop (now remove-after-stop)
> > ** dc_deadtime (now dc-deadtime)
> > ** cluster_recheck_interval (now cluster-recheck-interval)
> > ** election_timeout (now election-timeout)
> > ** shutdown_escalation (now shutdown-escalation)
> > 
> > * undocumented old names of resource meta-attributes
> > ** resource-failure-stickiness, resource_failure_stickiness,
> default-
> > resource-failure-stickiness, and
> > default_resource_failure_stickiness (now migration-threshold)
> > 
> > * undocumented and ignored -r option to lrmd
> > 
> > * compile-time option to use undocumented "notification-agent" and
> > "notification-recipient" cluster properties instead of current
> "alerts"
> > syntax
> > 
> > * compatibility with CIB schemas below 1.0, and schema 1.1 (should
> not
> > affect anyone who created their configuration using Pacemaker 1.0.0
> or
> > later)
-- 
Ken Gaillot 




___
Users mailing list: Users@clusterlabs.org
http://lists.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

Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings

2017-09-19 Thread Ken Gaillot 
On Tue, 2017-09-19 at 15:28 +0200, Jan Pokorný wrote:
> On 19/09/17 08:45 +0200, Klaus Wenninger wrote:
> > We could as well deprecate use of CRM_NOTIFY_* in alert-agents.
> > Just don't know an easy way of writing out a deprecation warning
> > upon a script using one of these.

I considered dropping support for CRM_notify_* in 2.0, but I think we
want to retain compatibility with scripts that people wrote for crm_mon
-E (which itself will not be deprecated this go-around either). I think
I'd rather wait for a future Pacemaker 2.x to break those, since alerts
are still relatively new to users.

The notification-agent/notification-recipient syntax is different,
since it was never released upstream.

> Rename to CRM_NOTIFY_DEPRECATED_* to allow emergency sed-based
> re-enabling in script-based notification agents (100% now?)
> while getting a clear message wrt. future across?

Not necessary, it's equally easy to s/CRM_notify_/CRM_alert_/g

> 
> > Of course one could search the alert-agents for the string when
> > they are read from the CIB. Apart from the multiple points of
> > ugliness this would impose positive point would be a log for non
> > existentalert-agents prior to their unsuccessful first use.
-- 
Ken Gaillot 




___
Users mailing list: Users@clusterlabs.org
http://lists.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

Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings

2017-09-19 Thread Jan Pokorný 
On 19/09/17 08:45 +0200, Klaus Wenninger wrote:
> We could as well deprecate use of CRM_NOTIFY_* in alert-agents.
> Just don't know an easy way of writing out a deprecation warning
> upon a script using one of these.

Rename to CRM_NOTIFY_DEPRECATED_* to allow emergency sed-based
re-enabling in script-based notification agents (100% now?)
while getting a clear message wrt. future across?

> Of course one could search the alert-agents for the string when
> they are read from the CIB. Apart from the multiple points of
> ugliness this would impose positive point would be a log for non
> existentalert-agents prior to their unsuccessful first use.

-- 
Jan (Poki)


pgp1sazWcxX4k.pgp
Description: PGP signature
___
Users mailing list: Users@clusterlabs.org
http://lists.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

Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings

2017-09-19 Thread Klechomir 
Hi Ken,
Any plans that there will be "lost monitoring request" handling (an added 
syntax) in 2.0?

Regards,
Klecho

On 18.9.2017 12:48:38 Ken Gaillot wrote:
> As discussed at the recent ClusterLabs Summit, I plan to start the
> release cycle for Pacemaker 1.1.18 soon.
> 
> There will be the usual bug fixes and a few small new features, but the
> main goal will be to provide a final 1.1 release that Pacemaker 2.0 can
> branch from.
> 
> As such, 1.1.18 will start to log deprecation warnings for syntax that
> is planned to be removed in 2.0. So, we need to decide fairly quickly
> what we intend to remove.
> 
> Below is what I'm proposing. If anyone feels strongly about keeping
> support for any of these, speak now or forever hold your peace!
> 
> * support for legacy cluster stacks (heartbeat, corosync 1 + CMAN, and
> corosync 1 + pacemaker plugin). Pacemaker 2.0 will initially support
> only corosync 2, though future support is planned for the new knet
> stack.
> 
> * compile-time option to directly support SNMP and ESMTP in crm_mon
> (i.e. the --snmp-* and --mail-* options) (alerts are the current
> syntax)
> 
> * pcmk_*_cmd stonith attributes (pcmk_*_action is the current syntax)
> 
> * pcmk_poweroff_action (pcmk_off_action is the current syntax)
> 
> * "requires" operation meta-attribute ("requires" resource meta-
> attribute is the current syntax)
> 
> * undocumented "resource isolation" feature (bundles are current
> syntax)
> 
> * undocumented LRMD_MAX_CHILDREN environment variable
> (PCMK_node_action_limit is the current syntax)
> 
> * cluster properties that have been obsoleted by the rsc_defaults and
> op_defaults sections
> ** stonith-enabled or stonith_enabled (now "requires" in rsc_defaults)
> ** default-resource-stickiness, default_resource_stickiness (now
> "resource-stickiness" in rsc_defaults)
> ** is-managed-default or is_managed_default (now "is-managed" in
> rsc_defaults)
> ** default-action-timeout or default_action_timeout (now "timeout" in
> op_defaults)
> 
> * undocumented old names of cluster properties
> ** no_quorum_policy (now no-quorum-policy)
> ** symmetric_cluster (now symmetric-cluster)
> ** stonith_action (now stonith-action)
> ** startup_fencing (now startup-fencing)
> ** transition_idle_timeout (now cluster-delay)
> ** default_action_timeout (now default-action-timeout)
> ** stop_orphan_resources (now stop-orphan-resources)
> ** stop_orphan_actions (now stop-orphan-actions)
> ** remote_after_stop (now remove-after-stop)
> ** dc_deadtime (now dc-deadtime)
> ** cluster_recheck_interval (now cluster-recheck-interval)
> ** election_timeout (now election-timeout)
> ** shutdown_escalation (now shutdown-escalation)
> 
> * undocumented old names of resource meta-attributes
> ** resource-failure-stickiness, resource_failure_stickiness, default-
> resource-failure-stickiness, and
> default_resource_failure_stickiness (now migration-threshold)
> 
> * undocumented and ignored -r option to lrmd
> 
> * compile-time option to use undocumented "notification-agent" and
> "notification-recipient" cluster properties instead of current "alerts"
> syntax
> 
> * compatibility with CIB schemas below 1.0, and schema 1.1 (should not
> affect anyone who created their configuration using Pacemaker 1.0.0 or
> later)


___
Users mailing list: Users@clusterlabs.org
http://lists.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

Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings

2017-09-19 Thread Klaus Wenninger 
On 09/18/2017 07:48 PM, Ken Gaillot wrote:
> As discussed at the recent ClusterLabs Summit, I plan to start the
> release cycle for Pacemaker 1.1.18 soon.
>
> There will be the usual bug fixes and a few small new features, but the
> main goal will be to provide a final 1.1 release that Pacemaker 2.0 can
> branch from.
>
> As such, 1.1.18 will start to log deprecation warnings for syntax that
> is planned to be removed in 2.0. So, we need to decide fairly quickly
> what we intend to remove.
>
> Below is what I'm proposing. If anyone feels strongly about keeping
> support for any of these, speak now or forever hold your peace!
>
> * support for legacy cluster stacks (heartbeat, corosync 1 + CMAN, and
> corosync 1 + pacemaker plugin). Pacemaker 2.0 will initially support
> only corosync 2, though future support is planned for the new knet
> stack.
>
> * compile-time option to directly support SNMP and ESMTP in crm_mon
> (i.e. the --snmp-* and --mail-* options) (alerts are the current
> syntax)
>
> * pcmk_*_cmd stonith attributes (pcmk_*_action is the current syntax)
>
> * pcmk_poweroff_action (pcmk_off_action is the current syntax)
>
> * "requires" operation meta-attribute ("requires" resource meta-
> attribute is the current syntax)
>
> * undocumented "resource isolation" feature (bundles are current
> syntax)
>
> * undocumented LRMD_MAX_CHILDREN environment variable
> (PCMK_node_action_limit is the current syntax)
>
> * cluster properties that have been obsoleted by the rsc_defaults and
> op_defaults sections
> ** stonith-enabled or stonith_enabled (now "requires" in rsc_defaults)
> ** default-resource-stickiness, default_resource_stickiness (now
> "resource-stickiness" in rsc_defaults)
> ** is-managed-default or is_managed_default (now "is-managed" in
> rsc_defaults)
> ** default-action-timeout or default_action_timeout (now "timeout" in
> op_defaults)
>
> * undocumented old names of cluster properties
> ** no_quorum_policy (now no-quorum-policy)
> ** symmetric_cluster (now symmetric-cluster)
> ** stonith_action (now stonith-action)
> ** startup_fencing (now startup-fencing)
> ** transition_idle_timeout (now cluster-delay)
> ** default_action_timeout (now default-action-timeout)
> ** stop_orphan_resources (now stop-orphan-resources)
> ** stop_orphan_actions (now stop-orphan-actions)
> ** remote_after_stop (now remove-after-stop)
> ** dc_deadtime (now dc-deadtime)
> ** cluster_recheck_interval (now cluster-recheck-interval)
> ** election_timeout (now election-timeout)
> ** shutdown_escalation (now shutdown-escalation)
>
> * undocumented old names of resource meta-attributes
> ** resource-failure-stickiness, resource_failure_stickiness, default-
> resource-failure-stickiness, and
> default_resource_failure_stickiness (now migration-threshold)
>
> * undocumented and ignored -r option to lrmd
>
> * compile-time option to use undocumented "notification-agent" and
> "notification-recipient" cluster properties instead of current "alerts"
> syntax

We could as well deprecate use of CRM_NOTIFY_* in alert-agents.
Just don't know an easy way of writing out a deprecation warning
upon a script using one of these.
Of course one could search the alert-agents for the string when
they are read from the CIB. Apart from the multiple points of
ugliness this would impose positive point would be a log for non
existentalert-agents prior to their unsuccessful first use.

Regards,
Klaus
 
>
> * compatibility with CIB schemas below 1.0, and schema 1.1 (should not
> affect anyone who created their configuration using Pacemaker 1.0.0 or
> later)


___
Users mailing list: Users@clusterlabs.org
http://lists.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

Re: [ClusterLabs] Pacemaker 1.1.18 deprecation warnings

2017-09-18 Thread Digimer 
On 2017-09-18 01:48 PM, Ken Gaillot wrote:
> As discussed at the recent ClusterLabs Summit, I plan to start the
> release cycle for Pacemaker 1.1.18 soon.
> 
> There will be the usual bug fixes and a few small new features, but the
> main goal will be to provide a final 1.1 release that Pacemaker 2.0 can
> branch from.
> 
> As such, 1.1.18 will start to log deprecation warnings for syntax that
> is planned to be removed in 2.0. So, we need to decide fairly quickly
> what we intend to remove.
> 
> Below is what I'm proposing. If anyone feels strongly about keeping
> support for any of these, speak now or forever hold your peace!
> 
> * support for legacy cluster stacks (heartbeat, corosync 1 + CMAN, and
> corosync 1 + pacemaker plugin). Pacemaker 2.0 will initially support
> only corosync 2, though future support is planned for the new knet
> stack.
> 
> * compile-time option to directly support SNMP and ESMTP in crm_mon
> (i.e. the --snmp-* and --mail-* options) (alerts are the current
> syntax)
> 
> * pcmk_*_cmd stonith attributes (pcmk_*_action is the current syntax)
> 
> * pcmk_poweroff_action (pcmk_off_action is the current syntax)
> 
> * "requires" operation meta-attribute ("requires" resource meta-
> attribute is the current syntax)
> 
> * undocumented "resource isolation" feature (bundles are current
> syntax)
> 
> * undocumented LRMD_MAX_CHILDREN environment variable
> (PCMK_node_action_limit is the current syntax)
> 
> * cluster properties that have been obsoleted by the rsc_defaults and
> op_defaults sections
> ** stonith-enabled or stonith_enabled (now "requires" in rsc_defaults)
> ** default-resource-stickiness, default_resource_stickiness (now
> "resource-stickiness" in rsc_defaults)
> ** is-managed-default or is_managed_default (now "is-managed" in
> rsc_defaults)
> ** default-action-timeout or default_action_timeout (now "timeout" in
> op_defaults)
> 
> * undocumented old names of cluster properties
> ** no_quorum_policy (now no-quorum-policy)
> ** symmetric_cluster (now symmetric-cluster)
> ** stonith_action (now stonith-action)
> ** startup_fencing (now startup-fencing)
> ** transition_idle_timeout (now cluster-delay)
> ** default_action_timeout (now default-action-timeout)
> ** stop_orphan_resources (now stop-orphan-resources)
> ** stop_orphan_actions (now stop-orphan-actions)
> ** remote_after_stop (now remove-after-stop)
> ** dc_deadtime (now dc-deadtime)
> ** cluster_recheck_interval (now cluster-recheck-interval)
> ** election_timeout (now election-timeout)
> ** shutdown_escalation (now shutdown-escalation)
> 
> * undocumented old names of resource meta-attributes
> ** resource-failure-stickiness, resource_failure_stickiness, default-
> resource-failure-stickiness, and
> default_resource_failure_stickiness (now migration-threshold)
> 
> * undocumented and ignored -r option to lrmd
> 
> * compile-time option to use undocumented "notification-agent" and
> "notification-recipient" cluster properties instead of current "alerts"
> syntax
> 
> * compatibility with CIB schemas below 1.0, and schema 1.1 (should not
> affect anyone who created their configuration using Pacemaker 1.0.0 or
> later)

Andrew announced that disabling stonith will put a node into maintenance
mode. This should be announced/alerted as well, eh?

-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould

___
Users mailing list: Users@clusterlabs.org
http://lists.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