The Juju bundle for the Canonical Distribution of Kubernetes
Python Makefile
Latest commit 32dd222 Jan 30, 2017 @mbruzek mbruzek committed on GitHub Merge pull request #197 from juju-solutions/rye/document-manual-resou…

document manual resource installation
Failed to load latest commit information.
fragments document manual resource installation Jan 30, 2017
tests merging master Jan 13, 2017
Makefile merge master Jan 13, 2017
bundle move bundler to root Jan 13, 2017

Bundle Builder for CDK

The bundle script will allow you to build CDK bundles out of bundle fragments (found in the fragments subdirectory). Here's what building the default bundle looks like:

./bundle -o ./bundles/cdk-flannel k8s/cdk cni/flannel

This will compose the fragments into a single bundle and version them according to the given channel, which by default is stable. Additionally, a bundle will be generated by concatenating all the fragment's in the order given.



You can select a channel using the --channel or -c option. Valid options are stable, unstable, edge, and local.


./bundle -o ./bundles/core-flannel -c edge k8s/core cni/flannel

Note: for this to work, the fragment charms must be public for the given channel.

The local channel can be used to generate a bundle wherein all the charms are referenced locally. The --localpath or -l option can be used to set the path for the location of all the charms. All the charms must be located in the same path for the local channel to work. By default, --localpath is set to /home/ubuntu/builds.

Output directory

You can set the location for the resulting bundle.yaml and with the --outputdir or -o flag.


./bundle -o foo k8s/core cni/flannel

Note: bundle will not overwrite existing bundle.yaml and files. If you provide a location that contains these files, bundle will abort.

Building all the bundles

This repo includes a makefile that will produce all known bundles. The bundles will be placed in the bundles directory of the root of this repo.



The fragments directory is laid out so:

├── cni
│   └── flannel
│       ├── bundle.yaml
│       └──
├── k8s
│   ├── cdk
│   │   ├── bundle.yaml
│   │   └──
│   └── core
│       ├── bundle.yaml
│       └──
└── monitor
    └── elastic
        ├── bundle.yaml

When the user adds the k8s/cdk fragment, they're grabbing the bundle.yaml and from fragments/k8s/cdk.

Each fragment is simply a bundle with two constraints:

  • It needs to interoperate with a k8s fragment by setting up relations.
  • It must not define versions for charms.

Here's a simple example from the flannel fragment:

series: xenial
    charm: "cs:~containers/flannel"
  - - "flannel:etcd"
    - "etcd:db"
  - - "flannel:cni"
    - "kubernetes-master:cni"
  - - "flannel:cni"
    - "kubernetes-worker:cni"