You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: designs/code-generate-image-plugin.md
+22-22Lines changed: 22 additions & 22 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@
6
6
7
7
## Summary
8
8
9
-
This proposal defines a new plugin which allow users get the scaffold with the
9
+
This proposal defines a new plugin that allows users to get the scaffold with the
10
10
required code to have a project that will deploy and manage an image on the cluster following the guidelines and what have been considered as good practices.
11
11
12
12
## Motivation
@@ -18,24 +18,24 @@ The biggest part of the Kubebuilder users looking for to create a project that w
18
18
### Goals
19
19
20
20
- Add a new plugin to generate the code required to deploy and manage an image on the cluster
21
-
- Promote the best practices as give example of common implementations
22
-
- Make the process to develop operators projects easier and more agil.
21
+
- Promote the best practices by giving examples of common implementations
22
+
- Make the process of developing operator's projects easier and more agile.
23
23
- Give flexibility to the users and allow them to change the code according to their needs
24
-
- Provide examples of code implementations and of the most common features usage and reduce the learning curve
24
+
- Provide examples of code implementations and of the usage of the most common features and reduce the learning curve
25
25
26
26
### Non-Goals
27
27
28
-
The idea of this proposal is provide a facility for the users. This plugin can be improved
28
+
The idea of this proposal is to provide a facility for the users. This plugin can be improved
29
29
in the future, however, this proposal just covers the basic requirements. In this way, is a non-goal
30
-
allow extra configurations such as; scaffold the project using webhooks and the controller covered by tests.
30
+
allow extra configurations such as; scaffolding the project using webhooks and the controller covered by tests.
31
31
32
32
## Proposal
33
33
34
-
Add the new plugin code generate which will scaffold code implementation to deploy the image informed which would like such as; `kubebuilder create api --group=crew --version=v1 --image=myexample:0.0.1 --kind=App --plugins=deploy-image.go.kubebuilder.io/v1beta1` which will:
34
+
Add the new plugin code generated which will scaffold code implementation to deploy the image informed which would like such as; `kubebuilder create api --group=crew --version=v1 --image=myexample:0.0.1 --kind=App --plugins=deploy-image.go.kubebuilder.io/v1beta1` which will:
35
35
36
-
- Add a code implementation which will do the Custom Resource reconciliation and create a Deployment resource for the `--image`;
36
+
- Add a code implementation that will do the Custom Resource reconciliation and create a Deployment resource for the `--image`;
37
37
38
-
- Add an EnvVar on the manager manifest (`config/manager/manager.yaml`) which will store the image informed and shows its possibility to users:
38
+
- Add an EnvVar on the manager manifest (`config/manager/manager.yaml`) which will store the image informed and show its possibility to users:
39
39
40
40
```yaml
41
41
..
@@ -49,7 +49,7 @@ Add the new plugin code generate which will scaffold code implementation to depl
49
49
...
50
50
```
51
51
52
-
- Add a check into reconcile to ensure that the replicas of the deployment on cluster are equals the size defined in the CR:
52
+
- Add a check into reconcile to ensure that the replicas of the deployment on the cluster are equal the size defined in the CR:
53
53
54
54
```go
55
55
// Ensure the deployment size is the same as the spec
- I am as user, would like to use a command to scaffold my common need which is deploy an image of my application, so that I do not need to know exactly how to implement it
96
+
- I am a user, who would like to use a command to scaffold my common need which is to deploy an image of my application, so that I do not need to know exactly how to implement it
97
97
98
-
- I am as user, would like to have a good example code base which uses the common features, so that I can easily learn its concepts and have a good start point to address my needs.
98
+
- I am a user, would like to have a good example code base that uses the common features so that I can easily learn its concepts and have a good starting point to address my needs.
99
99
100
100
- I am as maintainer, would like to have a good example to address the common questions, so that I can easily describe how to implement the projects and/or use the common features.
101
101
@@ -251,12 +251,12 @@ type {{ resource }}Spec struct {
251
251
252
252
### Test Plan
253
253
254
-
To ensure this implementation a new project example should be generated in the [testdata](../testdata/) directory of the project. See the [test/testdata/generate.sh](../test/testadata/generate.sh). Also, we should use this scaffold in the [integration tests](../test/e2e/) to ensure that the data scaffolded with works on the cluster as expected.
254
+
To ensure this implementation a new project example should be generated in the [testdata](../testdata/) directory of the project. See the [test/testdata/generate.sh](../test/testadata/generate.sh). Also, we should use this scaffold in the [integration tests](../test/e2e/) to ensure that the data scaffold works on the cluster as expected.
255
255
256
256
### Graduation Criteria
257
257
258
-
- The new plugin will only be support `project-version=3`
259
-
- The attribute image with the value informed should be added to the resources model in the PROJECT file to let the tool know that the Resource get done with the common basic code implementation:
258
+
- The new plugin will only support `project-version=3`
259
+
- The attribute image with the value informed should be added to the resources model in the PROJECT file to let the tool know that the Resource gets done with the common basic code implementation:
260
260
261
261
```yaml
262
262
plugins:
@@ -279,22 +279,22 @@ No, at least in the first moment to keep the simplicity.
279
279
2. Should we support StatefulSet and Deployments?
280
280
The idea is we start it by using a Deployment. However, we can improve the feature in follow-ups to support more default types of scaffolds which could be like `kubebuilder create api --group=crew --version=v1 --image=myexample:0.0.1 --kind=App --plugins=deploy-image.go.kubebuilder.io/v1beta1 --type=[deployment|statefulset|webhook]`
281
281
282
-
3. Could this feature be useful to other languages or is it just valid to Gobased operators?
282
+
3. Could this feature be useful to other languages or is it just valid to Go-based operators?
283
283
284
284
This plugin would is reponsable to scaffold content and files for Go-based operators. In a future, if other language-based operators starts to be supported (either officially or by the community) this plugin could be used as reference to create an equivalent one for their languages. Therefore, it should probably not to be a `subdomain` of `go.kubebuilder.io.`
285
285
286
-
For its integration with SDK, it might be valid for the Ansible-based operators where a new `playbook/role` could be generated as well. However, for example,for the Helm plugin it might to be useless. E.g `deploy-image.ansible.sdk.operatorframework.io/v1beta1`
286
+
For its integration with SDK, it might be valid for the Ansible-based operators where a new `playbook/role` could be generated as well. However, for example,for the Helm plugin, it might be useless. E.g `deploy-image.ansible.sdk.operatorframework.io/v1beta1`
287
287
288
-
4. Should we consider create a separate repo for plugins?
288
+
4. Should we consider creating a separate repo for plugins?
289
289
290
-
In the long term yes. However, see that currently, Kubebuilder has not too many plugins yet. And then, and the preliminary support for plugins did not indeed release. For more info see the [Extensible CLI and Scaffolding Plugins][plugins-phase1-design-doc].
290
+
In the long term yes. However, see that currently, Kubebuilder does not have too many plugins yet. And then, the preliminary support for plugins was not indeed released. For more info see the [Extensible CLI and Scaffolding Plugins][plugins-phase1-design-doc].
291
291
292
292
In this way, at this moment, it shows to be a little Premature Optimization. Note that the issue [#2016](https://github.com/kubernetes-sigs/kubebuilder/issues/1378) will check the possibility of the plugins be as separate binaries that can be discovered by the Kubebuilder CLI binary via user-specified plugin file paths. Then, the discussion over the best approach to dealing with many plugins and if they should or not leave in the Kubebuilder repository would be better addressed after that.
293
293
294
294
5. Is Kubebuilder prepared to receive this implementation already?
295
295
296
-
The [Extensible CLI and Scaffolding Plugins - Phase 1.5](extensible-cli-and-scaffolding-plugins-phase-1-5.md) and the issue #1941 requires to be implemented before this proposal. Also, to have a better idea over the proposed solutions made so for the Plugin Ecosystem see the meta issue [#2016](https://github.com/kubernetes-sigs/kubebuilder/issues/2016)
296
+
The [Extensible CLI and Scaffolding Plugins - Phase 1.5](extensible-cli-and-scaffolding-plugins-phase-1-5.md) and issue #1941 are required to be implemented before this proposal. Also, to have a better idea of the proposed solutions made so for the Plugin Ecosystem see the meta issue [#2016](https://github.com/kubernetes-sigs/kubebuilder/issues/2016)
Copy file name to clipboardExpand all lines: docs/book/src/cronjob-tutorial/gvks.md
+4-4Lines changed: 4 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Groups and Versions and Kinds, oh my!
2
2
3
-
Actually, before we get started with our API, we should talk terminology
3
+
Before we get started with our API, we should talk about terminology
4
4
a bit.
5
5
6
6
When we talk about APIs in Kubernetes, we often use 4 terms: *groups*,
@@ -38,7 +38,7 @@ lowercase form of the Kind.
38
38
39
39
## So, how does that correspond to Go?
40
40
41
-
When we refer to a kind in a particular group-version, we'll call it
41
+
When we refer to a kind in a particular groupversion, we'll call it
42
42
a *GroupVersionKind*, or GVK for short. Same with resources and GVR. As
43
43
we'll see shortly, each GVK corresponds to a given root Go type in
44
44
a package.
@@ -51,7 +51,7 @@ API!
51
51
In the next section, [Adding a new API](../cronjob-tutorial/new-api.html), we will check how the tool helps us to
52
52
create our own APIs with the command `kubebuilder create api`.
53
53
54
-
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].
54
+
The goal of this command is to create a 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].
55
55
56
56
## But, why create APIs at all?
57
57
@@ -87,7 +87,7 @@ API server that says
87
87
}
88
88
```
89
89
90
-
or properly look up the group-version when we go to submit a `&CronJob{}`
90
+
or properly look up the groupversion when we go to submit a `&CronJob{}`
0 commit comments