Apply properties directly to the facet roles; static and cluster roles should go away

[mrflip]

Right now, Ironfan's chef provider holds declarations as separate layers and applies them independently to a dynamic cluster role and facet role. Still others come in through the static component roles in the roles/ directory.

While there were good arguments for this, it’s clear now that this was a mistake: it’s unpredictable to have two different mechanisms for layering attributes. Additionally, you have to look in multiple places on the console to see what’s made it to the chef server; there's added complexity to preserve the layering; and it causes some operational annoyances (for the static roles files, operational hellholes).

The correct general principle is to compile state in a single place, and serve all downstream processes with an unambiguous static manifest. With the components features @joshbronson has added and the manifest code he's working on now, we can get rid of roles.

By looking at the system as used, we believe there should be only three roles applied to every machine: an organization role, a realm role and a facet role.

• By convention, the only attributes placed in the org or realm roles should be the ones you do NOT want to be variable at the facet level. You are making clear to the operator that if a facet has an override something unusual and intentional is happening. Nothing we saw passed that test for either cluster or component roles when we looked through the attributes in existing files. Anything that should be invariant at the component level should go in the component helper or in the cookbook itself.
• This is the sole place it continues to be a good idea to use roles. This level of limited layering is healthy and predictable: attributes are intended to live at exactly one of the three layers, but an override is still possible where necessary.
• The Ironfan components helpers should take over all attributes currently set in the component-level roles/*.rb files. It should instead set them on the facet role, just it does any other attributes. Current versions of the public ironfan pantry will continue to have the legacy roles; if you are using components they will never be referred to, so their presence is harmless. (We'll be removing them from our production homebases though, in case you were wondering.) In the next version of Ironfan, the roles directory should be empty; that change will get its own issue.
• If you change some property of the cluster, but only knife cluster sync one facet, the changes will only apply to that one facet. This is considered a feature, not a bug. In practice, applying such a change immediately cluster-wide made a rolling upgrade of a cluster dangerous. If you want the change to be cluster-wide, just do a knife cluster sync to the cluster
• The DSL must continue to have separated cluster, facet and component attributes: you must be able to declare properties of a cluster and not until much later describe its facets. Until the projection (provider+broker) code is refactored, the manifest should continue to be faithful to what the code does (i.e. it should describe the dynamic roles that actually are generated).
• If this feature lands in the current 4.x major version era, Ironfan should continue to print a blank cluster role by default in the current version, so that existing deployments don’t have stale cluster roles. There should be a :make_cluster_roles config option to disable that. In the next version of Ironfan, these roles will not be printed, and there should not be an option to do so. The manifest auditing tool should validate that the final compiled attributes are the same using the old roles or the new components.

The superannuation of static roles in favor of components is underway right now. Separation of facet and cluster roles may happen during this quarter (Q4C13), but otherwise early in the next one.

/cc @nickmarden @temujin9 @joshbronson

[temujin9]

I would recommend squashing all attributes down to a single per-facet role, rather than three layers. That provides a single touch-point between Ironfan and Chef for attributes, which simplifies debugging.

[joshbronson]

Yes, I can't think of a good reason to have three roles rather than one.