Patch1 support split stack

[mootpt]

This patch adds optional roles for a split installation. (camom, puppetdb, console). Likely needs some additional love.

[logicminds]

This would be an awesome addition.

[adrienthebo]

This needs a rebase in order to be merged, @revhazroot @npwalker @Sharpie could you guys figure out a route forward on this?

[logicminds]

Just rebased here: https://github.com/logicminds/vagrant-pe_build/blob/patch1-support-split-stack/lib/pe_build/config_builder/pe_bootstrap.rb

Going to test it out.

The only thing I would add is to maybe split the puppetdb into two roles for a external postgres install. But we could add this at a later time too.

[logicminds]

This feels a bit weird after using but I think its a combination of all these abstraction layers. Especially, because the roles and vms are tightly coupled in order for dns to work. The roles file must know about the vms when using config builder. So about the only other way I could think of is to put these options(camom, puppetdb, console) in the global config instead so we could use the pe_build.yaml file. However, I feel like this is more of a vagrant limitation. So maybe terraform would be a better fit for what we are trying to do since it can handle node dependencies. I am also unsure about the ordering of vm creation. Does the puppetdb need to start first? What is the correct order?

Basically when I specify my vms using config_builder from the list of roles

I also have to set all the pe_bootstrap config values for each role which bugs me because I specified the same values for each role.

I was hoping I could set these values in the pe_build.yaml file but these are not in the global class.

[logicminds]

Oh and I found a typo in one of the templates and fixed on my branch.

[logicminds]

This PR is also missing the cmaster template. Unless its expected to use the node classifier to classify a compile node.

[mootpt]

You are correct, it is in fact missing the cmaster template. Seems this will need to be done via classification. I have had success booting the camom, then puppetdb, then the console. This needs a bit of work tbh. May close this PR in favor of a rewrite/different approach.

[logicminds]

well I have a working branch based off the original code with only a few modifications. Aside from the cmaster everything seems to work as intended. I can submit a PR from my branch. @revhazroot

For the cmaster I think we could just call the api during a shell provisioner to inject the classification of cmaster and follow the PE docs more or less. Assuming the classifier has a REST API or way to inject data. If not we can just update site.pp or something too.

[mootpt]

@logicminds excellent. The classifier does have an API and there is an existing PE master group that ships with Puppet Enterprise that includes all of the necessary classification for a node to be promoted to a compilation master. We could update the rule to include the cmaster fqdn (https://docs.puppetlabs.com/pe/latest/nc_groups.html#post-v1groupsid), but I believe this might be problematic as we don't know the id of the node group? Looks like we will need to have this returned first before we can override the rules.

[npwalker]

You could make a rule in the classifier on the PE Master Group that uses a custom fact that you lay down in facts.d on the compile masters.

However, you'd still need to know the UUID for the PE Master Group.

[logicminds]

@npwalker I opened another PR #85 with my changes.