Merge pull request #1934 from estroz/update-release-3

🌱 update release-3 for v3.0.0-alpha.1

Author: k8s-ci-robot

cmd/main.go

@@ -34,12 +34,8 @@ func main() {
 			&pluginv2.Plugin{},
 			&pluginv3.Plugin{},
 		),
-		cli.WithDefaultPlugins(config.Version2,
-			&pluginv2.Plugin{},
-		),
-		cli.WithDefaultPlugins(config.Version3Alpha,
-			&pluginv2.Plugin{},
-		),
+		cli.WithDefaultPlugins(config.Version2, &pluginv2.Plugin{}),
+		cli.WithDefaultPlugins(config.Version3Alpha, &pluginv3.Plugin{}),
 		cli.WithCompletion,
 	)
 	if err != nil {

docs/book/src/component-config-tutorial/api-changes.md

@@ -11,7 +11,7 @@ steps](/quick-start.md#installation) before continuing.
 ```bash
 # we'll use a domain of tutorial.kubebuilder.io,
 # so all API groups will be <group>.tutorial.kubebuilder.io.
-kubebuilder init --plugins=go/v3-alpha --domain tutorial.kubebuilder.io --component-config
+kubebuilder init --domain tutorial.kubebuilder.io --component-config
 ```
 
 ## Setting up an exising project

docs/book/src/cronjob-tutorial/cronjob-tutorial.md

@@ -46,7 +46,7 @@ project:
 ```bash
 # we'll use a domain of tutorial.kubebuilder.io,
 # so all API groups will be <group>.tutorial.kubebuilder.io.
-kubebuilder init --plugins=go/v3-alpha --domain tutorial.kubebuilder.io
+kubebuilder init --domain tutorial.kubebuilder.io
 ```
 
 <aside class="note">

docs/book/src/cronjob-tutorial/gvks.md

@@ -46,6 +46,24 @@ a package.
 Now that we have our terminology straight, we can *actually* create our
 API!
 
+## So, how can we create our API? 
+
+In the next section, [Adding a new API](./cronjob-tutorial/new-api.html) we will check how the tool help us to create our own API's with the command `kubebuilder create api`.
+
+The goal of this command is to create Custom Resource (CR) and Custom Resource Definition (CRD) for our Kind(s). To check it further see; [Extend the Kubernetes API with CustomResourceDefinitions][kubernetes-extend-api].
+
+## But, why create APIs at all?
+
+New APIs are how we teach Kubernetes about our custom objects. The Go structs are used to generate a Custom Resource Definition (CRD) which includes the schema for our data as well as tracking data like what our new type is called. We can then create instances of our custom objects which will be managed by our [controllers][controllers].
+
+Our APIs and resouces represent our solutions on the clusters. Basically, the CRDs are a definition of our customized Objects, and the CRs are an instance of it.
+
+## Ah, do you have an example? 
+
+Let’s think about the classic scenario where the goal is to have an application and its database running on the platform with Kubernetes. Then, one CRD could represent the App, and another one could represent the DB. By having one CRD to describe the App and another one for the DB, we will not be hurting concepts such as encapsulation, the single responsibility principle, and cohesion. Damaging these concepts could cause unexpected side effects, such as difficulty in extending, reuse, or maintenance, just to mention a few.
+
+In this way, we can create the App CRD which will have its controller and which would be responsible for things like creating Deployments that contain the App and creating Services to access it and etc. Similarly, we could create a CRD to represent the DB, and deploy a controller that would manage DB instances.
+
 ## Err, but what's that Scheme thing?
 
 The `Scheme` we saw before is simply a way to keep track of what Go type
@@ -70,3 +88,6 @@ API server that says
 
 or properly look up the group-version when we go to submit a `&CronJob{}`
 in an update.
+
+[kubernetes-extend-api]: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/
+[controllers]: ../cronjob-tutorial/controller-overview.md

docs/book/src/cronjob-tutorial/testdata/generate_cronjob.sh

@@ -52,7 +52,7 @@ function gen_cronjob_tutorial {
   mkdir project
   cd project
   header_text "creating tutorial.kubebuilder.io base  ..."
-  kubebuilder init --plugins=go/v3-alpha --domain=tutorial.kubebuilder.io --project-version=3-alpha --repo=tutorial.kubebuilder.io/project --license apache2 --owner "The Kubernetes authors"
+  kubebuilder init --domain=tutorial.kubebuilder.io --project-version=3-alpha --repo=tutorial.kubebuilder.io/project --license apache2 --owner "The Kubernetes authors"
   kubebuilder create api --group batch --version v1 --kind CronJob --resource --controller
   kubebuilder create webhook --group batch --version v1 --kind CronJob --defaulting --programmatic-validation
 }

docs/book/src/cronjob-tutorial/testdata/project/Makefile

@@ -17,7 +17,7 @@ all: manager
 ENVTEST_ASSETS_DIR=$(shell pwd)/testbin
 test: generate fmt vet manifests
 	mkdir -p ${ENVTEST_ASSETS_DIR}
-	test -f ${ENVTEST_ASSETS_DIR}/setup-envtest.sh || curl -sSLo ${ENVTEST_ASSETS_DIR}/setup-envtest.sh https://raw.githubusercontent.com/kubernetes-sigs/controller-runtime/v0.7.0-alpha.6/hack/setup-envtest.sh
+	test -f ${ENVTEST_ASSETS_DIR}/setup-envtest.sh || curl -sSLo ${ENVTEST_ASSETS_DIR}/setup-envtest.sh https://raw.githubusercontent.com/kubernetes-sigs/controller-runtime/v0.7.0/hack/setup-envtest.sh
 	source ${ENVTEST_ASSETS_DIR}/setup-envtest.sh; fetch_envtest_tools $(ENVTEST_ASSETS_DIR); setup_envtest_env $(ENVTEST_ASSETS_DIR); go test ./... -coverprofile cover.out
 
 # Build manager binary

docs/book/src/cronjob-tutorial/testdata/project/PROJECT

@@ -1,11 +1,13 @@
 domain: tutorial.kubebuilder.io
-layout: go.kubebuilder.io/v3-alpha
+layout: go.kubebuilder.io/v3
 projectName: project
 repo: tutorial.kubebuilder.io/project
 resources:
-- crdVersion: v1
+- api:
+    crdVersion: v1
   group: batch
   kind: CronJob
   version: v1
-  webhookVersion: v1
+  webhooks:
+    webhookVersion: v1
 version: 3-alpha

docs/book/src/cronjob-tutorial/testdata/project/api/v1/cronjob_types.go

@@ -62,12 +62,12 @@ the fields.
 
 // CronJobSpec defines the desired state of CronJob
 type CronJobSpec struct {
-	// +kubebuilder:validation:MinLength=0
+	//+kubebuilder:validation:MinLength=0
 
 	// The schedule in Cron format, see https://en.wikipedia.org/wiki/Cron.
 	Schedule string `json:"schedule"`
 
-	// +kubebuilder:validation:Minimum=0
+	//+kubebuilder:validation:Minimum=0
 
 	// Optional deadline in seconds for starting the job if it misses scheduled
 	// time for any reason.  Missed jobs executions will be counted as failed ones.
@@ -90,14 +90,14 @@ type CronJobSpec struct {
 	// Specifies the job that will be created when executing a CronJob.
 	JobTemplate batchv1beta1.JobTemplateSpec `json:"jobTemplate"`
 
-	// +kubebuilder:validation:Minimum=0
+	//+kubebuilder:validation:Minimum=0
 
 	// The number of successful finished jobs to retain.
 	// This is a pointer to distinguish between explicit zero and not specified.
 	// +optional
 	SuccessfulJobsHistoryLimit *int32 `json:"successfulJobsHistoryLimit,omitempty"`
 
-	// +kubebuilder:validation:Minimum=0
+	//+kubebuilder:validation:Minimum=0
 
 	// The number of failed finished jobs to retain.
 	// This is a pointer to distinguish between explicit zero and not specified.
@@ -160,8 +160,8 @@ As previously noted, we don't need to change this, except to mark that
 we want a status subresource, so that we behave like built-in kubernetes types.
 */
 
-// +kubebuilder:object:root=true
-// +kubebuilder:subresource:status
+//+kubebuilder:object:root=true
+//+kubebuilder:subresource:status
 
 // CronJob is the Schema for the cronjobs API
 type CronJob struct {
@@ -174,7 +174,7 @@ type CronJob struct {
 	Status CronJobStatus `json:"status,omitempty"`
 }
 
-// +kubebuilder:object:root=true
+//+kubebuilder:object:root=true
 
 // CronJobList contains a list of CronJob
 type CronJobList struct {
@@ -187,4 +187,4 @@ func init() {
 	SchemeBuilder.Register(&CronJob{}, &CronJobList{})
 }
 
-// +kubebuilder:docs-gen:collapse=Root Object Definitions
+//+kubebuilder:docs-gen:collapse=Root Object Definitions

docs/book/src/cronjob-tutorial/testdata/project/api/v1/cronjob_webhook.go

@@ -54,7 +54,7 @@ This marker is responsible for generating a mutating webhook manifest.
 The meaning of each marker can be found [here](/reference/markers/webhook.md).
 */
 
-// +kubebuilder:webhook:path=/mutate-batch-tutorial-kubebuilder-io-v1-cronjob,mutating=true,failurePolicy=fail,groups=batch.tutorial.kubebuilder.io,resources=cronjobs,verbs=create;update,versions=v1,name=mcronjob.kb.io
+//+kubebuilder:webhook:path=/mutate-batch-tutorial-kubebuilder-io-v1-cronjob,mutating=true,failurePolicy=fail,groups=batch.tutorial.kubebuilder.io,resources=cronjobs,verbs=create;update,versions=v1,name=mcronjob.kb.io
 
 /*
 We use the `webhook.Defaulter` interface to set defaults to our CRD.
@@ -90,7 +90,7 @@ This marker is responsible for generating a validating webhook manifest.
 */
 
 // TODO(user): change verbs to "verbs=create;update;delete" if you want to enable deletion validation.
-// +kubebuilder:webhook:verbs=create;update,path=/validate-batch-tutorial-kubebuilder-io-v1-cronjob,mutating=false,failurePolicy=fail,groups=batch.tutorial.kubebuilder.io,resources=cronjobs,versions=v1,name=vcronjob.kb.io
+//+kubebuilder:webhook:verbs=create;update,path=/validate-batch-tutorial-kubebuilder-io-v1-cronjob,mutating=false,failurePolicy=fail,groups=batch.tutorial.kubebuilder.io,resources=cronjobs,versions=v1,name=vcronjob.kb.io
 
 /*
 To validate our CRD beyond what's possible with declarative validation.

docs/book/src/cronjob-tutorial/testdata/project/api/v1/groupversion_info.go

@@ -24,8 +24,8 @@ metadata for the CRDs it creates from this package.
 */
 
 // Package v1 contains API Schema definitions for the batch v1 API group
-// +kubebuilder:object:generate=true
-// +groupName=batch.tutorial.kubebuilder.io
+//+kubebuilder:object:generate=true
+//+groupName=batch.tutorial.kubebuilder.io
 package v1
 
 import (