* Adding explicit MPL license for sub-package.
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Adding explicit MPL license for sub-package
This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.
* Updating the license from MPL to Business Source License
Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at www.hashicorp.com/licensing-faq, and details of the license at www.hashicorp.com/bsl.
* Update copyright file headers to BUS-1.1
* Rerun make gen
This will pick up the last of the license changes
* Revert "Rerun make gen"
This reverts commit dbe0968bffd92745d8663c6940debae098395a6b.
* Remove copywrite from generation script
The current version of copywrite is not sophisticated enough
to only apply the copywrite changes to certain subdirectories,
so to avoid accidentally relicensing our api and sdk modules,
we will stop running the copywrite script until such time
that it can do the right thing.
* License protobuf API as MPL
The protobuf API files are used to generate the SDK,
since we want the SDK to be MPL, the protobuf files
must also be MPL. This extends to all protobuf files
whose sources end up in the SDK directory, including:
- internal/proto/controller/api
- internal/proto/controller/custom_options
- internal/proto/plugin
It also includes the generated service directory in
internal/gen/controller/api/services, since they are
generated from the protobuf sources used for the SDK.
* Change website license file name
This makes the naming scheme consistent with the rest
of the repository.
* Add note on licensing to README
* Set copywrite license to BUSL
* Revert "Add note on licensing to README"
This reverts commit 4d865a91a7a4f11605f0dc4609355d7e3c3cfffe.
---------
Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Our test helper packages were not possible to use
with benchmarks. This refactor switches to testing.TB
to allow both tests and benchmarks to use the helpers.
We never ended up using this and it makes it much harder to reason about the listeners.
An explanation: for the moment I separated out all of the listeners in the struct, even though one should suffice, because when I did it that way first I was hitting some really weird and hard to find intermittent behavior where it seemed like the listeners were getting crossed. So I re-did it this way with each listener very explicitly referenced. I'm happy to make a follow-up PR that attempts to combine them all into a single listener without hitting the issues I did, if desired, but at least doing it via a separate PR means that it won't be something with removing the ALPN muxer that is at fault.
Internally attributes are not allowed to be the null value. However, as
currently implemented, this then breaks our normal model of sending an
explicit `null` in the JSON to reset/clear a field. This is a problem
because the CLI doesn't have a way to say "set this but to empty"
without a lot of hoops, and causes some issues for API users and TF as
well.
This changes PatchBytes and PatchStruct to return an empty value (or
marshaled empty value in the case of PatchBytes) if the source is null
or empty. In the host catalog update function we then always set this
value if it's in the db mask (removing the nil check). Together this
means a null value ends up coming out as an empty value (and thus valid
for the DB) from PatchStruct/PatchBytes, and our API translation
function already returns nothing for attributes if the length of the
fields are zero.
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.
Anton Averchenkov
aditya2548
Jeff Mitchell
Todd
Chris Marchesi
Michael GaffneyandJeff Mitchell