+
+## Additional Operations Supported by the Plugin
+In addition to supporting the Cloudify `install` and `uninstall` workflows, the plugin provides two standalone operations that can be invoked using the Cloudify [`execute_operation` workflow](https://docs.cloudify.co/4.3.0/working_with/workflows/built-in-workflows/). The `dcae.nodes.ContainerizedApplication`, `dcae.nodes.ContainerizedPlatformComponent`, `dcae.nodes.ContainerizedServiceComponent`, and `dcae.nodes.ContainerizedServiceComponentUsingDmaap` node types support these operations.
+
+Currently, there's no convenient high-level interface to trigger these operations, but they could potentially be exposed through some kind of dashboard.
+
+### Scaling Operation (`scale`)
+The `scale` operation provides a way to change the number of replicas running for a node instance. The operation is implemented by modifying the number of replicas in the Kubernetes Deployment specification associated with a node instance and submitting the updated specification to the Kubernetes API. The scale operation works for increasing the number of replicas as well as decreasing the number of replications. The minimum number of replicas is 1.
+
+The `scale` operation takes two parameters:
+- `replicas`: Number of desired replicas. Integer, required.
+- `max_wait`: Number of seconds to wait for successful completion of the operation. Integer, optional, defaults to 300 seconds.
+
+One way to trigger a `scale` operation is by using the Cloudify command line. For example:
+```
+cfy executions start -d my_deployment -p scale_params.yaml execute_operation
+```
+where `my_deployment` is the name of an existing Cloudify deployment and
+`scale_params.yaml` is a a file containing the operation parameters:
+```
+operation: scale
+operation_kwargs:
+ replicas: 3
+node_ids:
+ - "web_server"
+```
+Note that the `node_ids` list is required by the `execute_operation` workflow. The list contains all of the nodes that are being targeted by the workflow. If a blueprint contains more than one node, it's possible to scale all of them--or some subset--with a single workflow execution.
+
+### Image Update Operation (`image_update`)
+The `update_image` operation provides a way to change the Docker image running for a node instance, using the Kubernetes _rolling update_ strategy. (See this [tutorial](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/) and this [discussion of the concept](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) in the Kubernetes documentation.) The operation is implemented by modifying the image property in the Kubernetes Deployment specification associated with a node instance and submitting the updated specification to the Kubernetes API.
+
+The `update_image` operation takes two parameters:
+- `image`: Full name (including registry, if not the default Docker registry, and tag) of the new image to use for the component. String, required.
+- `max_wait`: Number of seconds to wait for successful completion of the operation. Integer, optional, defaults to 300 seconds.
+
+The `update_image` operation can be triggered using the Cloudify command line. For example:
+```
+cfy executions start -d my_deployment -p update_params.yaml execute_operation
+```
+where `my_deployment` is the name of an existing Cloudify deployment and
+`update_params.yaml` is a a file containing the operation parameters:
+```
+operation: update_image
+operation_kwargs:
+ image: myrepository.example.com/server/web:1.15
+node_ids:
+ - "web_server"
+```
+Note that the `node_ids` list is required by the `execute_operation` workflow. The list contains all of the nodes that are being targeted by the workflow. For an `update_image` operation, the list typically has only one element.
+
+Note also that the `update_image` operation targets the container running the application code (i.e., the container running the image specified in the `image` node property). This plugin may deploy "sidecar" containers running supporting code--for example, the "filebeat" container that relays logs to the central log server. The `update_image` operation does not touch any "sidecar" containers.
\ No newline at end of file