Extending this to allow the Lookup to use other facts of the node also. E.g. Hostname
Opened this issue · 3 comments
Use Case
Currently the lookup at ServiceNow is to matchup with the node via the certname. However there are situations which this are not ideal. Extending this to allow the Lookup to use other fact of the node also. E.g. Hostname
Describe the Solution You Would Like
Additional Parameter can be added to specify the alternative fact to use to match up with the data on the servicenow. i.e. factnameinplaceofcertname
Additional Context
My scenerio originate from a real customer's situation. The customer plans using the said module for patching. However they do not like the fact that the module does CI lookup in CMDB, according to FQDN. Hence they want to customise the module so that hostname value is used in the lookup instead. Their certnames do not tally 100% with the fqdn found in their servicenow CMDB, this causes a lot of error and mismatched. Hence they are hopping that we can be flexible in this integration, esp on the linking of the data on both side.
It is found that upgrading the PDK Version used is slightly harder. Since it is not the focus of the Issue, so minimum was done on that part. It was fixed just enough to run the unit tests.
One danger in using an untrusted fact such as 'hostname' is that it can change overtime and cause a linkage break with the CMDB. It could also potentially end up causing duplicated entries in the CMDB, if they are being created from the hostname, so it would be important to at least include warnings about the use of an untrusted fact as the lookup.
Is the behaviour you're intending here @sooyean-hoo that a user could change the lookup field from certname to hostname? Or that they could provide a fallback field of hostname in the case that certname is not matched?
@jessereynolds The issue that is that certname is a provided information. The user provides the info during the installation, while the fact is a system determined data. In the customer environment, for some reason, the registration is done with long or short DNS names, a legacy issue. To have a perfect world where everyone registers with the same format of FQDN is not possible.
Hostname is the constant and has a 1:1 matching with the ServiceNow. Hence the customer chooses to use this fact instead. They are aware that they are not using a trusted fact potentially end up causing duplicate entries. However this risk is less troublesome and more manageable than to do an overhaul of the ServiceNow data or the Puppet Agents registrations. Have the alternate fact as a faiilsafe is also not acceptable.