/
The proper method for extending existing Puppet Modules (AKA Where do SIMP Profiles Go?)

The proper method for extending existing Puppet Modules (AKA Where do SIMP Profiles Go?)

Owned by Trevor Vaughan
Last updated: Jun 19, 2015
StatusDONE
StakeholdersChris TessmerĀ Michael RiddleĀ Judith JohnsonĀ Kendall MooreĀ 
Outcome
  1. If you can use it, use it
  2. Add some glue (simp_module_name)
  3. Fork it ( (sad) )

In that order.

Due date
OwnerTrevor VaughanĀ 

The Decision

  1. If you can use it, use it
  2. Add some glue (simp_module_name)
  3. Fork it ( (sad) )

In that order.

Background

The issue that we have is precisely cemented in the `electrical-elasticsearch` Puppet Module.

To make things work the way we need them to, we have a few options:

  1. Ā Fork the Module and push forward
    1. This has the obvious issue of needing to re-integrate all the time. It's not a horrible approach but not super exciting either as time presses on.
    2. This does technically have the advantage of easiest to attempt to push changes upstream. We can't push SIMP-specific changes, but we can push bug fixes, etc...
  2. Create a module named simp_elasticsearch which is just a profile set of the elasticsearch module
    1. This is good for the community but rapidly grows into a lot of pain in terms of figuring out what's going on as well as massive amounts of module creep all over your Environments
  3. Shove everything into the simp module
    1. I hate this the most because, as Chris and Kendall both pointed out, you will then need to push out an update of the simp module for minor changes that don't actually affect everyone. This may hurt upgrade capabilities for downstream users.

Ā 

Action items

  • (what was this checkbox for?)

Related content