| We had a meeting discussing the explicit lifetime of nodes in PDB on 3/28/19. This ticket will be used to summarize what was discussed and as a way to link additional work on the PDB team that may happen as a result. Please correct anything in the description below that doesn't seem accurate. Nodes missing from inventory endpoint: The Console is currently submitting an empty factset to PDB (if none exist for a given certname) in order to work around nodes not being present in the PDB inventory endpoint. This can happen if the node was created with a configure expiration command but hasn't received a factset/report/catalog command. For Kearney the behavior described above will continue. Post Kearney the PDB team will look into creating the empty factset when it receives a configure expiration command if a factest for the node doesn't yet exist. The PDB team may also look into having the existence of a node be sufficient for it to show up in the results from the inventory endpoint even if that node has yet to receive a factset/catalog/report.
Keeping nodes alive without completely disabling expiration: We also discussed ways to keep a node alive that would avoid the possibility of that node failing to expire when it should. One option was for the Console to use the existing configure expiration command to effectively touch a timestamp used to decide TTL on the node in question at a set interval. This could be accomplished by sending a configure expiration command at an interval more frequent than the node TTL set in PDB. See example configure expiration command below:
{ |
"certname": <string>, |
"expire": {"facts": true}, |
"producer_timestamp": <datetime> |
}
|
Repeatedly sending commands with: "expire": {"facts": true} would have the node exhibit the same behavior as a node managed by a Puppet agent, meaning that it would eventually expire unless a command for the node/certname was received within the node TTL. This approach would exploit the fact that we look at the updated timestamp in the certname_fact_expiration table when deciding which nodes to expire. See expire-stale-nodes. We believe the approach described above should work in the short term. Post Kearney the PDB team will look into creating a command that can be used explicitly to touch a timestamp PDB uses to decide when a node should expire. The PDB team will also explore the possibility of supporting bulk updates for this new command.
Please link any related tickets which are created to this one.
|
