JustinKuli

How the title works

The title is probably the first thing someone will see of the gist, so it's kind of important. Put simply: the title is the filename (including extension) of the "first" file in the Gist - first after GitHub re-orders them, at least.

So, how does GitHub re-order the files? Well... alphabetically, sort of.

There are a few tricky parts, like where it puts symbols, in relation to each other and in relation to the modern English alphabet. Another tricky part is how it orders capital letters.

JustinKuli

Tekton Task Results

When writing a Tekton Pipeline, it's common to want to pass information from one Task to another. One way to get information into a Task is via parameters. Then, either inside the a step's script, or via environment variables, it is possible to use variable substitution with those params.

Getting information out of a task/step is more complex, since there are multiple methods. It is possible to store information in a file in a workspace, but that generally requires a PersistentVolume, and you must carefully ensure the Tasks run in the correct order. Results, as we will see, are a better way to pass small bits of information out of a Task.

JustinKuli

Using the Policy Generator to Order Policies

The files here utilize the policy generator plugin to create some of the policies used in this blog: https://cloud.redhat.com/blog/using-policy-dependencies-to-apply-resources-in-a-specific-order.

The "tricks" are to use consolidateManifests: false and orderManifests: true to create the extraDependencies within one policy, and to use orderPolicies: true to create the dependency between separate policies.

The output is included here for convenience.

JustinKuli

The idea is to use a Placement and a Policy to distribute a resource to managed cluster namespaces on a hub cluster, not to the actual managed clusters.

This can be accomplished by using two ranges in object-templates-raw in the Policy: one over all the PlacementDecisions, and then one over all the clusters in each decision. For example, the Policy would be:

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: jkuli-policy-test-slack
  namespace: open-cluster-management-global-set
spec:

JustinKuli

With an ACM mustgather of the hub, navigate into a managedcluster namespace, then run this script to identify possibly affected policies:

for file in *.yaml; do
  ts_ten="$(yq e '.status.details[].history[9].lastTimestamp | select(. != null)' ${file})"
  if [[ -n "${ts_ten}" ]]; then
    echo "${ts_ten} - ${file}"
  fi
done

JustinKuli

Overview

This gist demonstrates using Red Hat OpenShift GitOps (read: ArgoCD) with the policy framework in Red Hat Advanced Cluster Management for Kubernetes (RHACM, with a community at open-cluster-management.io). In particular it shows how the OperatorPolicy kind provides a more gitops-friendly surface for managing OLM operators, compared to managing Subscriptions, ClusterServiceVersions, InstallPlans (and more) directly.