Support for non-direct communication
We need to make use of proxy http proxy plugin. From Greg's mail:
1) The Host registering with Foreman. This is a JSON POST to Foreman,
and generally works OK even through NAT
2) The reboot command at the end of the orchestration queue is direct
from Foreman to Host.
3) The request to refresh facts is direct from Foreman to Host
1) and 2) can be implemented as a smartproxy plugin adding
post /discovery/update (for uploading new facts on existing host)
as routes. The discovery image will need to be updated to try either
the proxy or core URLs, depending on the network config.
Updated by Lukas Zapletal almost 9 years ago
Notes from todays scrum:
Foreman to Image communication:
Reboot command use BMC API "shell provider" which we will extend with possibility to forward to a different BMC API if IP/hostname is provided.
Refresh facts will be implemented as a simple proxy controller in the new proxy plugin. Let's investigate if the support can be based of prefix like /proxy/:IP/original/path so other calls can be easily added just by adding new controller/action pairs (or whole paths) into an array or something. Beware of security, unlisted actions must not be proxied (let's write a functional test for this).
Image to Foreman communication:
Although Create discovered host (JSON POST) works fine with NAT, we need to proxy that as well. We can take the same approach as for Refresh Facts call, but the direction is opposite here.
The "proxy plugin" needs to have a name, but everything with a proxy in it looks strange (foreman-proxy-discovery-proxy). A patch into BMC proxy shell provider will be needed too.
Updated by Shlomi Zadok almost 9 years ago
- creating facts (receive facts from discovered host and post them to Foreman)
- updating facts (receive ip from foreman and get facts from discovered host)
Tests, secured reboot action