Drop mentions of --foreman-proxy-register-in-foreman
By removing mentions of this, it becomes an unsupported feature. This is good because various parts of the documentation assume it's turned on. Users can easily get into unexpected errors way further down the line if they disable this feature.
Where there were explicit instructions to disable it, the text is changed into troubleshooting.
I'd appreciate some feedback on the phrasing of the changed lines.
- [x] I am familiar with the contributing guidelines.
Please cherry-pick my commits into:
- [ ] Foreman 3.11/Katello 4.13
- [ ] Foreman 3.10/Katello 4.12
- [ ] Foreman 3.9/Katello 4.11 (Satellite 6.15; orcharhino 6.8)
- [ ] Foreman 3.8/Katello 4.10
- [ ] Foreman 3.7/Katello 4.9 (Satellite 6.14)
- [ ] Foreman 3.6/Katello 4.8
- [ ] Foreman 3.5/Katello 4.7 (Satellite 6.13; orcharhino 6.6/6.7)
- We do not accept PRs for Foreman older than 3.5.
@ehelms @evgeni should we introduce a migration in the installer that resets the answer (so it's turned on) or will that cause more problems than it solves?
The PR preview for 537f232c065515053e6f13e1e19b7f595781ea1d is available at theforeman-foreman-documentation-preview-pr-3080.surge.sh
The following output files are affected by this PR:
- Administering_Project/index-katello.html
- Administering_Project/index-orcharhino.html
- Administering_Project/index-satellite.html
- Configuring_Load_Balancer/index-katello.html
- Configuring_Load_Balancer/index-orcharhino.html
- Configuring_Load_Balancer/index-satellite.html
- Installing_Proxy/index-katello.html
- Installing_Proxy/index-satellite.html
I am cool w/o a migration.
@ehelms @evgeni should we introduce a migration in the installer that resets the answer (so it's turned on) or will that cause more problems than it solves?
Reset sounds good, and cleaning up the output message that includes it.
Moving back to draft because it needs some installer work as well before we can proceed.
Trivial rebase without any content changes just so I could test previews after I made changes there.
Moving back to draft because it needs some installer work as well before we can proceed.
@ehelms opened https://github.com/theforeman/foreman-installer/pull/1012.
Moving back to draft because it needs some installer work as well before we can proceed.
@ehelms opened theforeman/foreman-installer#1012.
Good connection! Yea, let's clean all this up.
Rebased without change, but now the installer is updated. I think this should only go in nightly unless we decide to cherry pick the installer patch as well.
Trivial rebase done.
Merged to "master". No cherry-picks necessary according to foreman-installer:
$ git branch --contains cab536317b58d9af129ab369ee5be33a14c4232e
* develop
Merged to "master". No cherry-picks necessary according to
foreman-installer:
Technically I think --contains only looks at merges and won't spot cherry picks because those commits have a different commit ID. https://stackoverflow.com/questions/2922652/git-is-there-a-way-to-figure-out-where-a-commit-was-cherry-picked-from/2937724#2937724 does have some ways. I usually rely on the commit message with git log --all --grep.
Argh. You're right about cherry-picks. I also assumed that "git branch --contains" would also use remote branches, which it did not. I double checked and it was merged to develop prior to branching 3.15. -> Cherry-picked to "3.15": 29595d3b1b..9f2ae907a0 3.15 -> 3.15
Refs https://github.com/theforeman/foreman-installer/commits/3.15-stable/