Solved

Blueprint from the K10 website documentation


Userlevel 7
Badge +22

Hi

I spun up the example used on the K10 documentation page for Postgresql Application Consistent backup but it looks like that blueprint no longer works. https://docs.kasten.io/latest/kanister/postgresql/install_app_cons.html

On quick inspection I see this error: 

message: Failed to create pre-backup Kanister phase
- cause:
cause:
message: "Failed to exec command in pod: container postgres-postgresql is not
valid for pod postgres-postgresql-0"

but the container deployed by that chart is in fact named postgresql

container name

I have not done a lot with Blueprints yet so will want to dig deeper but I assume my next step is to change this part of the blueprint to represent the right container name? 

I have also attached the logs.

 

 

icon

Best answer by FRubens 27 April 2023, 09:27

View original

11 comments

Userlevel 7
Badge +22

 

@jaiganeshjk Please disregard this post now.

 

 

 

Userlevel 4
Badge +2

Hello @Geoff Burke,

Could you please try this Logical PostgreSQL backup:

https://docs.kasten.io/latest/kanister/postgresql/install_logical.html

I have tested the link you are using, and indeed the blueprint is not working, the container parameter can even be removed, but the problem is that the  functions used in the psql commands in that blueprint probably were deprecated. 

We will have to update the blueprint to fix the issues, and also to work with latest versions of PostgreSQL (15), I will raise this internally to get this updated.
 

Userlevel 7
Badge +22

Hi @FRubens 

Thanks in fact I changed the name and it did not solve the problem. I exec into the container and was having issues with the commands themselves so guessed something might have changed but not being a postgres expert was not sure that I was correct. 

 

cheers

Userlevel 7
Badge +22

Hi the Mongodb app aware example has issues as well as that version number 9.0.0 is no longer available

https://docs.kasten.io/latest/kanister/mongodb/install_app_cons.html

I am not trying to be picky but I sometimes tell potential customers to go and try it themselves as there are easy examples on the Kasten-io Documentation site so as you can imagine they come back to me thinking they did something wrong.

 

 

I tried without setting a version just for fun but most likely stuff has changed and been deprecated here as well

 "Failed to exec command in pod: command terminated with exit code 2"

cheers

 

Userlevel 4
Badge +2

Hello @Geoff Burke,

Thank you for pointing out, I have tested and indeed the mongo command was deprecated, it must be replaced with mongosh inside the blueprint to work.

We are working to update the application consistent blueprints templates to support latest versions.

Regards

FRubens

Userlevel 7
Badge +22

Hello @Geoff Burke,

Thank you for pointing out, I have tested and indeed the mongo command was deprecated, it must be replaced with mongosh inside the blueprint to work.

We are working to update the application consistent blueprints templates to support latest versions.

Regards

FRubens

ok thank you very much for this. I have a demo coming up soon and really wanted to show this. I do underline that application owners are the ones who have to create these and keep them up to date since we can’t be experts in everything. Although this one you found pretty fast :) . I will give it a spin. 

Thank you 

Userlevel 7
Badge +22

ok trying this again. Blueprint errors out with exit code 2 which I believe means command not performed correctly somehow in the script. To be fair all I did was change the mongo to mongosh. However I can exec into the pod and exec successfully:
 

 

Userlevel 7
Badge +22

I think that I have to stop being lazy and go back and review Kanister :) outside of Kasten then comeback

 

https://docs.kanister.io/index.html

Userlevel 4
Badge +2

Hi @Geoff Burke ,

Please take a look in the kanister logs, they might point you what was the issue with the command.

kubectl get pods --no-headers -n kasten-io | grep kanister | awk '{print $1}' | xargs kubectl logs -n kasten-io

Maybe you can even add -f at the end of the command and monitor it while running the backup, it is not easy to read, but you can see the commands being executed.

I have tested replacing mongo with mongosh and the policy completed with success, you can also provide the kanister log here so we can check.

FRubens

Userlevel 7
Badge +22

Thanks @FRubens will do! 

Userlevel 7
Badge +22

Well in the end there was no need. I was pretty sick yesterday so I have no clue what I did. Today I deleted what I did yesterday and took the blueprint from the docs, changed the mongo command to mongosh again and … voila 

 

I did not trust myself, maybe I put the blueprint in the default namespace in haste or something :) so I checked.. all good snapshot and the hooks blueprint is there that performs the db lock. Thanks again @FRubens for answering this on a weekend. I realize this is free support so I really appreciate it when people answer from your team. 

Snapshot
Blueprint was leveraged

cheers

 

Geoff

Comment