This adds a parameter to host sets allowing the sync interval to be
user-specified on a per-host-set basis. A value of -1 disables syncing;
a value of null uses the current default.
* Create catalog service handler for updating plugin. Add tests for handler and run make fmt. Silently drop attributes where the value is nil when creating the catalog or set.
* internal/libs/patchstruct: add package for patching structpb
This adds a small helper package for patching *structpb.Struct values
using the same patterns that our APIs use for updating records. The
intent of this package is to provide a fallback mechanism for working
with these values when said record update behavior is unavailable, such
as when working with plugin-based host subtypes where the exact
structure of the subtype's attributes is unavailable.
patchstruct.Patch follows the following logic:
* The source (src) map is merged into the destination map (dst).
* Values are overwritten by the source map if they exist in both.
* Values are deleted from the destination if they are set to null in the
source.
* Maps are recursively applied, meaning that a nested map at key "foo" in
the destination would be patched with a map at key "foo" in the
source.
* A map in the destination is overwritten by a non-map in the source,
and a non-map in the destination is overwritten by a map in the
source.
Patch returns the updated map as a copy, dst and src are not altered.
* Add doc comment for patchstruct.Patch
* vim snafu
* Premature commit of repository_host_catalog.go
* add nil cases
* internal/libs/patchstruct: add PatchJSON
* small comment formatting fix
* Change PatchJSON to PatchBytes
PatchJSON wasn't what was needed here - we need a helper to patch the
protobuf encoding of structpb.Struct.
* remove equality for original src/dst for patchbytes
Rather than pick addresses totally at random, this changes the
preference to be private IP4 > public IP4 > DNS. (Ordering is not
guaranteed, but in many cases there will only be one of each type of IP
anyways.) All three of these are preferred over IP6, which also goes
public > private.
This seems likely to match the common case where you're getting into a
machine on the private side from the public side. It's harder to know if
DNS is private or not, so IPs are preferred in this case.
Jeff MitchellandJim
Todd
Chris Marchesi
Michael GaffneyandJeff Mitchell