Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1255484 - [RFE] Make subnet an optional field
Summary: [RFE] Make subnet an optional field
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Provisioning
Version: 6.0.8
Hardware: All
OS: Linux
medium
medium
Target Milestone: Unspecified
Assignee: Lukas Zapletal
QA Contact: Shimon Shtein
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-20 17:44 UTC by Karthick Murugadhas
Modified: 2021-08-30 10:40 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-21 12:30:53 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Verification screenshot (53.75 KB, image/png)
2017-08-16 17:40 UTC, Shimon Shtein
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 15133 0 Normal Resolved Make subnet an optional field 2020-11-17 06:17:16 UTC
Red Hat Issue Tracker SAT-4751 0 None None None 2021-08-30 10:40:41 UTC
Red Hat Knowledge Base (Solution) 1616173 0 None None None 2016-07-24 08:33:46 UTC
Red Hat Product Errata RHBA-2016:1500 0 normal SHIPPED_LIVE Red Hat Satellite 6.2 Base Libraries 2016-07-27 12:24:38 UTC
Red Hat Product Errata RHSA-2018:0336 0 normal SHIPPED_LIVE Important: Satellite 6.3 security, bug fix, and enhancement update 2018-02-21 22:43:42 UTC

Comment 17 Lukas Zapletal 2016-05-16 19:31:09 UTC
I think there was a misunderstanding on my side. RFE is was to make Subnet an optional field (therefore I am also renaming the subject).

Subnet field was and is (in 6.2) required field for Managed and/or Provision interfaces. It defines whether to use DHCP or Static configuration for Managed interface and defines other required services for Provision interface like Puppet Master/CA, TFTP, Reverse DNS and Discovery. These are essential associations which are made through Subnet, for this reason this is mandatory field and we unlikely change that.

For unmanaged (non-provision) interfaces it should be technically possible not to require Subnet field, but we don't support that. I was under impression that version 6.2 supports that, but that was not the case. But if I understand customer requirements correctly, in both cases they would like to have the field optional for Provision interfaces.

While it might be tempting to do a workaround by creating a "fake" Subnet(s), I'd not recommend that. If subnet address and netmask does not match, Satellite will be unable to find the subnet for particular IP address (e.g. discovery finds Capsule for communication).

Ohad, can you confirm my opinion? Or do you see there is a way of turning Subnet field into non-mandatory one?

Comment 18 Ohad Levy 2016-05-17 07:41:29 UTC
I tend to agree with Lukas, however I wonder if we could simplify the usage cases where tftp is only used (e.g. no dhcp/dns, where ip address management is not as important), without adding further confusion / more complex setup.

Having said that, we already have infoblox support in the upstream, and would expect that being added downstream, so in the case of using infoblox and satellite, you would actually need to use the current subnet anyway.

Comment 19 Lukas Zapletal 2016-05-17 13:27:40 UTC
Can you elaborate on that Ohad? Do you suggest to make the subnet field optional when DHCP Capsule is not associated? If so, do you think this should still go into 6.2 GA release?

Comment 23 errata-xmlrpc 2016-07-27 08:54:54 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, 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/RHBA-2016:1500

Comment 25 Lukas Zapletal 2017-05-18 07:29:00 UTC
I am making this bug public, keeping the initial internal discussion private tho.

Anyway, I am moving this on to ON_QA for 6.3. I am now able to create host without any subnet. When you select domain, subnet is automatically selected it there is one associated, but the dropdown can be switched back to "Please select" which is blank value. I tested this with one or two subnets, all works just fine.

QA: Please just verify, steps are above.

Comment 26 Lukas Zapletal 2017-05-18 07:34:05 UTC
I also created small change upstream to change the confusing label for blank value: http://projects.theforeman.org/issues/19583

Comment 27 Shimon Shtein 2017-08-16 17:40:08 UTC
Created attachment 1314259 [details]
Verification screenshot

Verified.

Screenshot attached. Works both for domain without any subnet and for domain with single subnet (with deselecting it).

Sat version: 6.3.0-16.0.beta.el7sat

Comment 28 Luc de Louw 2017-09-20 14:10:45 UTC
Is it planned to also manually provide a (default) gateway?

Thanks,

Luc

Comment 31 errata-xmlrpc 2018-02-21 12:30:53 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, 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-2018:0336


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