How will RPM-based and foreman-installer installations migrate to a container-based installation?

[ehelms]

This is track how users will upgrade from a classic installation based on RPMs and using foreman-installer to container based.

[archanaserver]

• migrate redis installation from rpm to container-based #63
• migrate pgsql installation from rpm to container-based #62
• migrate httpd installation from rpm to container-based #59

[ekohl]

Those don't appear to migrate existing installations, which is how I interpreted this issue. Probably also much larger, requiring some discussion

[archanaserver]

@ekohl Isn't those are part of it? That only covers basic installation setup so far for only services and not the config migration.

I want to understand more though!

[ehelms]

@ekohl Isn't those are part of it? That only covers basic installation setup so far for only services and not the config migration.

I want to understand more though!

I can understand the confusion and I attempted to clarify the title and description. This issue is intended to cover how existing installations will upgrade. The using containers for backend services is arguably a subset of that but could be tracked on it's own.

[ekohl]

IMHO this is about how users will migrate their existing installations. Perhaps include the word users in the title?

[archanaserver]

Ah, Thanks for clarifying! Seems more clear to me now.

[ehelms]

Here are some notes from a few discussions:

• Ideas
  • Delivering the base .container file within an RPM
  • Applying quadlet overrides for any additional configuration
• Questions
  • What is the level of configurability we need to have?
  • What worked well from the previous experience? What did not work well?
  • Do we need a wizard?
  • Is a config management tool sufficient or do we need to implement it in a full blown programming language?
• smart-proxy is a heavy burden and bottleneck to new installer
  • could we write RPM-based smart-proxy installation with new installer technology?
  • could we draw the line between Foreman with containers and new installer and smart-proxy/Capsule using puppet-based?

[ehelms]

Adding some additional context for this from other discussions:

• How coupled is the current installer when it comes to installing core components vs. the smart-proxy?
• Is there a clear division line between the core application install and the smart-proxy parts?
• Do we need to update the architecture first to have this cleaner division?

This is in service of whether we could use a new installer for the core application and the existing installer for the smart-proxy /foreman-proxy/Capsule parts to allow us flexibility in migrating.