Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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?
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.
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?
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
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.
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
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