Github user aledsage commented on a diff in the pull request:
https://github.com/apache/brooklyn-server/pull/879#discussion_r149317795
--- Diff:
policy/src/main/java/org/apache/brooklyn/policy/ha/ElectPrimaryPolicy.java ---
@@ -0,0 +1,223 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.brooklyn.policy.ha;
+
+import java.util.Collection;
+import java.util.List;
+import java.util.Map;
+
+import org.apache.brooklyn.api.entity.Entity;
+import org.apache.brooklyn.api.entity.Group;
+import org.apache.brooklyn.api.mgmt.Task;
+import org.apache.brooklyn.api.sensor.AttributeSensor;
+import org.apache.brooklyn.api.sensor.EnricherSpec;
+import org.apache.brooklyn.api.sensor.Sensor;
+import org.apache.brooklyn.api.sensor.SensorEvent;
+import org.apache.brooklyn.api.sensor.SensorEventListener;
+import org.apache.brooklyn.config.ConfigKey;
+import org.apache.brooklyn.core.config.ConfigKeys;
+import org.apache.brooklyn.core.effector.Effectors;
+import org.apache.brooklyn.core.entity.AbstractEntity;
+import org.apache.brooklyn.core.entity.Attributes;
+import org.apache.brooklyn.core.entity.Entities;
+import org.apache.brooklyn.core.entity.EntityInternal;
+import org.apache.brooklyn.core.entity.StartableApplication;
+import org.apache.brooklyn.core.entity.lifecycle.Lifecycle;
+import org.apache.brooklyn.core.mgmt.BrooklynTaskTags;
+import org.apache.brooklyn.core.policy.AbstractPolicy;
+import org.apache.brooklyn.core.sensor.Sensors;
+import org.apache.brooklyn.entity.group.DynamicGroup;
+import org.apache.brooklyn.util.collections.MutableList;
+import org.apache.brooklyn.util.collections.QuorumCheck.QuorumChecks;
+import org.apache.brooklyn.util.core.task.DynamicTasks;
+import org.apache.brooklyn.util.exceptions.Exceptions;
+import org.apache.brooklyn.util.exceptions.UserFacingException;
+import org.apache.brooklyn.util.text.Strings;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.common.base.Preconditions;
+import com.google.common.base.Throwables;
+import com.google.common.reflect.TypeToken;
+
+/**
+
+The ElectPrimaryPolicy acts to keep exactly one of its children or members
as primary, promoting and demoting them when required.
+
+A simple use case is where we have two children, call them North and
South, and we wish for North to be primary. If North fails, however, we want
to promote and fail over to South. This can be done by:
+
+* adding this policy at the parent
+* setting ` ha.primary.weight` on North
+* optionally defining `promote` on North and South (if action is required
there to promote it)
+* observing the `primary` sensor to see which is primary
+* optionally setting `propagate.primary.sensors: [ main.uri ]` to publish
`main.uri` from whichever of North or South is active
+* optionally setting `primary.selection.mode: best` to switch back to
North if it comes back online
+
+The policy works by listening for service-up changes in the target pool
(children or members) and listening for `ha.primary.weight` sensor values from
those elements.
--- End diff --
Perhaps worth making the trigger sensor (defaulting to `service-up`)
configurable. I could see that someone would want stabilisation delays etc.
However, I see that is additive (i.e. does not break backwards
compatibility if we add it later) so is fine to defer.
(With hindsight, the way we've done stabilisation delays in
service-restarter, service-replacer etc doesn't feel quite right. We should
probably have just had a simple enricher that does a stabilisation delay,
setting a different sensor.)
---
