Bug 1511416 - [RFE] Ability to leave IP address field empty when creating new host
Summary: [RFE] Ability to leave IP address field empty when creating new host
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Networking
Version: 6.2.12
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: Unspecified
Assignee: Aditi Puntambekar
QA Contact: Roman Plevka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-09 10:12 UTC by Ture Karlsson
Modified: 2019-07-02 17:53 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-02 17:53:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 22485 0 Normal New Ability to leave IP address field empty when creating new host 2020-11-13 07:42:26 UTC

Description Ture Karlsson 2017-11-09 10:12:42 UTC
Description of problem:
In some environments, Satellite is used to provision new hosts, but DHCP is not running on Satellite/Capsule, but already exist (e.g. from AD) and is not known to the Satellite.

In this situation, when creating a new host, it is not known what IP the host will get from the DHCP, but you still have to provide an IP (which will be set in the Satellite but ignored by the DHCP) in the Interfaces tab under Hosts -> New Host.

This makes no sense and creates confusion for customers, since that IP is not used anyway.

Version-Release number of selected component (if applicable): 6.2.12


How reproducible:
Always

Steps to Reproduce:
1. Setup a Satellite and Capsule (or use the internal Capsule on the Satellite) in a subnet where DNS and DHCP is provided by another party (e.g. AD).
2. Start the TFTP service on the Capsule
3. Make sure the existing DHCP has configured the Capsule as next-server
4. Create a subnet declaration for the subnet in the Satellite. Since you don't have DHCP running on the Capsule the only sensible choice (to me) is to set "IPAM: None"
5. Under Capsules, choose the Capsule as TFTP Capsule and leave the others to None, since neither of the other features are enabled on the Capsule. 
6. Now create a new host (Hosts -> New Hosts). When you choose the subnet in the Interfaces tab, you have to manually input an IP (which you don't know at this stage). Otherwise you can't create the host. You can input whatever IP you want that is in the range of the subnet, it does not matter.
7. Press Submit and the host is created and built with an IP assigned by the DHCP.

Actual results:
You have to input a random IP since you don't know what IP the DHCP will provide, in order to be able to create the host.

Expected results:
Alternative 1: If you choose "IPAM: None" in your subnet declaration, you should be able to leave the IP field empty.

Alternative 2: Add another option to the IPAM field that allows you to create a host without providing an IP address.

Additional info:
I have seen this with multiple customers that have an existing network they want to use where they have these components in place. I know that the Capsule can integrate with different providers, but IIRC AD DHCP is not one of them (yet).

One workaround is to set "IPAM: Internal DB" and set start and end of IP range to e.g. the first IP in the DHCP range. Then the Satellite will suggest the same IP every time even if it is not the one the host will get in the end.

It is also possible to make sure that the Satellite updates to the correct IP after build is complete with the following setting: Administer -> Settings -> Provisioning -> Update IP from built request.

Comment 1 Daniel Lobato Garcia 2018-02-01 17:08:26 UTC
Cloning to Redmine, valid RFE IMO.

Comment 2 Daniel Lobato Garcia 2018-02-01 17:09:28 UTC
Created redmine issue http://projects.theforeman.org/issues/22485 from this bug

Comment 3 Bryan Kearney 2019-07-02 17:53:43 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.


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