| Summary: | [RFE] Reducing the potential number of discovery rules | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | ckyriaki |
| Component: | Discovery Plugin | Assignee: | Lukas Zapletal <lzap> |
| Status: | CLOSED WONTFIX | QA Contact: | Katello QA List <katello-qa-list> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | Unspecified | CC: | bkearney, ckyriaki, jcallaha, kabbott, lzap |
| Target Milestone: | Unspecified | Keywords: | FutureFeature |
| Target Release: | Unused | ||
| Hardware: | All | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-09-04 19:15:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
ckyriaki
2016-09-27 15:38:00 UTC
Rating this as high as this has the chance to really have a negative impact on Satellite deployments at our largest customers. As Christina points out, any way that we can reduce the number of discovery rules in a complex environment would go a long way towards reducing the amount of resources required to run Satellite effectively in these environments. Karl Hello, this is a valid RFE, but if I understand correctly, this should be doable today if you use PXE-less: Discovery accepts fdi.factname1 and fdi.factvalue1 options today. You can use these to send any key/value you want, these are visible via facts method (facts['myfact') in the hostname template and also in provisioning templates. You can also create a simple extension (it's basically a ZIP file with a shell script) that can read variables from kernel command line and creating custom facts reported via facter, these can be used in the same way as described above. Once you test the workaround extension in your environment, we can merge the script into the upstream tree easily. Please follow our official docs about how to create ZIP extensions and for fdi kernel command line options. If this does not work for you, please explain in more detail how would you like things to be implemented. I am not sure if I understand your use case clearly. Since there is a workaround, I am setting normal priority. Please give me feedback on discovery custom facts, if you can achieve something with them. Or describe in better way what your expectations are please. I don't remember the exact details of this bz as I've opened it for a customer that I'm no longer on site for but I think the general idea is that the networks required for discovery should be able to be dynamically generated with group variables i.e. all subnets under 172.30. can be grouped by one discovery rule as there can be multiple combinations of hostgroup*rhel version and discovered network. If this doesn't make sense then please close the BZ. Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you. Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you. |