Bug 1576859 - [RFE] Implement automatic assigning subnets through data provided by facter
Summary: [RFE] Implement automatic assigning subnets through data provided by facter
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Fact
Version: 6.3.0
Hardware: Unspecified
OS: Linux
high
medium
Target Milestone: 6.8.0
Assignee: Ondřej Pražák
QA Contact: Radovan Drazny
URL:
Whiteboard:
Depends On:
Blocks: 1122832
TreeView+ depends on / blocked
 
Reported: 2018-05-10 14:53 UTC by Nikola Kresic
Modified: 2020-10-27 12:57 UTC (History)
10 users (show)

Fixed In Version: foreman-2.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-27 12:57:24 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 25020 0 Normal Closed Update subnets from facts only for provision interface 2020-10-28 17:14:46 UTC
Red Hat Product Errata RHSA-2020:4366 0 None None None 2020-10-27 12:57:42 UTC

Internal Links: 1577136

Description Nikola Kresic 2018-05-10 14:53:52 UTC
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

Comment 2 Peter Vreman 2018-05-17 08:11:10 UTC
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.

Comment 3 Peter Vreman 2018-07-31 15:30:39 UTC
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
------------------

Comment 4 Ondřej Pražák 2018-09-13 11:49:45 UTC
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?

Comment 5 Peter Vreman 2018-09-14 15:51:35 UTC
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

Comment 6 Ondřej Pražák 2018-09-24 12:10:28 UTC
Created redmine issue http://projects.theforeman.org/issues/25020 from this bug

Comment 7 Ondřej Pražák 2018-09-24 12:11:24 UTC
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.

Comment 9 Bryan Kearney 2019-11-04 14:00:53 UTC
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.

Comment 10 Peter Vreman 2019-11-04 14:10:38 UTC
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.

Comment 14 Bryan Kearney 2019-11-11 21:19:15 UTC
We are addressing this BZ during the current sprint.

Comment 15 Bryan Kearney 2019-11-18 11:01:36 UTC
Upstream bug assigned to oprazak@redhat.com

Comment 16 Bryan Kearney 2019-11-18 11:01:39 UTC
Upstream bug assigned to oprazak@redhat.com

Comment 17 Bryan Kearney 2019-11-21 19:01:46 UTC
Moving this bug to POST for triage into Satellite 6 since the upstream issue https://projects.theforeman.org/issues/25020 has been resolved.

Comment 26 Radovan Drazny 2020-09-04 15:54:03 UTC
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.

Comment 29 errata-xmlrpc 2020-10-27 12:57:24 UTC
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


Note You need to log in before you can comment on or make changes to this bug.