Take the 2-minute tour ×

I’m thinking about converting my roles to JSON syntax and storing some extra data in there for an external, non-chef application (specifically Vagrant). My idea is that if I stick to a convention in which each machine only gets a single role, I can have Vagrant iterate through my roles directory and automatically configure a separate VM for each one.

The problem is that different roles may require different Vagrant settings (e.g. CPU, memory, forwarded ports, etc.), so I figured I could store all this stuff under a “vagrant” key in each role file. In my testing, I found that I can create any keys I want in these files, and the Chef server simply strips them off when you upload them. And this is fine, because the only thing that would ever need to look at them is Vagrant anyway (which simply parses the local files).

What does everyone think? Is this a bad idea? I can’t see how this could possibly hurt anything, but since I’ve never heard of anyone else doing anything like this, I figured I should ask around.

share|improve this question
add comment

1 Answer

I don't think there's any guarantees that this would continue working forever - but if it works today, I don't imagine that will change any time soon.

So that wouldn't stop me, but I probably wouldn't do it anyway - what happens when you want to create a role that shouldn't have a corresponding VM? For example, a base role abstracting common components from two other roles.

I'd prefer a separate directory containing yaml/json files for Vagrant to loop over, perhaps mapping those to Chef roles by convention.

Despite disagreeing on some details, I think it's a good idea - how did it work out for you?

share|improve this answer
add comment

Your Answer


