We are starting to be in a position where we will want to support different Foreman servers with the QUADS foreman.py library, in cases where we either have other siloed architectures or even remote geographically connected systems so this would pave the way for this.
Implementation
Looking at providing additional values in the mongoDB host collection seems to be the most obvious approach.
The behavior would be such that this value is by default not populated and the default foreman_url and foreman_api_url is used in quads.yml. However, if these value(s) are populated then they would take precedence.
For flexibility we should carry over all foreman-related settings should credentials also differ on the alternate Foreman.
foreman_url may become foreman.url in the hosts collection document.
foreman_api_url may become foreman.api in the hosts collection document.
foreman_username may become foreman.username in the hosts collection document.
foreman_password may become foreman.password in the hosts collection document.
We might also consider bringing over the medium, OS and partition table settings too just in case they needed to differ (default again here is blank and reference what's in conf/quads.yml
foreman_default_os may become foreman_default.os in the hosts collection document.
foreman_default_ptable may become foreman_default.ptable in the hosts collection document.
foreman_default_medium may become foreman_default.medium in the hosts collection document.
This is an RFE for supporting more than the default
foreman_url
andforeman_api_url
server outlined here in QUADS:https://github.com/redhat-performance/quads/blob/master/conf/quads.yml#L85
Why
We are starting to be in a position where we will want to support different Foreman servers with the QUADS
foreman.py
library, in cases where we either have other siloed architectures or even remote geographically connected systems so this would pave the way for this.Implementation
Looking at providing additional values in the mongoDB host collection seems to be the most obvious approach.
https://github.com/redhat-performance/quads/blob/c2d497e2d4f86c3b4612e47cd707be477170ebef/quads/model.py#L193
The behavior would be such that this value is by default not populated and the default
foreman_url
andforeman_api_url
is used inquads.yml
. However, if these value(s) are populated then they would take precedence.For flexibility we should carry over all foreman-related settings should credentials also differ on the alternate Foreman.
foreman_url
may becomeforeman.url
in the hosts collection document.foreman_api_url
may becomeforeman.api
in the hosts collection document.foreman_username
may becomeforeman.username
in the hosts collection document.foreman_password
may becomeforeman.password
in the hosts collection document.We might also consider bringing over the medium, OS and partition table settings too just in case they needed to differ (default again here is blank and reference what's in
conf/quads.yml
foreman_default_os
may becomeforeman_default.os
in the hosts collection document.foreman_default_ptable
may becomeforeman_default.ptable
in the hosts collection document.foreman_default_medium
may becomeforeman_default.medium
in the hosts collection document.Populating / Update Settings
I think it's enough to simply support the facilities in
quads-cli --define-host-details
to populate these settings per https://github.com/redhat-performance/quads/blob/c2d497e2d4f86c3b4612e47cd707be477170ebef/docs/quads-host-metadata-search.md#importing-host-metadata