README: add create and deploy section#14
README: add create and deploy section#14hongchaodeng merged 1 commit intooperator-framework:masterfrom hongchaodeng:d
Conversation
|
|
||
| ## Up and running | ||
|
|
||
| At this step we actually have a functional operator already. To see it, first build the binary and container: |
There was a problem hiding this comment.
Maybe reword to something like:
At this point we are ready to build and deploy a functional operator. First build the binary and container image:
| Kubernetes deployment files will be generated under `deploy/play-operator`. Deploy operator to Kubernetes: | ||
|
|
||
| ``` | ||
| kubectl create -f deploy/play-operator/ |
There was a problem hiding this comment.
kubectl create -f deploy/play-operator/deployment.yaml?
I think about creating three files under deploy/play-operator/
crd.yaml : crd for PlayService
deployment.yaml : file for create play-operator
example_play.yaml : an example CR for PlayService
There was a problem hiding this comment.
crd.yaml and deployment.yaml files are needed and should be created together. That's why we -f the entire dir.
The example CR would better be in another directory since it is not related to operator deployment.
There was a problem hiding this comment.
maybe I am missing something. I assume that all deployment related stuff is under deploy/play-operator/ like the example/ we have for vault and etcd-operator.
There was a problem hiding this comment.
The deployment related stuff is about deploying the operator only.
For the vault and operators, we'd better organize them separately.
There was a problem hiding this comment.
that's fine with me. we can leave out the example_play.yaml for now. and get back to it later.
There was a problem hiding this comment.
Creating one file will be easier for distribution, but harder if you want to introspect or change the objects. What do you guys think we should do?
There was a problem hiding this comment.
Yeah. I think in one file is better. Let's make it operator.yaml.
Eventually, we will capture those deployment lifecycles in the sdk tool.
| kind: "PlayService" | ||
| metadata: | ||
| name: "example" | ||
| spec: |
There was a problem hiding this comment.
maybe no spec section? since we haven't defined any spec.
There was a problem hiding this comment.
since we haven't defined any spec.
Can you make the default spec have a field replica?
| replica: 1 | ||
| ``` | ||
|
|
||
| Once the CR is created, a new pod `example-box` will be created: |
There was a problem hiding this comment.
maybe mentioning ngix pod? if that's we are aiming for. I am fine with the current one.
There was a problem hiding this comment.
Nginx, or busy loop, or just sleep.
Maybe modify this again once we have the implementation?
There was a problem hiding this comment.
kk, maybe add a TODO so we don't forget?
There was a problem hiding this comment.
This is minor detail.
Let's not add a TODO in README.
| example-box 2/2 Running 0 6d | ||
| ``` | ||
|
|
||
| This is a basic test that verifies everything works correctly. Next we are going to write business logic and do something more interesting. |
There was a problem hiding this comment.
write business -> write the business
|
lgtm |
|
@robszumski @hasbro17 PTAL |
|
LGTM |
4 participants
No description provided.