However, there is also a bit of additional logic. Gateway types have extensive status reporting. Unlike Ingress, this is status reporting is done inline in the main controller, allowing status generation to be done directly in the logic processing the resources.

Additionally, Gateway involves two components writing to the cluster:

 *
 * <pre>{@code
 * Bill bill = remoteService.getLastUnpaidBill();
 *
 * // In case bug 12345 happens again we'd rather just die
 * Verify.verify(bill.status() == Status.UNPAID,
 *     "Unexpected bill status: %s", bill.status());
 * }</pre>
 *
 * <h3>Comparison to alternatives</h3>
 *
 * <p><b>Note:</b> In some cases the differences explained below can be subtle. When it's unclear

    echo "You can also try applying the patch file from the build artifacts:

git apply <(curl -sL \"${patchFile}\")
"
}

if [[ -n $(git status --porcelain) ]]; then
  git status
  git diff
  echo "ERROR: Some files need to be updated, please run 'make gen' and include any changed files in your PR"
  write_patch_file
  exit 1

}

// PodDisruptionBudgetStatus represents information about the status of a
// PodDisruptionBudget. Status may trail the actual state of a system.
message PodDisruptionBudgetStatus {
  // Most recent generation observed when updating this PDB status. DisruptionsAllowed and other
  // status information is valid only if observedGeneration equals to PDB's object generation.
  // +optional

  // you made the request against.  If empty, it is defaulted.
  optional SubjectAccessReviewSpec spec = 2;

  // Status is filled in by the server and indicates whether the request is allowed or not
  // +optional
  optional SubjectAccessReviewStatus status = 3;
}

// NonResourceAttributes includes the authorization attributes available for non-resource requests to the Authorizer interface

occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

## Status

[PROPOSED, ACCEPTED, REJECTED, DEPRECATED, REPLACED]

## Consequences

* X
* Y
* Z
```

## Status

ACCEPTED

## Consequences

* We start to use Architectural Decision Records
* We use the proposed template from this ADR

  // Spec holds information about the pod being evaluated
  optional ImageReviewSpec spec = 2;

  // Status is filled in by the backend and indicates whether the pod should be allowed.
  // +optional
  optional ImageReviewStatus status = 3;
}

// ImageReviewContainerSpec is a description of a container within the pod creation request.
message ImageReviewContainerSpec {

�EcBSize��EcIndex�EcDist�
�CSumAlgo
�PartNums�
�PartETags��PartSizes��	ը�PartASizes��	ը�Size�	ը�MTime�������MetaSys��x-minio-internal-replica-status�REPLICA�"x-minio-internal-replica-timestamp�2022-03-20T15:17:01.730949636Z�MetaUsr��content-type�application/octet-stream�x-amz-storage-class�STANDARD�X-Amz-Replication-Status�REPLICA�etag� 9587ddd31fead633830366f45d221d56�j��...

N�EcBSize��EcIndex�EcDist�
�CSumAlgo
�PartNums�
�PartETags��PartSizes��	ը�PartASizes��	ը�Size�	ը�MTime�����çMetaSys��x-minio-internal-replica-status�REPLICA�"x-minio-internal-replica-timestamp�2022-03-20T15:15:01.584169645Z�MetaUsr��content-type�application/octet-stream�x-amz-storage-class�STANDARD�X-Amz-Replication-Status�REPLICA�etag� 9587ddd31fead633830366f45d221d56�;��...

	VersionID  string `xml:"VersionId"`
}

// ObjectToDelete carries key name for the object to delete.
type ObjectToDelete struct {
	ObjectV
	// Replication status of DeleteMarker
	DeleteMarkerReplicationStatus string `xml:"DeleteMarkerReplicationStatus"`
	// Status of versioned delete (of object or DeleteMarker)
	VersionPurgeStatus VersionPurgeStatusType `xml:"VersionPurgeStatus"`
	// VersionPurgeStatuses holds the internal