Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: adds expectations with regards to pulling using OCI #5307

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions docs/architecture/adr-001-autopilot-oci-basic-auth-support.md
Original file line number Diff line number Diff line change
Expand Up @@ -110,6 +110,39 @@ secretRef:
name: artifacts-token-based-auth
```

#### Expected workflow

This feature supports pulling both the k0s binary and the k0s air-gap bundle.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Downloading executables raises the question of how to manage the executable bit of the downloaded files.

Each repository tag should host only one artifact. To remotely host an artifact
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should happen if there are multiple artifacts?

and later retrieve it using this feature, the following command is sufficient:

```sh
oras push <registry-address>/<namespace>/<repository>:<tag> <artifact path>
```

For example, to push the k0s binary and its corresponding airgap bundle, use
the following commands:

```sh
# pushing the k0s binary.
oras push registry.company.com/k0s/binary:v1.31.1 k0s

# pushing the k0s airgap bundle.
oras push registry.company.com/k0s/bundle:v1.31.1 k0s-airgap-bundle
```

Once the artifacts are hosted in the OCI registry, the following configuration
is sufficient to enable the pull through OCI:

```yaml
url: oci://registry.company.com/k0s/binary:v1.31.1
sha256: <sha-for-the-binary>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Big question: Is this the digest of the image or the digest of the embedded binary?

When dealing with OCI artifacts, it would seem more natural to be the digest of the image (or image index) itself.

If it is the latter, this means that as long as the published artifact also uses SHA-256 as its digest algorithm (I have yet to see an image that doesn't), we would have an accurate way of figuring out which artifact to pick out of the image index. The downside would be that this would make multi-platform downloads with the same name impossible.

secretRef:
# if auth is required to pull the artifact.
namespace: kube-system
name: artifacts-registry
```

### Secrets Layout

The following standard Kubernetes secret types are supported:
Expand Down
Loading