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.
Description of problem:
The code to generate the default PXE menu (at least the unattended URL) from config_templates is inconsistent between the WebUI controller and the API controller.
This can cause different results in the generated PXE if called from the API or from the WebUI.
See below that there are 3 methods to generate the URL:
# grep -r default_template_url *
api/v1/config_templates_controller.rb: def default_template_url template, hostgroup
api/v2/config_templates_controller.rb: def default_template_url template, hostgroup
config_templates_controller.rb: def default_template_url template, hostgroup
Please refactor the code so there is only one method that generates the default PXE menu. E.g. by calling the API from the WebUI.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1. Generate a PXE template from WebUI
2. Generate a PXE template using API accessed by localhost
(curl -K /opt/hoici/etc/curl-hoici.conf -H 'Content-Type: application/json' -XGET https://localhost/api/v2/config_templates/build_pxe_default)
3.
Actual results:
Different URLs generated
Expected results:
Consistent template
Additional info:
Additionaly the Build PXE from the WebUI is affected by if there is a Location set. If a location is set then the Build PXE from the WebUI fails with cannot find a TFTP proxy.
On the other hand the API call does not this location check.
In both cases the same user account was used that has both a default org and location set.
Comment 2RHEL Program Management
2014-09-19 09:03:13 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
re comment #1, sounds like the proxy needs associating to both the org/location that you use on a day to day basis, then it should find it when under that context. (The API incidentally can specify a context, but it's generally unused.)
*** This bug has been marked as a duplicate of bug 1124386 ***
WebUI lists the capsule as being already part of the Location.
But on the Manage Location page the association is not there, when i try to add the association i get the error "Validation failed: Taxonomy has already been taken"
It looks like there is some implicit adding of locations based on hosts that are attached to the capsule.
The capsule doing tftp, puppet, puppetca