RFC: foreman_templates refactoring and improvements

Development RFCs
#1

Purpose of this RFC: To improve foreman_templates plugin. Current plan:

  1. refactor and remove duplicate code for importing templates
  2. improve error handling and propagate meaningful errors to a user so that it is obvious why a template was not imported
  3. better structure of API controller response, related to the previous point
  4. add UI for template syncs
  5. fix several minor issues related to sync settings (repeated imports/exports are idempotent, default prefix should be empty, …)
  6. add CLI commands
  7. Deprecate and remove the rake task for import/export, use API, CLI and UI
  8. Use application logger

Current progress:
Several PRs opened to fix minor issues, pending reviews.

Next steps/action needed:
There are 2 approaches we can take to code refactoring, we have PRs opened to give everyone a better idea what it would look like. We can:

A. move the import logic to core


B. keep it in foreman_templates


We need to decide which way to go, since this essentially blocks further progress (most notable points 2. and 3.). Let us know what you think.

Redmine for foreman_templates tracking all the opened issues.

1 Like
Questions about provisioning template storage and update behavior
#2

Thanks for this summary. Very appreciated.

In case foreman_templates is used, it would be nice to use the foreman_templates plugin from the very beginning and use these templates instead of the seed.d templates.

Regarding “template sync”, there are some regular sync plans currently in foreman / katello:

  • Katello sync plans for repositories
  • Remote Execution Tasks
  • foreman template "sync plans"
    What about one “driver” to schedule such regular tasks which can be used within foreman?
1 Like
#3

Absolutely, having this in core enables some nice possibilities. I am going to review the core patch, thanks.

#4

The idea of using foreman_templates instead of seeds is interesting. It would save us the step of copying templates from community-templates into foreman/views/unattended.

Having some sort of general scheduler that would run regular tasks would be nice, though it would require some design to meet the needs of all the areas you listed. Maybe another RFE? :wink:

1 Like
#5

This particular item is worth noting in this context. The ability to sync a repository at intervals is something that Katello will need to support natively. Pulp 3 is removing scheduled tasks, so a pre-cursor to eventually moving to it will be to provide sync plan functionality directly. This implies that we will need some core solution for this. So there is one driving factor towards spending the time to build central functionality around this idea.