// The policy cares about an operation if it matches _any_ Rule.
  // +listType=atomic
  // +optional
  repeated NamedRuleWithOperations resourceRules = 3;

  // ExcludeResourceRules describes what operations on what resources/subresources the ValidatingAdmissionPolicy should not care about.
  // The exclude rules take precedence over include rules (if a resource matches both, it is excluded)
  // +listType=atomic

import org.codelibs.core.io.SerializeUtil;
import org.junit.After;
import org.junit.Before;
import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExpectedException;

/**
 * @author higa
 *
 */
public class ArrayMapTest {

    /**
     * @see org.junit.rules.ExpectedException
     */
    @Rule
    public ExpectedException exception = ExpectedException.none();

    ArrayMap<String, String> map;

	// Append our rules here
	builder := cfg.appendHostRules(hostSNATIP, hostSNATIPV6)

	log.Info("Adding host netnamespace iptables rules")

	if err := cfg.executeCommands(log.WithLabels("component", "host"), builder); err != nil {
		log.Errorf("failed to add host netnamespace iptables rules: %v", err)
		return err
	}
	return nil
}

 * 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 gradlebuild.codenarc.rules;

import org.codehaus.groovy.ast.ASTNode;
import org.codehaus.groovy.ast.ClassNode;
import org.codehaus.groovy.ast.MethodNode;
import org.codehaus.groovy.ast.expr.Expression;

}

// PodFailurePolicy describes how failed pods influence the backoffLimit.
message PodFailurePolicy {
  // A list of pod failure policy rules. The rules are evaluated in order.
  // Once a rule matches a Pod failure, the remaining of the rules are ignored.
  // When no rule matches the Pod failure, the default handling applies - the
  // counter of pod failures is incremented and it is checked against

     * and no heuristic rule will be involved.
     *
     * <p>It is nevertheless common to specify two or more types of path. For example,
     * a Java library may be compatible with either the class-path or the module-path,
     * and the user may have provided no instruction about which type to use. In such
     * case, the plugin may apply rules for choosing a path. See for example

// superset of type `list:set` - we can then query the superset directly in iptables (with the same rule),
// and iptables will be smart enough to pick the correct underlying set (v4 or v6, based on context),
// reducing the # of rules we need.
//
// BUT netlink lib doesn't support adding things to `list:set` types yet, and current tagged release

sleep 10s

## Add warm tier
./mc ilm tier add minio sitea WARM-TIER --endpoint http://localhost:9004 --access-key minioadmin --secret-key minioadmin --bucket bucket

## Add ILM rules
./mc ilm add sitea/bucket --transition-days 0 --transition-tier WARM-TIER
./mc ilm rule list sitea/bucket

./mc cp README.md sitea/bucket/README.md

until $(./mc stat sitea/bucket/README.md --json | jq -r '.metadata."X-Amz-Storage-Class"' | grep -q WARM-TIER); do

    // checkPublicSuffix("a.b.example.local", null);
    // TLD with only 1 rule.
    checkPublicSuffix("biz", null)
    checkPublicSuffix("domain.biz", "domain.biz")
    checkPublicSuffix("b.domain.biz", "domain.biz")
    checkPublicSuffix("a.b.domain.biz", "domain.biz")
    // TLD with some 2-level rules.
    checkPublicSuffix("com", null)
    checkPublicSuffix("example.com", "example.com")

for existing object replication are detected when scanner runs, and will be replicated if existing object replication is enabled and applicable replication rules are satisfied. Because replication depends on the immutability of versions, only pre-existing objects created while versioning was enabled can be replicated. Even if replication rules are disabled and re-enabled later, the objects created during the interim will be synced as the scanner queues them. For saving iops, objects qualifying for...