Skip to content

Dynamic YAML config by processing ERB first #24

Merged
adrienthebo merged 1 commit intooscar-stack:masterfrom
nanliu:erb
Sep 20, 2014
Merged

Dynamic YAML config by processing ERB first #24
adrienthebo merged 1 commit intooscar-stack:masterfrom
nanliu:erb

Conversation

@nanliu
Copy link
Copy Markdown
Contributor

@nanliu nanliu commented Sep 15, 2014

The yaml configuration files are processed by ERB first. This allows
slightly more dynamic configs, such as support of environment variables
for vagrant vm/provisioner settings:

---
  provisioner:
    - type: puppet
      manifest_file: <%= ENV['VAGRANT_MANIFEST'] || 'init.pp' >

@nanliu
Copy link
Copy Markdown
Contributor Author

nanliu commented Sep 15, 2014

Not sure if there's a better solution (or if I'm using this plugin wrong). This would allow something like:

---
  provisioner:
    - type: puppet
      manifest_file: <%= ENV['VAGRANT_MANIFEST'] || 'init.pp' >

@adrienthebo
Copy link
Copy Markdown
Member

I would rather ERB interpolated YAML be implemented as a separate loader; the loader layer is entirely pluggable so you can easily implement elaborate loaders without having to change the core implementations.

@adrienthebo
Copy link
Copy Markdown
Member

For that matter, you could add a custom loader that inherits from the YAML loader, override that one method, and be done with that. However I don't want this to be a core behavior of the YAML loader.

@nanliu
Copy link
Copy Markdown
Contributor Author

nanliu commented Sep 15, 2014

Sure, I updated the PR.

@adrienthebo
Copy link
Copy Markdown
Member

Also, one of the purposes of this plugin was to get away from intertwined logic and data. If you need functionality like this, why not use a stock Vagrantfile?

@nanliu
Copy link
Copy Markdown
Contributor Author

nanliu commented Sep 15, 2014

Originally I was using a stock Vagrantfile, then I wrote a wrapper to simplify the VM specification, but it was a bit clunky. The more I updated the wrapper, the closer it looked like something like this, so I thought it would be easier to add a few small things to this project. I really don't need to tweak the rest of the VM configuration, except occasionally the puppet agent environment or the puppet manifest file name.

@Sharpie
Copy link
Copy Markdown
Member

Sharpie commented Sep 17, 2014

I also believe that one of the driving purposes behind config_builder is to provide a logic-less way of configuring Vagrant. However, thhat does not have to preclude having an ERB layer that re-introduces logic --- as long as the two remain clearly and cleanly separated into different loaders.

@nanliu
Copy link
Copy Markdown
Contributor Author

nanliu commented Sep 17, 2014

Yep, the PR was rewritten so the erb loader is yaml_erb, and the original yaml loader is left as is.

@adrienthebo
Copy link
Copy Markdown
Member

Okay, I'm 👍. Since this isn't as straightforward as pure YAML could you add some documentation to the class demonstrating the interpolation? Your first comment in this thread would be a great example of that.

The yaml configuration files are processed by ERB first. This allows
slightly more dynamic configs, such as support of environment variables
for vagrant vm/provisioner settings:

```yaml
---
  provisioner:
    - type: puppet
      manifest_file: <%= ENV['VAGRANT_MANIFEST'] || 'init.pp' >
```
@nanliu nanliu changed the title Support more flexible yaml config. Dynamic YAML config by processing ERB first Sep 19, 2014
@nanliu
Copy link
Copy Markdown
Contributor Author

nanliu commented Sep 19, 2014

@adrienthebo, I've made some updates to the PR. Let me know what you think. I'll write another PR to update the project documentation (README, etc).

adrienthebo added a commit that referenced this pull request Sep 20, 2014
Dynamic YAML config by processing ERB first
@adrienthebo adrienthebo merged commit 1d8fa98 into oscar-stack:master Sep 20, 2014
@adrienthebo
Copy link
Copy Markdown
Member

Thanks for the contribution!

@nanliu nanliu deleted the erb branch September 25, 2014 16:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants