Last modified: 2014-09-24 19:04:57 UTC
We have several roles or potential roles that provide conflicting or redundant services: HHVM vs PHP5, Redis vs Memcached, MySQL va MariaDB. In a "normal" Puppet usage, the site manifest would be used to say "setup hostA with hhvm, redis and mariadb" and "setup hostB with php5, memcached and mysql". Our use case is strange though. As far as puppet is concerned we have one host with one configuration. We want that host to "just work" for a new MediaWiki-Vagrant user in that when they run `./setup.sh; vagrant up` we want a VM to be created that has some PHP runtime, some cache service and some db to power a running wiki. It would be really neat to find a way to create a "virtual class" or interface of some type that can be used to provide choose one of many support for classes that are applied to a host. This would optimally allow a default configuration to be created and then let the user choose at some later time to swap variantA for variantB. This gets even a little trickier for the database layer as we use defined types like mysql::user and mysql::db from outside the mysql module.
I've been thinking about the idea of role variants as well. In addition to the conflicting-resources problem that you mentioned, there seems to be a need in some cases to customize the behavior beyond the broad on/off pattern that roles provide, the biggest example I can think of being the toggling of browser-test dependencies. [1] Another example would be having 'full' or 'minimum' variants of roles—the latter serving those who dream of a leaner and meaner MWV. One way forward might be to add parameters to role classes so that certain sub-features can be customized—leveraging hiera as the actual implementation. To specifically solve the conflicting resource issue, we would reduce certain sets of roles into singular ones that take a $provider parameter—e.g. `class role::php($provider = 'hhvm')` or `class role::mysql($provider = 'mariadb')` or `class role::cached($provider = 'redis')`. This pattern seems to be congruent with pupppet's implementation of `service` and `package` providers. Role parameters could either be set via the `vagrant hiera` command or, if that's too cryptic for people, we could allow for parameters to be passed to the `vagrant enable-role` command. (e.g. `vagrant enable-role php --provider=hhvm`). [1] https://gerrit.wikimedia.org/r/#/c/155861/
(In reply to Dan Duvall from comment #1) > > Role parameters could either be set via the `vagrant hiera` command or, if > that's too cryptic for people, we could allow for parameters to be passed to > the `vagrant enable-role` command. (e.g. `vagrant enable-role php > --provider=hhvm`). The idea of enable-role providing some facility for option switches is an interesting one. The homebrew system for managing OSX packages allows "options" to be specified when you install a package via `brew install <package>` and the list of possible options can be seen with `brew info <package>`. The system supplies sane defaults when no options are given. While we are at it maybe we can change `vagrant enable-role ...` to `vagrant role enable ...` too. :)
Some sort of `vagrant role info` command to show possible options would be great, especially if we could just print out the puppet class documentation.
