-
Jeff McCune authored
* Add GCF VM Delete Event Handler Example Customer use case: When a VM is deleted, DNS A records associated with the VM should be automatically deleted so that stale DNS records do not pile up. The customer requested the solution be general enough to support VMs deleted through the Console UI, gcloud, Deployment Manager, Terraform, etc... The solution uses a GCF Background Function handling `compute.instances.delete events`. The customer also required the function compare the IP address of the VM's primary interface with the DNS A record rrdatas to guard against deleting the incorrect record. This IP check introduces a race condition, the function races against the VM delete operation. In practice the function wins the race most of the time and the cleanup is successful. * Improve log UX when DNS cleanup fails for reason IP_NOT_AVAILABLE This patch is intended to enable the customer to easily identify when the DNS A record cleanup is not performed because the IP address cannot be determined. The goal is to provide structured data to easily filter and identify VM instances which did not have their A record deleted. The reason: 'IP_NOT_AVAILABLE' key/value is intended to provide this filter. * Refactor to DnsVmGc app class and structured logs App class --- This patch refactors GCF function into a DnsVmGc class. Instances of this class are intended to have the same lifetime as the GCF background function process. API discovery happens once during cold start and is re-used across multiple trigger events. The EventHandler class models a single event processing execution. Helper methods ensure results are reported consistently via the `log_struct` method. Result logs are logged into the `reports/dns_vm_gc` stream. Structured Logs --- Without this patch the log structure data is sprinkled throughout the code. This is a problem because it's tangled up with the behavior, instead the structured logs should be considered a contract with the end user who will generate reports based on the logs. This patch defines a set of StructuredLog sub-classes modeling the structured log data. This separates the log structure from the behavior of the code, making it easier to change the behavior of the code without affecting the log structure the user relies on. Structured Logs are sent to the `projects/$FUNCTION_PROJECT/logs/$FUNCTION_NAME` by default. The output stream is configurable via the DNS_VM_GC_REPORTING_LOG_STREAM environment variable.
79bbafac