kustomize/pseudo

Pseudo k8s

The module defined below in pseudo/k8s contains code generated by the init-pseudo-module.sh script.

The module contains clones (see the script for the specific clone tag) of code from the following repositories:

• kubernetes/api
• kubernetes/apimachinery
• kubernetes/client-go

These repositories are in turn snapshots of code being developed in kubernetes staging.

Why?

In what follows, let the word apimachinery generally represent one of more of the modules kubernetes/api, kubernetes/apimachinery, kubernetes/client-go.

• kubectl depends on apimachinery in the k/k repo via a go.mod replacement.

• kubectl must depend the on kustomize API module.

• apimachinery doesn’t yet do releases distinguished by major version number. I.e., one cannot write a go.mod file containing the lines

  require k8s.io/apimachinery    v1.1.4
  require k8s.io/apimachinery/v2 v2.1.0
  require k8s.io/apimachinery/v3 v3.2.1
  

  The only option at this time are pseudo-versions of the form v0.0.0-20181127025237-2b1284ed4c93 and everything in the k/k repo must depend on exactly one pseudo version, which is typically a v.0.0.0 with a replace directive specifying an in-repo relative path.

• kustomize depends on apimachinery.

This creates a problem, since kubectl and kustomize have no means to declare a dependence on different versions of apimachinery, and no means to sync on the same version since kubectl and kustomize live in different repositories.

A solution to this is a manual vendor: either the kustomize API module source code must be manually snapshotted into the k/k repo at some invented path that could never be confused with a normal module import path, or the apimachinery module (and friends) must be snapshotted into the kustomize repo using the same notion of import path replacement.

This module is the result of taking the latter option. kustomize can depend on this snapshot of apimachinery, and both can be vendored into the k/k repo safely.

Caveats

This pseudo k8s module may be removed at anytime in the future without warning and no support will be given for these modules. It's best to try to encourage semver development in apimachinery directly.

How was this module made?

These libraries were forked by running git clone to clone the repos.

Automated Creation Steps

1. Remove the current existing pseudo modules

• $ rm -rf pseudo/k8s

2. Run the init-pseudo-module.sh script to clone and configure pseudo deps

• From the root directory -- $ pseudo/init-pseudo-module.sh