Document URL: Section Number and Name: 13.2.4. Configuring Parameterized Classes Describe the issue: Step 9 describes how to set up overrides. Although it contains some examples the list of parameters available for matching is missing. Suggestions for improvement: Add a paragraph that would contain a list of applicable parameters plus mention that puppet facts can be used too. Additional information: There are upstream docs about this functionality: http://theforeman.org/manuals/1.9/index.html#4.2.6SmartMatchers
Hello Tomas The Parameters section of the Host Configuration Guide was improved recently but I was not aware of this bug. Could you review the current doc [1] for us and see if there is anything more that needs to be added? Thank you See also Bug 1328132 - Information on available parameters missing for order field in Smart Class Parameter Bug 1374467 - [RFE] Add an 'AND' operator to the matcher conditionals [1] https://access.redhat.com/documentation/en/red-hat-satellite/6.2/paged/host-configuration-guide/82-parameters
Hi Stephen, bug 1328132 is duplicate of this one. I'll mark this bug as dupe just because there's been more activity in the other one. The documentation look much better now. Good job! Still I think it would be good to mention the list of available matcher keys. Of course we won't be able to list every possible option, because the mechanism is very dynamic, but we can provide at least the basic examples as in [1]. I find it useful especially for the description of values. Other candidates that might be worth mentioning are: architecture compute_profile compute_resource content_view domain environment hostgroup lifecycle_environment location medium model operatingsystem organization ptable puppet_ca_proxy puppet_proxy subnet [1] https://theforeman.org/manuals/1.9/index.html#4.2.6SmartMatchers *** This bug has been marked as a duplicate of bug 1328132 ***
(In reply to Tomas Strachota from comment #2) > Hi Stephen, > bug 1328132 is duplicate of this one. I'll mark this bug as dupe just > because there's been more activity in the other one. Thank you > > The documentation look much better now. Good job! Still I think it would be > good to mention the list of available matcher keys. Of course we won't be > able to list every possible option, because the mechanism is very dynamic, Also, things change, not all system will have the same Puppet Facts. So were prefer to say how to find them when possible. > but we can provide at least the basic examples as in [1]. I find it useful > especially for the description of values. > > Other candidates that might be worth mentioning are: > architecture > compute_profile > compute_resource > content_view > domain > environment > hostgroup > lifecycle_environment > location > medium > model > operatingsystem > organization > ptable > puppet_ca_proxy > puppet_proxy > subnet > Are those all Puppet Facts? Where did you get that list? I went to Monitor -> Facts on my test VM: architecture <-- present compute_profile <-- Not found compute_resource <-- Not found content_view <-- Not found domain <-- present environment <-- not present hostgroup <-- not present lifecycle_environment <-- not present location <-- not present medium <-- not present model <-- not present {I see lscpu::model } operatingsystem <-- present organization <-- not present ptable <-- not present puppet_ca_proxy <-- not present puppet_proxy <-- not present subnet <-- not present Thank you
The list I sent is subset of host's attributes (mentioned in docs in procedure 8.3, bullet 9. > 2. > 1.). They're hard-coded in the satellite models and therefore I expect changes only upon a release. Some of the attributes overlap with facts and, as described in the matching procedure, they take precedence. That could be another pro for adding the list: to be clear about when we match against attributes vs. facts.