The way our development environment code is handled today is as follows:
puppet-katello_devel – has all of the logic to configure environment
katello-devel installer scenario – creates an installer scenario to run partial normal setup and puppet-katello_devel
devel scenario is packaged into foreman-installer-katello
this scenario is not tested
this scenario is gated by standard nightly release process
Problems
Devel is untested
Devel is blocked by nightly breakages when can stretch out
Devel needs to move faster and react to changes faster than nightly
Devel is buried under layers of release (puppet module -> installer -> nightly)
Proposal
The proposal is to drop puppet-katello_devel and the devel installer scenario and switch to Ansible role(s) that performs a similar set of operations that lives in Forklift. I believe this will provide faster turn around for development environment issues, engage more developers fixing and adding features and provide an easier avenue for testing the development setup asynchronously to the nightly release process. To sum it up in bullet points:
Add required functionality from puppet-katello_devel to foreman_devel role (and/or add roles)
Move development playbooks to use new role
Archive puppet-katello_devel
Remove devel scenario from installer
I’ve began the first bullet point locally but would love collaboration from anyone interested. What can you as a developer do with this RFC? +1 if this sounds like a solid plan. Reply here if you have additional requirements, requests or ideas for consideration.
Note: This proposal does not intend to reflect any changes to how Forklift itself works or is designed today so please limit this to how a development environment is configured. There will be a separate RFC around Forklift itself.
I like the idea of removing layers which add complexity - especially when things go wrong and it’s time to debug. Like you said, this will encourage engagement from others who would simply groan when something blew up during the devel installer. +1
Big +1 from me. But before we get there, today we don’t have a good option to also deploy foreman proxy with additional plugins.
Until we have luna counterpart for proxy in Forklift, I think it would be useful to keep devel scenario and add luna plugins to it. Today it only installs core proxy and content plugin if I’m not mistaken. If we have all luna plugins there, we’d have full dev setup of Foreman part.
I’d prefer having this temporary solution since adding proxy plugins in dev setup is not that easy. Plugins have configuration files that are today created only by puppet installer.
+1 - I guess this means that changes to puppet-* repos will have to be tested against katello.yml rather than katello-devel.yml after this change. Right now we use the module_pr foreman_installer task. I guess it wouldn’t make sense to test puppet modules against devel if devel no longer contains puppet modules.
As I started down the path of creating a development role to mirror puppet-katello_devel it occurred to me that we can achieve some of the goals herein faster by making direct use of latest and greatest puppet-katello_devel and by passing the installer release workflow.
Thus, I created a PR that adds a role that includes the katello-devel installer scenario and functionality to clone puppet-katello_devel from master when spinning up an environment.
This should provide a bridge to pursue migrating pieces of development setup into a role for broader use while maintaining functionality and avoiding a major overhaul. Please let me know your thoughts here or on the PR. If this is accepted, I will then remove all -devel references from our installer code base.
The initial work has been merged moving the devel scenario into a role in Forklift directly. This means devel installs with master on Forklift will now use latest and greatest puppet-katello_devel at any given time. To modify the devel scenario from here on out, modifications must be made to the scenario in the role. See:
