1

I am creating a Chef recipe that does a couple of things, amongst others a big import of data into a Postgresql database.

I am using the Supermarket 'postgresql' cookbook which allows me to create a config file via node['postgresql']['config'] attributes.

I would like to update the config in postgresql.conf during my recipe run, namely set values that cater to the big import just before I do that big import and subsequently when that is finished update those values so that are more catered to day to day operations (specifically fsync and full_page_writes 'off' before the import and turn those 'on' after).

I created ruby_block resources that enable me to update the node.default['postgresql']['config']['fsync/full_page_write'] via a notify just before and just after the import but these changes are not serialised to the postgresql.conf, I guess because the postgresql::server_conf has already run at that stage.

Is there a way that I can signal the postgresql cookbook that I would like to have the node['postgresql']['config'] serialised multiple times during a run?

Martin Bokman
  • 9
  • 5
  • adding `run_context.include_recipe` or `run_context.load_recipe` to my ruby_block resource does not seem to help. – Martin Bokman Oct 18 '15 at 21:32
  • Are you using an immediate notify or a delayed one? I would expect an immediate notify would do what you want if you're notifying the appropriate resource defined in `postgresql::server_conf`. Can you show us specifically what you're doing in your recipe? – Martin Oct 20 '15 at 09:10
  • I am unable to answer this in a few sentences so I have created this gist (https://gist.github.com/mbokman/a29592680f1dbcb05a65#file-server_conf-question-md) which hopefully clarifies what I am trying to do. – Martin Bokman Oct 21 '15 at 21:12
  • I don't think you can rely on `include_recipe` the way you are doing. If that recipe was already included earlier, your use of it would be a no-op. Recipes run only once, regardless of how many times you include them. – Martin Oct 22 '15 at 09:13
  • Hi, thanks for your reply. I guess I have no other recourse than copying the logic from server_conf.rb and serialize the postgresql.conf myself when I want. It seems clumsy. – Martin Bokman Oct 22 '15 at 09:27
  • The goal with Chef is idempotency. You figure out your state, and then set it that way once. Chef isn't really designed to take your postgresql configuration through one state, then run scripts, then another state. It probably isn't the best way to do what is essentially orchestration. You can write your recipes with resources instead of recipes, and then you'll be able to more easily execute your logic, but it will probably still feel like a bit of a chore to get perfect. Perhaps check out `chef push` or some of the more advanced features that handle events like a database migration. – Martin Oct 23 '15 at 01:24
  • Hi Martin, thanks for your feedback, I appreciate what you're saying. Nevertheless, I did find a way to achieve what I wanted without too much repetition/copying of logic from the original 'postgresql' cookbook. I have created a new gist (https://gist.github.com/mbokman/58b826258d05f1c7bec0) that shows I am referring to and updating the postgresql.conf template from the 'postgresql' cookbook and restarting/reloading the 'postgresql' service appropriately. I hope it is helpful to someone else. – Martin Bokman Oct 25 '15 at 17:01

1 Answers1

-1

Found the answer myself, this gist (https://gist.github.com/mbokman/58b826258d05f1c7bec0) shows how I did it.

Martin Bokman
  • 9
  • 5
  • Made a slight edit to the `resources()` call in the gist to prevent foodcritic from complaining. – Martin Bokman Oct 27 '15 at 20:16
  • Even for self-answered questions, please add the most relevant details from external links to prevent link-rot. – Sven Oct 31 '15 at 15:53