@alexiiii Thanks for creating this topic.

Would you be able to point to which blueprint that you have used ?

Is it the example for logical mysql backup blueprint ?

https://raw.githubusercontent.com/kanisterio/kanister/0.108.0/examples/mysql/blueprint-v2/mysql-blueprint.yaml

Also, would you be able to let us know if you manually annotated the statefulset of mariadb with the blueprint name or did you use execution hooks while creating the policy ?

@jaiganeshjk I used this blueprint : https://raw.githubusercontent.com/kanisterio/kanister/master/examples/maria/blueprint-v2/maria-blueprint.yaml

Then I annotated the StatefulSet in the same way as described in the documentation:
kubectl --namespace mariadb annotate statefulset/maria-release \

    kanister.kasten.io/blueprint=maria-blueprint
 

And after that, I created a policy like this :
(sample profile : is a s3 location profile)

Thanks for this.
From the screenshot, I see that you have also added a hook phase to run before the snapshot during the backupaction. Is it a different blueprint that you want to run before the actual mariaDB blueprint execution ?

The error `Could not render Object reference` is coming from the hook phase that you have added in the policy. This is because the hooks run with the namespace as blueprint subject rather than the statefulset.

So any templates pointing to statefulset like ‘{{ .StatefulSet.Name }}’ would not evaluate.

Annotation that you added will execute the blueprint during backup. You don’t need to add a hook seperately in the policy. Policy Hooks are not designed to run the backup/data operations.

These are just designed to run few commands that can be used to prepare your app/db before/after backup.

If you have mistakenly added the blueprint to the before snapshot hook, Please edit the policy, remove it and then retry the policy.

Thanks for the response, it worked perfectly.
My next question is : what are these parameters for and what are their purposes?
 

Thank you for all

Hooks with blueprints are executed before or action based on how it is configured in the policy.

Data operations with the profiles are not supported in this type of blueprint execution.

These execution hooks are designed in a way that these can be used to prepare your app/db before & after the backups. You can use these hooks to do custom actions before and after the backups. For example, there can be some database commands to quiesce or unquiesce the database before and after your backup action to flush the transaction logs/WAL logs etc.

That’s the primary use case of the execution hooks. 

Please refer this documentation https://docs.kasten.io/latest/kanister/hooks.html?highlight=hooks for more details.