chore: update import paths

Signed-off-by: Andrew Rynhard <[email protected]>

Author: andrewrynhard

Documentation/alpha-features.md

@@ -15,5 +15,5 @@ This alpha annotation will retain the endpoints even if the etcd pod isn't ready
 This feature is always enabled in endpoint controller in k8s even it is alpha.
 
 References:
-- https://github.com/kubernetes-incubator/bootkube/issues/599
-- https://github.com/kubernetes-incubator/bootkube/pull/626#issuecomment-313187659
+- https://github.com/kubernetes-sigs/bootkube/issues/599
+- https://github.com/kubernetes-sigs/bootkube/pull/626#issuecomment-313187659

Documentation/development.md

@@ -9,8 +9,8 @@
 First, clone the repo into the proper location in your [`GOPATH`][GOPATH]:
 
 ```
-go get -u github.com/kubernetes-incubator/bootkube
-cd $(go env GOPATH | cut -d: -f1)/src/github.com/kubernetes-incubator/bootkube
+go get -u github.com/kubernetes-sigs/bootkube
+cd $(go env GOPATH | cut -d: -f1)/src/github.com/kubernetes-sigs/bootkube
 ```
 
 Then build:

Documentation/disaster-recovery.md

@@ -11,7 +11,7 @@ failure scenarios:
 To minimize the likelihood of any of the these scenarios, production
 self-hosted clusters should always run in a high-availability configuration
 (**TODO:** [add documentation for running high-availability self-hosted
-clusters](https://github.com/kubernetes-incubator/bootkube/issues/311)).
+clusters](https://github.com/kubernetes-sigs/bootkube/issues/311)).
 
 Nevertheless, in the event of a control plane loss the bootkube project
 provides limited disaster avoidance and recovery support through the
@@ -39,7 +39,7 @@ render` to create cluster manifests. Using the Pod Checkpointer is highly
 recommended for all self-hosted clusters to ensure node reboot resiliency.
 
 For more information, see the [Pod Checkpointer
-README](https://github.com/kubernetes-incubator/bootkube/blob/master/cmd/checkpoint/README.md).
+README](https://github.com/kubernetes-sigs/bootkube/blob/master/cmd/checkpoint/README.md).
 
 ## Bootkube Recover
 
@@ -85,7 +85,7 @@ automatically tear down the recovery control plane.
 
 For best results always use the most recently tagged Bootkube release when using `recover`,
 regardless of which release was used to create the cluster. To see the available releases,
-checkout [the tagged binary releases on GitHub](https://github.com/kubernetes-incubator/bootkube/releases)
+checkout [the tagged binary releases on GitHub](https://github.com/kubernetes-sigs/bootkube/releases)
 or [the tagged Docker images on Quay.io](https://quay.io/repository/coreos/bootkube).
 
 To see available options, run:
@@ -116,7 +116,7 @@ attempt to recreate self-hosted assets; it only runs a temporary control plane
 to allow the self-hosted control plane to recover itself.
 
 For complete recovery examples see the
-[hack/multi-node/bootkube-test-recovery](https://github.com/kubernetes-incubator/bootkube/blob/master/hack/multi-node/bootkube-test-recovery)
+[hack/multi-node/bootkube-test-recovery](https://github.com/kubernetes-sigs/bootkube/blob/master/hack/multi-node/bootkube-test-recovery)
 and
 
 [![asciicast](https://asciinema.org/a/dsp43ziuuzwcztni94y8l25s5.png)](https://asciinema.org/a/dsp43ziuuzwcztni94y8l25s5)

Documentation/upgrading.md

@@ -14,8 +14,8 @@ Before beginning an upgrade, it is recommended you evaluate if an in-place upgra
 
 Find the diff between bootkube assets generated for the existing cluster version and the desired version. This depends on the tool used to generate assets:
 
-* Github [compare](https://github.com/kubernetes-incubator/bootkube/compare/v0.5.0...v0.5.1) changes between the existing and desired versions and infer the appropriate cluster changes.
-* [bootkube render](https://github.com/kubernetes-incubator/bootkube) - Install the `bootkube` binaries for the existing and desired versions. Render assets to different locations with each binary and diff the assets.
+* Github [compare](https://github.com/kubernetes-sigs/bootkube/compare/v0.5.0...v0.5.1) changes between the existing and desired versions and infer the appropriate cluster changes.
+* [bootkube render](https://github.com/kubernetes-sigs/bootkube) - Install the `bootkube` binaries for the existing and desired versions. Render assets to different locations with each binary and diff the assets.
 * [External Tools](users-integrations.md) - Check the docs for the external tool and compare assets generated for each version.
 
 In simple cases, you may only need to bump the version of a few images. In more complex cases, there may be entirely new components, configuration, or flags.

Makefile

@@ -5,7 +5,7 @@ export PATH:=$(PATH):$(PWD)
 LOCAL_OS:=$(shell uname | tr A-Z a-z)
 GOFILES:=$(shell find . -name '*.go' ! -path './vendor/*')
 VENDOR_GOFILES ?= $(shell find vendor -name '*.go')
-LDFLAGS=-X github.com/kubernetes-incubator/bootkube/pkg/version.Version=$(shell $(CURDIR)/build/git-version.sh)
+LDFLAGS=-X github.com/kubernetes-sigs/bootkube/pkg/version.Version=$(shell $(CURDIR)/build/git-version.sh)
 TERRAFORM:=$(shell command -v terraform 2> /dev/null)
 
 all: \
@@ -48,7 +48,7 @@ _output/bin/%: GOARCH=$(word 2, $(subst /, ,$*))
 _output/bin/%: GOARCH:=amd64  # default to amd64 to support release scripts
 _output/bin/%: $(GOFILES) $(VENDOR_GOFILES)
 	mkdir -p $(dir $@)
-	GOOS=$(GOOS) GOARCH=$(GOARCH) go build $(GOFLAGS) -ldflags "$(LDFLAGS)" -o $@ github.com/kubernetes-incubator/bootkube/cmd/$(notdir $@)
+	GOOS=$(GOOS) GOARCH=$(GOARCH) go build $(GOFLAGS) -ldflags "$(LDFLAGS)" -o $@ github.com/kubernetes-sigs/bootkube/cmd/$(notdir $@)
 
 _output/release/bootkube.tar.gz: _output/bin/linux/bootkube _output/bin/darwin/bootkube _output/bin/linux/checkpoint
 	mkdir -p $(dir $@)

README.md

@@ -1,8 +1,8 @@
-# Bootkube  
+# Bootkube
 
 [![Build Status](https://travis-ci.org/kubernetes-incubator/bootkube.svg?branch=master)](https://travis-ci.org/kubernetes-incubator/bootkube)
-[![GoDoc](https://godoc.org/github.com/kubernetes-incubator/bootkube?status.svg)](https://godoc.org/github.com/kubernetes-incubator/bootkube)
-[![Go Report Card](https://goreportcard.com/badge/github.com/kubernetes-incubator/bootkube)](https://goreportcard.com/report/github.com/kubernetes-incubator/bootkube)
+[![GoDoc](https://godoc.org/github.com/kubernetes-sigs/bootkube?status.svg)](https://godoc.org/github.com/kubernetes-sigs/bootkube)
+[![Go Report Card](https://goreportcard.com/badge/github.com/kubernetes-sigs/bootkube)](https://goreportcard.com/report/github.com/kubernetes-sigs/bootkube)
 
 Bootkube is a tool for launching self-hosted Kubernetes clusters.
 
@@ -12,16 +12,16 @@ Additionally, bootkube can be used to generate all of the necessary assets for u
 
 ## Details of self-hosting
 
-* [KubeCon self-hosted presentation video](https://www.youtube.com/watch?v=EbNxGK9MwN4)
-* [Kubernetes self-hosted design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/self-hosted-kubernetes.md)
+- [KubeCon self-hosted presentation video](https://www.youtube.com/watch?v=EbNxGK9MwN4)
+- [Kubernetes self-hosted design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/self-hosted-kubernetes.md)
 
 ## Guides
 
-* [GCE Quickstart](hack/quickstart/quickstart-gce.md)
-* [AWS Quickstart](hack/quickstart/quickstart-aws.md)
-* [Bare-Metal](https://github.com/coreos/matchbox/tree/master/examples/terraform/bootkube-install)
-* [Vagrant Single-Node](hack/single-node/README.md)
-* [Vagrant Multi-Node](hack/multi-node/README.md)
+- [GCE Quickstart](hack/quickstart/quickstart-gce.md)
+- [AWS Quickstart](hack/quickstart/quickstart-aws.md)
+- [Bare-Metal](https://github.com/coreos/matchbox/tree/master/examples/terraform/bootkube-install)
+- [Vagrant Single-Node](hack/single-node/README.md)
+- [Vagrant Multi-Node](hack/multi-node/README.md)
 
 ## Usage
 
@@ -64,6 +64,7 @@ bootkube start --asset-dir=my-cluster
 ```
 
 When `bootkube start` is creating Kubernetes resources from manifests, the following order is used:
+
 1. Any `Namespace` objects are created, in lexicographical order.
 1. Any `CustomResourceDefinition` objects are created, in lexicographical order.
 1. Any remaining resources are created, in lexicographical order.
@@ -86,7 +87,7 @@ You can find us at the `#bootkube` channel on [Kubernetes slack][slack].
 
 ## Related Links
 
-* [Users and Integrations](Documentation/users-integrations.md)
+- [Users and Integrations](Documentation/users-integrations.md)
 
 ## License
 

RELEASING.md

@@ -32,15 +32,16 @@ Eventually we might want to consider moving the checkpointer to its own repo. Th
 However, this should also be balanced against the longer-term goal, which would be that checkpointing is natively supported in the kubelet.
 
 For some past discussions related to these topics, see:
+
 - https://github.com/kubernetes/kubeadm/issues/131
 - https://github.com/kubernetes/kubernetes/issues/489
-- https://github.com/kubernetes-incubator/bootkube/issues/424
+- https://github.com/kubernetes-sigs/bootkube/issues/424
 
 ## Updating Kubernetes Version
 
 ### Updating Kubernetes vendor code
 
-Vendoring currently relies on the [dep](https://github.com/golang/dep) tool. 
+Vendoring currently relies on the [dep](https://github.com/golang/dep) tool.
 
 - Update pinned versions in `Gopkg.toml`
 - Run `make vendor`
@@ -50,14 +51,14 @@ Note that we require all dependencies be recorded `Gopkg.toml`, even transitive
 ### Updating hyperkube image / Kubernetes version
 
 - Update hyperkube image for manifests in templates:
-    - `pkg/asset/internal/templates.go`
+  - `pkg/asset/internal/templates.go`
 - Update conformance test version: (`CONFORMANCE_VERSION`)
-    -  `hack/tests/conformance-test.sh`
+  - `hack/tests/conformance-test.sh`
 - Update on-host kubelet versions (`KUBELET_IMAGE_TAG`)
-    - `hack/multi-node/user-data.sample`
-    - `hack/single-node/user-data.sample`
-    - `hack/quickstart/kubelet.master`
-    - `hack/quickstart/kubelet.worker`
+  - `hack/multi-node/user-data.sample`
+  - `hack/single-node/user-data.sample`
+  - `hack/quickstart/kubelet.master`
+  - `hack/quickstart/kubelet.worker`
 
 ## Run conformance test
 
@@ -121,4 +122,3 @@ BUILD_IMAGE=checkpoint PUSH_IMAGE=true ./build/build-image.sh
 In `pkg/asset/images.go` change:
 
 `PodCheckpointer` in `DefaultImages` to use the image built in previous step.
-

ROADMAP.md

@@ -2,11 +2,11 @@
 
 ## v1.0.0 targets
 
-- [ ] Recovery from etcd-backup part of e2e testing (https://github.com/kubernetes-incubator/bootkube/issues/596)
+- [ ] Recovery from etcd-backup part of e2e testing (https://github.com/kubernetes-sigs/bootkube/issues/596)
 - [ ] Publicly published upstream conformance tests
 - [ ] How-it-works documentation for bootkube
-- [ ] Documentation for running HA clusters (https://github.com/kubernetes-incubator/bootkube/issues/311)
-- [ ] Versioned configuration objects replace flags (https://github.com/kubernetes-incubator/bootkube/issues/565)
+- [ ] Documentation for running HA clusters (https://github.com/kubernetes-sigs/bootkube/issues/311)
+- [ ] Versioned configuration objects replace flags (https://github.com/kubernetes-sigs/bootkube/issues/565)
 
 ## Upstream Features (as available)