github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Clean up standalone conversion tool

Browse Source 
Remove kube-version-change for all its functionalities are covered
by kubectl convert command. Also changed the related docs.
This commit is contained in:
hurf
2015-10-10 09:51:09 +08:00
parent 56f72aeb45
commit 763edd3011
5 changed files with 5 additions and 159 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/admin/cluster-management.md
View File

@@ -204,13 +204,13 @@ for changes to this variable to take effect.
### Switching your config files to a new API version
You can use the `kube-version-change` utility to convert config files between different API versions.
You can use `kubectl convert` command to convert config files between different API versions.
```console
$ hack/build-go.sh cmd/kube-version-change
$ _output/local/go/bin/kube-version-change -i myPod.v1beta3.yaml -o myPod.v1.yaml
$ kubectl convert -f pod.yaml --output-version v1
```
For more options, please refer to the usage of [kubectl convert](../user-guide/kubectl/kubectl_convert.md) command.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/admin/cluster-management.md?pixel)]()

2
docs/api.md
View File

@@ -121,7 +121,7 @@ As of June 4, 2015, the Kubernetes v1 API has been enabled by default. The v1bet
### v1 conversion tips (from v1beta3)
We're working to convert all documentation and examples to v1. A simple [API conversion tool](admin/cluster-management.md#switching-your-config-files-to-a-new-api-version) has been written to simplify the translation process. Use `kubectl create --validate` in order to validate your json or yaml against our Swagger spec.
We're working to convert all documentation and examples to v1. Use `kubectl create --validate` in order to validate your json or yaml against our Swagger spec.
Changes to services are the most significant difference between v1beta3 and v1.

2
docs/devel/adding-an-APIGroup.md
View File

@@ -42,7 +42,7 @@ We plan on improving the way the types are factored in the future; see [#16062](
2. Create pkg/apis/`<group>`/{register.go, `<version>`/register.go} to register this group's API objects to the encoding/decoding scheme (e.g., [pkg/apis/extensions/register.go](../../pkg/apis/extensions/register.go) and [pkg/apis/extensions/v1beta1/register.go](../../pkg/apis/extensions/v1beta1/register.go);
3. Add a pkg/apis/`<group>`/install/install.go, which is responsible for adding the group to the `latest` package, so that other packages can access the group's meta through `latest.Group`. You probably only need to change the name of group and version in the [example](../../pkg/apis/extensions/install/install.go)). You need to import this `install` package in {pkg/master, pkg/client/unversioned, cmd/kube-version-change}/import_known_versions.go, if you want to make your group accessible to other packages in the kube-apiserver binary, binaries that uses the client package, or the kube-version-change tool.
3. Add a pkg/apis/`<group>`/install/install.go, which is responsible for adding the group to the `latest` package, so that other packages can access the group's meta through `latest.Group`. You probably only need to change the name of group and version in the [example](../../pkg/apis/extensions/install/install.go)). You need to import this `install` package in {pkg/master, pkg/client/unversioned}/import_known_versions.go, if you want to make your group accessible to other packages in the kube-apiserver binary, binaries that uses the client package.
Step 2 and 3 are mechanical, we plan on autogenerate these using the cmd/libs/go2idl/ tool.