Some questions about Wordpress example

[devdattakulkarni]

This seems like a cool project.

With regards to Wordpress example, I had some questions.

1. In the README for the wordpress example, I did not find where the Custom Resource (WordpressAPI) available in sample directory is being created/used.

2. The methods in wordpress_manager.py take input_data/spec as input parameter. Where is it being passed in? In Dockerfile's ENTRYPOINT I did not find any argument being passed into the python command.

3. Similarly, where is the action_type passed in to the python command?

4. The kubectl binary is being packaged within the Operator's container image. How/where is it being given the credentials to access the API server? Note that in typical Golang based implementation of Operators such in-cluster creds/config is available through client-go library.

[vnzongzna]

1. When we do craft create CRAFT creates a directory in $GOPATH/src by taking the name from controller.json. In that directory, you'll find the actual code of the operator's CRD & controller. All behind the scene we are creating the docker image of the whole operator & just making the manifest of the operator in the example directory for the user to apply in any k8s cluster.
2. wordpress_manager.py is expecting those parameters from the Operator's controller. Given which CRUD operation is required based on exit codes it will use the input_parameter

[maheswarasunil]

While we are working on the improvements in CRAFT documentation to address the questions let me add few more details.

1. Let me point out commands in README where CRDs are creation and deployed. As @vnzongzna pointed out custom resource creation and its operator docker image is generated with command.
   craft create -c config/controller.json -r config/resource.json --podDockerFile resource/DockerFile -p
   This generated image can be deployed using operator.yaml
   kubectl apply -f config/deploy/operator.yaml
   We will update our docs with more details of craft create.

2. and 3. Both the input_data/spec and action_type are passed as args at pod spec. Operator deploys a pod for each execution of action_type (create/update/delete/verify), below is the function where args is initialized for the pod spec and pod deploy is executed.

   craft/_base-operator/reconciler/reconcile_runner.go

   Line 672 in c2dd7e8

   func (r *ReconcileRunner) spawnPod(event string, podInputSpec PodSpec) ({{ .Resource }}{{ .Version }}.Pod, error) {

   .
   For Wordpress operator wordpress_manager.py reads those args which are passed by pod specs.

3. I agree we can also use the client-go library instead of kubectl binary in Wordpress example. For kubectl also using the default service account available credentials in the pod itself. Just like client-go kubectl default to that service account and we are not specifically configuring any other credentials. https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod

[devdattakulkarni]

Thanks @vnzongzna and @maheswarasunil for the details.

For 2 and 3, interesting to note that the Operator is deploying a Pod for each action. So essentially, for every CRUD operation executed by the user, the Operator creates a new Pod with the appropriate action type captured in its Spec. Is this correct understanding?

[maheswarasunil]

Yes @devdattakulkarni. That is correct. Adding to that the reconciliation flow of the operator will be based on the docker exit codes (wordpress_manager.py for WordPress operator) of the new pod created per action type.

https://opensource.salesforce.com/craft/tutorial/docker_exit_codes.html

[prakashrj]

@devdattakulkarni Every CRUD operation is a docker entry point call, and you will incur little extra cost that docker as a isolation wrapper will bring in. You can also change reconciliation frequency controlling how often a resource should be checked to bring into a desired state.