Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: packaging-and-versioning.md

This document surveys the various sorts of piles of things that exist in KubeStellar and how they are versioned. The picture above outlines the situation. The thing at the tail of an arrow refers to or in some way consumes from the thing at the head of the arrow. Some details omitted for brevity: the full release archives, the Kubernetes API group, and the space framework component. KubeStellar defines a Kubernetes [API group](https://kubernetes.io/docs/reference/using-api/#api-groups), named `control.kubestellar.io`. API groups are versioned; see [the Kubernetes documentation on API group versioning](https://kubernetes.io/docs/reference/using-api/#api-versioning). The Kubernetes API of KubeStellar is defined in `api/control`. The API objects form the interface between users and the controllers that implement the semantics of those objects. The syncer is KubeStellar's agent in WECs, and is based on a Kubernetes Pod that uses a container image at `quay.io/kubestellar/syncer`. This container image is built from contents of [the KubeStellar GitHub repo](https://github.com/kubestellar/kubestellar) focused by on the syncer binary. This image is normally built using the `make` target named "build-kubestellar-syncer-image. The syncer image is referenced in the output generated by the `kubectl kubestellar syncer-gen` command, which is invoked by `kubectl kubestellar prep-for-syncer`, which is invoked by `kubectl kubestellar prep-for-cluster`. The `kubectl kubestellar prep-for-syncer` script holds the default value for the tag to use in the reference to the syncer image. Following are some recent tags and what they correspond to. `v0.9.0`, for the git commit with that tag (i.e., that release). `v0.8.0`, for the git commit with that tag (i.e., that release). `pr-1103` = `git-ae64d5722-clean`, incorporating [PR 1103](https://github.com/kubestellar/kubestellar/pull/1103), the latest development in the release-0.7 line. The core container image is used in containers that run the KubeStellar core controllers , initialize the KubeStellar core, and run one of the supported space providers. It is built from some contents of [the KubeStellar GitHub repo](https://github.com/kubestellar/kubestellar), specifically excluding some that are only needed by users outside this container. This image is normally built using the `make` target "kubestellar-image". This image is referenced from the core Helm chart, which can be used directly from the Helm repo and also is used by the `kubectl kubestellar deploy` command (which has a fixed image tag in its source, which is edited when it is time to advance that tag). Following are some recent tags and what they correspond to. `release-0.9`, for the release 0.9 line of development; currently this points to the same image as `v0.9.0` but may move in the future. `v0.9.0` = `v0.9.0-alpha.1.git1f0e2cc-clean`, for the v0.9.0

This Helm chart describes a deployment of the KubeStellar core components (a space provider, KubeStellar controllers, initialization) as workload for a Kubernetes cluster. The source of this Helm chart is in the `core-helm-chart` subdirectory of the . The `kubectl kubestellar deploy` command uses the adjacent copy of this Helm chart. That is: (1) in the case of working with a local copy of the kubestellar/kubestellar GitHub repo, the copy in the `core-helm-chart` directory, and (2) in the case of using an unpacked release archive which contains `core-helm-chart` as well as `bin` that unpacked copy of `core-helm-chart`. Alternatively, users can use the Helm repository at `https://helm.kubestellar.io/`, which is served via GitHub pages from the `main` branch of [the kubestellar/helm GitHub repo](#kubestellarhelm). This repository holds tar archives of released versions of the chart, created manually from the sources in the `core-helm-chart` subdirectory of the [kubestellar GitHub repo](#kubestellarkubestellar). A Helm chart has both a version number for the chart itself and a version number for the "application" it installs. Currently there is only one version of the chart that is interesting. | Chart Version | App Version | What it is | | - | -- | - | | 1/2 (some confusion here) | v0.9.0 | KubeStellar release-0.9 branch | The repo is the main repo for KubeStellar. It holds the code and documentation and the source of the Helm chart. The following branches and tags are most interesting. branch `main` is the main line of development. branch `release-0.9` is for development along the line of the 0.9 release. tag `v0.9.0` is release 0.9.0. The GitHub repo hosts distributions of archived versions of the chart, as discussed . The GitHub repo serves directly as the homebrew repository for KubeStellar. According to homebrew convention, users refer to it in homebrew as `kubestellar/kubestellar` (e.g., `brew tap kubestellar/kubestellar` connects directly to this GitHub repository). This HomeBrew repository has two formulae. One to control the space provider and another formula called `kubestellar_cli` containing tools needed by a user who deploys the KubeStellar core as workload in a Kubernetes cluster or another user of that deployment. This formula fetches and installs a `kubestellaruser` release archive from GitHub. Users invoke the `brew` command directly to install, upgrade, and remove these formulae. Following are the versions available. `kubestellar_cli` `v0.9.0`, for that release of KubeStellar. The repo holds kubeflex, an independent component that we anticipate using as a provider for the Space framework in the future.