Use recursive_merge instead of Bosh::Template::Renderer for stubs

[rkoster]

This PR simplifies stub files, by not having to use an intermediate format (erb with 'p('foo') helpers). It allow you to create a yaml stub file which can be used to inject name, director_uuid and meta.

cc @allomov

[cfdreddbot]

Hey rkoster!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you've already signed the CLA.

[allomov]

Yey! That's a great idea.

I also wanted to find the way to substitute bosh-template. And the easiest way would be using spruce with its possibility to create templates out of templates. I like this way to create stubs.

[allomov]

I have one consideration here. I can think of the situation when you can take advantage of bosh-template here. Imagine you have following stub:

stub.yml

properties:
  components:
    - gaussian-filter
    - bandpass-filter

bosh-templates allow to have the following deployment deploymnet.yml

director_uuid: some-hash

templates:
  - common-components.yml

<% p('components').each do |component_name| %>
  - templates/additional-components/<%= component_name %>.yml
<% end %>

meta:
  bandpass-filter:
     t1: 440

Finally it looks like such solution has more fragile, but a little bit messy. What do you think?

[rkoster]

@allomov I see your use-case I'm however not sure if this should be something to support. Since it makes it even harder to reason about the outcome of the deployment (which makes it a nightmare to maintain). In the above case I would create separate deployment files for different use-cases. As was for example done with swarm support in the the docker-services-boshworkspace.

[allomov]

Yes. I see, still having distinct deployment file for every case seems little bit redundant for me.

[allomov]

I have controversy feelings about it: I both like and dislike it. Of course, it would be nice to have something else from ERB to render yaml templates, but there is no such things and spruce looks like reasonable choice here.

[rkoster]

I'm currently working on adding rspec helpers to easily test all the deployment in a boshworkspace repository. I found that not having a dynamic number of templates makes it easier to test. Because one deployment is basically one use-case.

[rkoster]

Will leave this PR open till I finish the rspec helper PR

[allomov]

This makes sense. Would like to see such specs.

[allomov]

@rkoster have you seen this PR ? https://github.com/geofffranks/spruce/issues/51

Seems like suffering could be over in some time and stubs can be merged using spruce. :)

[allomov]

@rkoster as far as I can see you are going to open source you spec helpers. Can I take a look on them? To avoid repeating each other.

[rkoster]

Just finished creating a PR: https://github.com/cloudfoundry-incubator/bosh-workspace/pull/81

[allomov]

To be honest, I don't see huge benefit of using ERB without taking advantage of bosh-templates. Why do you need ERB then?

[rkoster]

I personally don't use erb. Logic in templates makes them even hard to maintain. Erb support was a contribution https://github.com/cloudfoundry-incubator/bosh-workspace/pull/69. I don't know what it is used for. And if that usecase could be covered with the current stub merge behaviour.

[allomov]

I don't feel convenient with having deployment file for each kind of deployment. Potentially, ERB and bosh-templates can help with it. Still I understand they can cause huge mess in deployment file and that's one of the reasons why I like idea with deep merge. This really puts me into cognitive dissonance :)

[rkoster]

Have you seen the tests I added to the cf-boshworkspace? Basically you can test all you different deployments with just a simple stub + result file per deployment. After working with it for a week I found this really powerful. It gives you the ability to get a bosh deploy like diff of the changes but then for all your environments at once. This way you can see how a templates change affects all your deployments. Something which would be much harder when using erb.