feat: add configuration templates

[gazarenkov]

Description

Add profile configuration as a part of "flavor approach" for installation methods

Which issue(s) does this PR fix or relate to

PR acceptance criteria

• Documentation

How to test changes / Special notes to the reviewer

PROFILE=rhdho docker compose -f profile/compose.yaml up

Summary by Sourcery

Introduce a profiles-based installation method by adding a new profile directory containing a sample ‘rhdho’ profile, a Docker Compose orchestrator for RHDH and its plugins, and documentation on using and customizing profiles

New Features:

• Add support for preconfigured installation profiles via a new profile directory
• Include a ready-to-use ‘rhdho’ profile with app configuration, backend settings, catalog entities, and dynamic plugins
• Provide a docker-compose setup to launch RHDH and associated SonetaFlow orchestrator using profiles

Documentation:

• Add README explaining profile benefits, structure, and usage instructions

[sourcery-ai]

Reviewer's Guide

This PR introduces a profile-based installation mechanism by adding a new profile/ directory with documentation and a root compose file to orchestrate services and dynamic plugins, along with a sample rhdho profile that provides app-config templates, dynamic-plugins setup, service definitions, catalog-entity overrides, and environment variable scaffolding.

File-Level Changes

Change	Details	Files
Introduce profile-based deployment framework	Add README explaining profile usage and structure Add root compose.yaml to include profile services and plugin installer Configure env_file, volumes, and dependencies for profile-based compose	profile/README.md profile/compose.yaml
Add sample 'rhdho' profile scaffolding	Create app-config.yaml template with auth, branding, backend, catalog, and techdocs sections Add dynamic-plugins.yaml to include and configure orchestrator plugins Add services.yaml defining the sonataflow container and workflow mounts Provide example catalog-entities overrides for components, users, and mkdocs Introduce default.env for profile-specific environment variables	profile/rhdho/app-config/app-config.yaml profile/rhdho/dynamic-plugins/dynamic-plugins.yaml profile/rhdho/services.yaml profile/rhdho/catalog-entities/components.yaml profile/rhdho/catalog-entities/users.yaml profile/rhdho/catalog-entities/mkdocs.yml profile/rhdho/default.env

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[durandom]

it's a good way into the right direction but from a naming perspective I think we want to keep the flavor term because that is what people are getting used to

second I would love to see how we can reuse some of the configuration that is part of a specific flavor either by consuming the configuration from the operator repository or maybe from a new repository that contains the flavor definition and this external new repository is then consumed by our HDH local and the operator and maybe the helm chart

[kadel]

How this related to the work that has been done in #55 and in #72?
Isn't this just another approach to #72 ?

[gazarenkov]

How this related to the work that has been done in #55 and in #72? Isn't this just another approach to #72 ?

@kadel
I have no idea about another approach, my point was to make a POC of predefinid configurations (flavours) as discussed with @durandom on Mon and next day I discussed this idea with the team and go to this POC, I do not know how it related to anything :)

[gazarenkov]

it's a good way into the right direction but from a naming perspective I think we want to keep the flavor term because that is what people are getting used to

Thanks,
Any naming is OK with me, as discussed, the point is mostly to generate the idea/POC for predefined configs

However, note, this configuration in local is a "final" configuration, not "default" configuration (like config in operator profile or default values in chart) where the "final" configuration comes with CR and user values respectively.

second I would love to see how we can reuse some of the configuration
that is part of a specific flavor either by consuming the configuration from the operator repository or maybe from a new repository that contains the flavor definition and this external new repository is then consumed by our HDH local and the operator and maybe the helm chart

I believe any app-config related configuration is reusable because it is processed by backstage, the difference is the way of delivering (local files/envs vs CMs/secrets)