I wanted to provide an update to this. The general flow is very similar with a few key differences. As we worked through user stories, it became obvious that creating a new pull provider would result in:
- Duplicated job templates
- Needing to enhance the UI to support running the same ‘job’ across multiple providers, potentially with different inputs
Talking through it we realized that to a large extent the templates used to generate instructions to run on a host should not be fully tied to the technology used to execute it on the host.
This is similar to what evgeni brought up here: Relationship between Ansible and REX proxy plugins - #9 by evgeni
While this could long term lead to a break between the templating (scripts & ansible playbooks) and the execution technology (ssh & ansible) for the time being this has some implications for the ‘pull provider’ work.
We came away with:
- There should not be a dedicated pull provider
- The ‘SSH’ provider sould be named the ‘Script’ provider
- The ‘Script’ provider should support executing via SSH or Pull on a given smart proxy
- The ‘Script’ provider should support an optional MQTT notification if configured to use Pull
- The sys admin installing & configuring the Smart proxy would decide if the Script provider should use SSH or Pull
- The foreman application does not need to know which host will use pull or which host will use SSH, it will simply use a smart proxy for execution, that smart proxy will use the method it is configured for
I’ve updated our Google Doc with user stories and Personas that i invite you review: RHC inspired MQTT Pull Provider - Google Documenten