github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
604dfb3197
kubernetes/federation
History
Kubernetes Submit Queue cce1c9b41e Merge pull request #49192 from mfojtik/unify-clientgen-tags 
Automatic merge from submit-queue (batch tested with PRs 49498, 49192)

Unify genclient tags and add more fine control on verbs generated

This will change the syntax of the existing `genclient` tags be like this:

```
// +genclient
// +genclient:noStatus
// +genclient:noVerbs
// +genclient:nonNamespaced
// +genclient:readonly
```

The first one indicates the client will be generated from the struct below and the other tags are basically options to the genclient (which justify why they should be prefixed with `genclient:`)

This also changes the `// +genclientstatus=false` to `// +genclient:noStatus` to follow the pattern and also changes the `// +noMethods=true` to `// +genclient:noVerbs` as we call the REST operations verbs so it will make it consistent with terminology.

In addition to existing options this patch also add two more to allow more fine-grained control on which verbs are going to be generated. This is extra useful for third-party projects (like OpenShift) where some resources does not implement full CRUD, but for example just "create" verb or "create" and "delete"...
To support that, you can use this syntax:

```
// +genclient:onlyVerbs=create,delete
// +genclient:skipVerbs=patch
```

The first one will generate only create and delete functions and second one will generate full CRUD without "patch" actions. This somehow overlaps with the existing "readonly" tag, but I want to keep that tag in place as it reads better in some cases ;-)
2017-07-25 02:43:13 -07:00
..
apis Merge pull request #49192 from mfojtik/unify-clientgen-tags 2017-07-25 02:43:13 -07:00
client regenerate clients 2017-07-24 22:35:19 +02:00
cluster [Federation] Handle federation up timeouts 2017-07-14 11:47:22 -07:00
cmd expose RegisterAllAdmissionPlugins so that admission chains can be built reused 2017-07-18 13:30:06 -04:00
deploy Update charts image version. 2016-10-12 00:15:01 -07:00
develop Revert "[Federation] Build a simple hyperkube image on-the-fly only containing the hyperkube binary for development and testing purposes." 2017-04-24 22:26:20 -07:00
docs/api-reference Update swagger and OpenAPI spec 2017-07-24 17:28:29 -07:00
manifests Release 3.0.17 etcd image 2017-02-27 16:23:44 +01:00
pkg Merge pull request #48200 from irfanurrehman/fed-sched-generic-args 2017-07-19 01:57:27 -07:00
plugin/pkg/admission/schedulingpolicy [Federation]Fix forgeting to close file 2017-06-24 10:04:06 +08:00
registry/cluster Grow signature for predicate attributes to include init status 2017-06-02 22:09:04 -04:00
BUILD federation: Add admission controller for policy-based placement 2017-06-05 07:58:59 -07:00
Makefile
OWNERS fed: Add marun as reviewer 2017-02-09 09:50:57 -08:00
README.md federation:update outdated link 2017-05-08 09:07:40 +08:00

README.md

Cluster Federation

Kubernetes Cluster Federation enables users to federate multiple Kubernetes clusters. Please see the user guide and the admin guide for more details about setting up and using the Cluster Federation.

Building Kubernetes Cluster Federation

Please see the Kubernetes Development Guide for initial setup. Once you have the development environment setup as explained in that guide, you also need to install jq

Building cluster federation artifacts should be as simple as running:

make build

You can specify the docker registry to tag the image using the KUBE_REGISTRY environment variable. Please make sure that you use the same value in all the subsequent commands.

To push the built docker images to the registry, run:

make push

To initialize the deployment run:

(This pulls the installer images)

make init

To deploy the clusters and install the federation components, edit the ${KUBE_ROOT}/_output/federation/config.json file to describe your clusters and run:

make deploy

To turn down the federation components and tear down the clusters run:

make destroy

Ideas for improvement

  1. Continue with destroy phase even in the face of errors.

    The bash script sets set -e errexit which causes the script to exit at the very first error. This should be the default mode for deploying components but not for destroying/cleanup.

Analytics