Use table for default OS repositories
What changes are you introducing?
Introduce tables to list default OS repositories of supported Client OS
Why are you introducing these changes? (Explanation, links to references, issues, etc.)
to simplify and shorten instructions
Anything else to add? (Considerations, potential downsides, alternative solutions you have explored, etc.)
Checklists
- [x] I am okay with my commits getting squashed when you merge this PR.
- [x] I am familiar with the contributing guidelines.
Please cherry-pick my commits into:
- [x] Foreman 3.14/Katello 4.16
- [x] Foreman 3.13/Katello 4.15 (EL9 only)
- [x] Foreman 3.12/Katello 4.14 (Satellite 6.16)
- [ ] Foreman 3.11/Katello 4.13 (orcharhino 6.11 on EL8 only; orcharhino 7.0 on EL8+EL9; orcharhino 7.1 with Leapp)
- [ ] Foreman 3.10/Katello 4.12
- [ ] Foreman 3.9/Katello 4.11 (Satellite 6.15; orcharhino 6.8/6.9/6.10)
- [ ] Foreman 3.8/Katello 4.10
- [ ] Foreman 3.7/Katello 4.9 (Satellite 6.14)
- We do not accept PRs for Foreman older than 3.7.
@sbernhard What do you think about this structure/these tables?
The PR preview for c5c9eec611845bdb4868672dfa63c432eb3ec7cc is available at theforeman-foreman-documentation-preview-pr-3804.surge.sh
The following output files are affected by this PR:
@maximiliankolb if you want inspiration on how to make the application better: Foreman already has a list of operating systems and related media. Those are the same URLs as you're documenting here. What engineering wise could be built is an extension to Katello to build a wizard to set up content sources for an existing OS.
So it roughly becomes:
- Select an OS. For example, by going to the OS overview and select the "Set up content syncing"
- Add installation media. By default it will select the ones that are already added for that OS, but users can select any
Then to make it nicer we can add any repos we're missing to db/seeds.d/100-installation_media.rb.
That way you don't need to maintain a large table that users need to copy and have a nicer user experience. There would be consistency between provisioning with and without Katello by using the same data.
@sbernhard What do you think about this structure/these tables? I still think they are too bloated but an improvement to the status quo. What do you think about Ewoud's suggestion to move this to DB seeds?
@sbernhard What do you think about these tables? ACK to move forward with this or do you want us/upstream to go another direction?
Merged to "master" and cherry-picked: 5d201d4b28..ae2ced85b4 3.15 -> 3.15 3f05e52f60..34dbe7e723 3.14 -> 3.14