fixes #12823 - multi-network support for sysidcfg #2976
Conversation
|
There were the following issues with the commit message:
If you don't have a ticket number, please create an issue in Redmine, selecting the appropriate project. More guidelines are available on the Foreman wiki. This message was auto-generated by Foreman's prprocessor |
domcleal
changed the title
| @@ -89,6 +89,7 @@ def jumpstart_params(host, vendor) | |||
| server_ip = host.domain.resolver.getaddress(server_name).to_s | |||
| jpath = jumpstart_path host.medium, host.domain | |||
| ipath = interpolate_medium_vars(host.medium.media_dir, host.architecture.name, self) | |||
| network = host.subnet.network | |||
There was a problem hiding this comment.
This might have to look at host.provisioning_interface.subnet.network, as the provisioning interface may be different to the primary.
Also, the indentation is off by one character.
|
This looks like it'd be a backwards-incompatible change, do you agree? It appears that this would then need users to populate sysidcfg files for each subnet. We might have to think about a more configurable way if so. If you could squash your commits ( |
|
How about using a custom parameter which holds network value, that is when declared [either at host level or OS level] can be used [i.e. /export/jumpstart/sysidcfg/sysidcfg_primary/192.168.216.0], otherwise empty out the path, resulting it to use /export/jumpstart/sysidcfg/sysidcfg_primary/ |
|
We don't use or assume any parameters in the core app, they're only really for end users. It'd be more typical to add an attribute onto the operating system I suppose, or add a global setting. |
|
I am clueless if how OS attribute or global setting would get populated with hosts network. As I see it, the setting or attr needs to be a value and can not be another variable holding a value. |
|
I mean a boolean about whether to use the network in the sysidcfg path or not, which can then be populated in the host still. My understanding is that if the code went in like this, the paths of any existing sysidcfg files would have to change - users would have to create new ones? |
|
I understand your concern. I will re-visit the problem altogether and file a separate pull request. That would be for multiple sysidcfg files support. |
sysidcfg can be specified for separate network, adding a way to get that freedom in foreman solaris support