Skip to content
This repository was archived by the owner on Jul 14, 2021. It is now read-only.

Roles and Environments should have identical implementations #182

Closed
lamont-granquist opened this issue Oct 7, 2014 · 2 comments
Closed
Labels
Type: Enhancement Adds new functionality.

Comments

@lamont-granquist
Copy link
Contributor

They're basically the same right now, but environments support cookbook version pinning and roles do not (at least not without the hacky equality pinning in the run_list). If they were normalized, then the distinction between them would go away. Environments could ideally then be just dropped and sites could use role[production]. role[development], etc. We'd still probably keep them around because people want a thing called 'environment' that matches their 'development/test/integration/production' workflow.

Right now environments are bad because its a 1-1 mapping and results in sites having to decide up front what their strategy will be and then they will get locked in. You see sites where they start mixing in datacenters and canaries and all kinds of other dimensions into the environment in order to get their deployment cells.

The difference is that before you might have a server with:

run_list:  role[foo_app]
chef_environment:  production-seattle-canary

The result is a large number of environments to manage as we have the cross product of all the dimensions expressed in the environment. Each item in the cross product is another cell to manage.

And afterwards:

run_list:  role[foo_app], role[seattle], role[canary]
chef_environment: production

Now we don't have to manage and name the cross product of the things, we just manage the axes and then they get mixed in. That keeps 'environment' as the name for the thing people expect (or they could drop it entirely), and then also allows the rest of the matrix to expand organically. If the company fragments and they need to add logical business units to the run_list to segregate companies-within-a-company then they can just add another role to all the servers that maps to the business units, etc.

@johnbellone
Copy link

👍

@danielsdeleo
Copy link
Contributor

Gonna close this since it's not really a ChefDK thing. If you use policyfiles, then you're not using roles or environments, so that sorta fixes the issue. That said, we're probably gonna need some sort of policyfile composition story (maybe also a service discovery thing to replace environment attributes) before most organizations will be able to migrate to them, so maybe it's worth some kind of near-term updates to the non-policyfile way of running Chef to improve the story here. But the RFC process is probably a better place to propose and track that.

@thommay thommay added Type: Enhancement Adds new functionality. and removed Enhancement labels Feb 1, 2017
@chef-boneyard chef-boneyard locked and limited conversation to collaborators Feb 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Type: Enhancement Adds new functionality.
Development

No branches or pull requests

5 participants