Bug 1576859
| Summary: | [RFE] Implement automatic assigning subnets through data provided by facter | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Nikola Kresic <nkresic> |
| Component: | Fact | Assignee: | Ondřej Pražák <oprazak> |
| Status: | CLOSED ERRATA | QA Contact: | Radovan Drazny <rdrazny> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.3.0 | CC: | bkearney, egolov, gpayelka, lzap, mhulan, mmccune, nkresic, ofalk, oprazak, peter.vreman |
| Target Milestone: | 6.8.0 | Keywords: | FutureFeature, Patch, Reopened, Triaged |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | foreman-2.0.0 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-27 12:57:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1122832 | ||
With the setting 'Update subnets from facts' set to Yes then the puppet interface facts will also get the subnet_id field assigned. When this subnet_id is mandatory then it shall not depend on a setting that can be change by the user. I have a small patch to always update the subnet if the interface is managed
--------------
--- /usr/share/foreman/app/models/host/base.rb
+++ /usr/share/foreman/app/models/host/base.rb
@@ -394,7 +394,8 @@
iface.ip = attributes.delete(:ipaddress)
iface.ip6 = attributes.delete(:ipaddress6)
- if Setting[:update_subnets_from_facts]
+ # managed interface requires always a valid subnet
+ if iface.managed? || Setting[:update_subnets_from_facts]
iface.subnet = Subnet.subnet_for(iface.ip) if iface.ip_changed? && !iface.matches_subnet?(:ip, :subnet)
iface.subnet6 = Subnet.subnet_for(iface.ip6) if iface.ip6_changed? && !iface.matches_subnet?(:ip6, :subnet6)
end
------------------
There are 2 requests in this BZ: 1) If the provisioning interface is unmanaged and no network is specified, the host deployment may fail. I think this is expected. Satellite can take care of things for you but if you set the interface as unmanaged, you are saying that you do not want that and you prefer to do it yourself. Is there any specific reason why you need the provision interface as unmanaged? I did notice that domain and subnet is automatically added again when they were removed by user when the interface was switched to unmanaged. Not sure what the reason is, perhaps that is something that could be improved. 2) When the host interfaces are modified externally, Satellite should reflect the change and update the information based on what facts are received. I consider this an RFE for updating interfaces from facts with the following requirements: * Satellite should be able to show the actual interface configuration of the host * Satellite should receive the information about interfaces via facts * When facts for the interfaces are received, Satellite should compare them with the existing data and update the data if necessary. That would include adding the missing interfaces or deleting the existing ones if they are not present in the newly received facts. Is there anything that I have missed? Ondrej, For the the key thing in this BZ is: ----- With the setting 'Update subnets from facts' set to Yes then the puppet interface facts will also get the subnet_id field assigned. When this subnet_id is mandatory then it shall not depend on a setting that can be change by the user. ----- For the Provisioning interface that is managed then subnet must be available. And therefor the fact importer shall update the subnet also from the host independent of the value of the setting 'update subnets from facts' The small patch above will fixes this small gap to not make the user force to set that setting Created redmine issue http://projects.theforeman.org/issues/25020 from this bug I see, thank you for clarification. I would like to avoid completely bypassing the setting, especially when the default id set to false. But updating only the provisioning interface is something we should be able to do. Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you. How can this be a WONTFIX with argumentation that current behavior is creating incomplete (validation failing later when updating any (even unrelated) host fields) host record when a global user setting is set 'wrong'. Also there is a very simple patch is provided that fixes it. I am running with this patch applied already for 1+ year and since then i never had any incomplete (validation failing) host interfaces anymore. We are addressing this BZ during the current sprint. Upstream bug assigned to oprazak Upstream bug assigned to oprazak Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25020 has been resolved. Tested on Satellite 6.8 Snap 13.1 using the reproducer from the initial report and additional info from comments #4 and #5. A host could be created without issues, setting an IP address directly on the host and then updating facts on Satellite correctly assigned a subnet to the interface. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: Satellite 6.8 release), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:4366 |
Description of problem: Two different issues, first is that if left unmanaged (in Sat, in GUI where you deploy a host) an interface setup and host deployment can fail if no network is specified. Second is that if after deployment we wont to switch the network interfaces, if we had 2 or 3 of them and we deployed through one but after deployment we no longer want to use that interface but we want to switch to another for updates/management/etc, the only way to do this outside Sat is to give Sat this information through facter data, which Sat currently can process properly. Examples are below. Please also check the cases from the customer linked to this BZ Version-Release number of selected component (if applicable): Sat 6.3 How reproducible: Always Steps to Reproduce: 1. - Create 2 Subnets Primary 192.168.10.x Kickstart 192.168.20.x, make this having the Capsule / TFTP - Create/Register a HostA with 2 interfaces NIC1: Primary Interface 192.168.10.x NIC2: Kickstart interface 192.168.20.x - Edit HostA interfaces - Delete subnet value from Primary interface - Check the 'Managed' to enable validation - Submit changes 2. - Create VM HostA with 2 interfaces NIC1: Main Interface NIC2: Kickstart interface - Only configure in the OS NIC1, leave NIC2 unconfigured - Remove HostA from Sat6 to make sure it will be re-created - Run puppet agent on HostA, the uploaded facts will create HostA in Sat6 Actual results: Deployment either fails if we mess around with the way Sat manages multiple interfaces, or if we try deployment without Sat controlling the interfaces, later changes cause a misconfiguration of the host in Sat Expected results: Both issues can be fixed if we allow for changes of the interface configuration outside Sat, by uploading the facter facts to Sat where they are interpreted properly and host is configured in this way, *outside* of Sat Additional info: Because the issues are connected im opening only one RFE